VPN se znovu připojí, ale relace aplikace stále selhává

Tunel se vrátí, klient hlásí připojení a prohlížeč se pořád točí na stránce, kterou načítal před výpadkem. Opětovné připojení VPN obnoví cestu a neobnoví stav spojení, který aplikace a vzdálená strana nashromáždily na té staré. To jsou dvě různé věci k opravě a jejich záměna vás bez důvodu vrací do nastavení VPN.

Jeden test je čistě oddělí a trvá deset sekund. Pošlete nový požadavek na stejné místo určení, dokud ten starý visí.

Co opětovné připojení přežije a co ne

Tunel je sada tras, klíčů a adres a opětovné připojení může obnovit všechny tři, zatímco každý navázaný tok zůstává mrtvý. Operační systém drží socket otevřený, protože o to aplikace požádala, a časový limit toho socketu může být minuty nebo hodiny daleko. Pod tím protějšek zapomněl tok, záznam překladu vypršel, nebo cesta teď vede přes koncový bod, který handshake nikdy neviděl. Nic v sekvenci opětovného připojení neprochází sockety aplikace a neopravuje je.

Někteří klienti přidávají hák, který při opětovném připojení zahodí zastaralá spojení, a většina ne. Chování se tu liší podle klienta, platformy a verze.

Vzdálená strana zapomněla i vás

Vzdálený konec drží vlastní stav: relaci TLS, řídicí blok TCP a možná záznam mapování, který svazuje vaši adresu a port s tokem. Překladové zařízení na cestě může ten záznam nechat vypršet během mezery, i když se tunel obnoví rychle. Jakmile mapování zmizí, přicházejí pakety pro tok, který server už nezná, a odpovědí může být reset, který klient nikdy neukáže. Aplikace to hlásí jako zaseknutí, ne jako chybu, protože pořád čekají na socket, který nikdy neodpoví.

Časové limity nečinnosti na straně serveru dělají totéž podle vlastního rozvrhu, a proto relace může zemřít bez jakékoli síťové události. Spojení, které bylo nečinné déle, než server očekává, je pryč dřív, než si všimnete, že se tunel pohnul.

Nový požadavek je test, který je oddělí

Pošlete nový požadavek na stejný hostitel, dokud starý ještě visí, a sledujte oba. Pokud nový požadavek uspěje, tunel, trasa i překlad jmen fungují a závada je omezená na zastaralý tok. Pokud selže i nový požadavek, máte problém s cestou a stav relace aplikace je falešná stopa.

Během testu nechte jakýkoli blok přímého provozu na místě. Požadavek, který uspěje přes náhodnou záložní cestu, o tunelu nic nedokazuje.

Potvrďte novým spojením, ne tím starým

Níže uvedené příkazy ukážou sockety, které jsou stále otevřené, spustí jeden nový požadavek a ověří, zda tabulka relací pořád drží záznam pro tok. Spusťte první před opětovným připojením a po něm, aby byl rozdíl vidět. Nahraďte hostitele a port vlastní službou.

ss -tanp | grep -E ':(443|8443)'
curl -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 https://intranet.example.com/
conntrack -L 2>/dev/null | grep 8443
dig +short intranet.example.com

Navázaný socket, kterým neprochází provoz, je podpis, který hledáte, a nový požadavek vracející stavový kód ukazuje, že cesta žije. Tabulka spojení odpovídá na to, zda tok ještě něco mapuje, a to je část, kterou klient nevidí. Dotaz na resolver pokrývá druhou polovinu načtení stránky, protože selhání jména a zaseknuté spojení vypadají v prohlížeči stejně. Dohromady ty čtyři výstupy oddělí zastaralou relaci od rozbitého tunelu.

Zapište čas přerušení, čas opětovného připojení a rozdíl mezi starým a novým požadavkem. Takový záznam mění vágní stížnost ve zprávu, se kterou může někdo pracovat.