VPN koblet til på nytt, men appøkten feiler fortsatt

Tunnelen er tilbake, klienten sier tilkoblet, og nettleseren spinner fortsatt på en side den lastet før bruddet. En VPN-gjenoppkobling gjenoppretter en rute og gjenoppretter ikke den tilkoblingstilstanden som applikasjonene og fjernsiden samlet på den gamle. Det er to forskjellige ting å reparere, og å blande dem sender deg tilbake til VPN-innstillingene uten grunn.

Én test skiller dem rent, og den tar ti sekunder. Send en ny forespørsel til samme destinasjon mens den gamle henger.

Hva som overlever en gjenoppkobling og hva som ikke gjør det

En tunnel er et sett med ruter, nøkler og adresser, og en gjenoppkobling kan gjenopprette alle tre mens hver etablert flyt forblir død. Operativsystemet holder en socket åpen fordi applikasjonen ba om det, og den socketens tidsavbrudd kan være minutter eller timer unna. Under det har motparten glemt flyten, en oversettelsesoppføring er utløpt, eller ruten går nå gjennom et endepunkt som aldri så håndtrykket. Ingenting i gjenoppkoblingssekvensen går gjennom applikasjonens sockets og reparerer dem.

Noen klienter legger til en krok som slipper gamle tilkoblinger ved gjenoppkobling, og de fleste gjør det ikke. Atferden her varierer etter klient, plattform og versjon.

Fjernsiden glemte deg også

Den fjerne enden holder sin egen tilstand: en TLS-økt, en TCP-kontrollblokk og kanskje en mapping-oppføring som binder adressen og porten din til flyten. En oversettelsesenhet langs ruten kan la den mappingen utløpe i løpet av gapet selv når tunnelen gjenopprettes raskt. Når mappingen er borte, kommer pakker for en flyt serveren ikke lenger kjenner igjen, og svaret kan være en reset klienten aldri viser. Applikasjoner rapporterer dette som en fastlåsing og ikke som en feil, fordi de fortsatt venter på en socket som aldri vil svare.

Inaktivitetstidsavbrudd på serversiden gjør det samme etter sin egen plan, og derfor kan en økt dø uten noen nettverkshendelse i det hele tatt. En tilkobling som har vært inaktiv lenger enn serveren forventer, er allerede borte før du merker at tunnelen har flyttet seg.

En ny forespørsel er testen som skiller dem

Send en ny forespørsel til samme vert mens den gamle fortsatt henger, og følg med på begge. Hvis den nye forespørselen lykkes, virker tunnelen, ruten og navneoppslaget, og feilen er begrenset til den gamle flyten. Hvis den nye forespørselen også feiler, har du et ruteproblem og applikasjonens økttilstand er et falskt spor.

La enhver blokkering av direkte trafikk stå under testen. En forespørsel som lykkes gjennom en tilfeldig reservevei beviser ingenting om tunnelen.

Bekreft med en ny tilkobling, ikke den gamle

Kommandoene nedenfor viser socketene som fortsatt er åpne, starter én ny forespørsel og sjekker om økttabellen fortsatt har en oppføring for flyten. Kjør den første før og etter gjenoppkoblingen så forskjellen blir synlig. Erstatt verten og porten med din egen tjeneste.

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

En etablert socket uten trafikk som beveger seg er signaturen du leter etter, og en ny forespørsel som returnerer en statuskode viser at ruten lever. Tilkoblingstabellen svarer på om noe fortsatt mapper flyten, og det er den delen klienten ikke kan se. Resolver-spørringen dekker den andre halvdelen av en sideinnlasting, siden en navnefeil og en fastlåst tilkobling ser like ut i en nettleser. Sammen skiller de fire utskriftene en gammel økt fra en ødelagt tunnel.

Noter avbruddstidspunktet, gjenoppkoblingstidspunktet og forskjellen mellom den gamle og den nye forespørselen. Den noten gjør en vag klage til en rapport noen kan handle på.