VPN sa znova pripojilo, ale relácia aplikácie stále zlyháva

Tunel sa vráti, klient hlási pripojenie a prehliadač sa stále točí na stránke, ktorú načítaval pred výpadkom. Opätovné pripojenie VPN obnoví cestu a neobnoví stav spojenia, ktorý aplikácie a vzdialená strana nahromadili na tej starej. To sú dve rôzne veci na opravu a ich zámena vás bez dôvodu vracia do nastavení VPN.

Jeden test ich čisto oddelí a trvá desať sekúnd. Pošlite novú požiadavku na rovnaké miesto určenia, kým tá stará visí.

Čo opätovné pripojenie prežije a čo nie

Tunel je sada trás, kľúčov a adries a opätovné pripojenie môže obnoviť všetky tri, zatiaľ čo každý nadviazaný tok zostáva mŕtvy. Operačný systém drží socket otvorený, pretože o to aplikácia požiadala, a časový limit toho socketu môže byť minúty alebo hodiny ďaleko. Pod tým protistrana zabudla tok, záznam prekladu vypršal, alebo cesta teraz vedie cez koncový bod, ktorý handshake nikdy nevidel. Nič v sekvencii opätovného pripojenia neprechádza socketmi aplikácie a neopravuje ich.

Niektorí klienti pridávajú hák, ktorý pri opätovnom pripojení zahodí zastarané spojenia, a väčšina nie. Správanie sa tu líši podľa klienta, platformy a verzie.

Vzdialená strana zabudla aj vás

Vzdialený koniec drží vlastný stav: reláciu TLS, riadiaci blok TCP a možno záznam mapovania, ktorý spája vašu adresu a port s tokom. Prekladové zariadenie na ceste môže nechať to mapovanie vypršať počas medzery, aj keď sa tunel obnoví rýchlo. Keď mapovanie zmizne, prichádzajú pakety pre tok, ktorý server už nepozná, a odpoveďou môže byť reset, ktorý klient nikdy neukáže. Aplikácie to hlásia ako zaseknutie a nie ako chybu, pretože stále čakajú na socket, ktorý nikdy neodpovie.

Časové limity nečinnosti na strane servera robia to isté podľa vlastného rozvrhu, a preto môže relácia zomrieť bez akéhokoľvek sieťového zdarzenia. Spojenie, ktoré bolo nečinné dlhšie, než server očakáva, je preč skôr, než si všimnete, že sa tunel pohol.

Nová požiadavka je test, ktorý ich oddelí

Pošlite novú požiadavku na rovnaký hostiteľ, kým tá stará ešte visí, a sledujte obe. Ak nová požiadavka uspeje, tunel, trasa aj preklad názvov fungujú a porucha je obmedzená na zastaraný tok. Ak zlyhá aj nová požiadavka, máte problém s cestou a stav relácie aplikácie je falošná stopa.

Počas testu nechajte akúkoľvek blokádu priamej prevádzky na mieste. Požiadavka, ktorá uspeje cez náhodnú záložnú cestu, o tuneli nič nedokazuje.

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

Príkazy nižšie ukážu sockety, ktoré sú stále otvorené, spustia jednu novú požiadavku a overia, či tabuľka relácií ešte drží záznam pre tok. Spustite prvý pred opätovným pripojením a po ňom, aby bol rozdiel viditeľný. Nahraďte hostiteľa a port vlastnou 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

Nadviazaný socket, ktorým neprechádza prevádzka, je podpis, ktorý hľadáte, a nová požiadavka vracajúca stavový kód ukazuje, že cesta žije. Tabuľka spojení odpovedá, či tok ešte niečo mapuje, a to je časť, ktorú klient nevidí. Dotaz na resolver pokrýva druhú polovicu načítania stránky, pretože zlyhanie názvu a zaseknuté spojenie vyzerajú v prehliadači rovnako. Spolu tieto štyri výstupy oddeľujú zastaranú reláciu od pokazeného tunela.

Zapíšte čas prerušenia, čas opätovného pripojenia a rozdiel medzi starou a novou požiadavkou. Taký záznam mení vágne sťažnosti na správu, s ktorou môže niekto pracovať.