VPN’en er genopkoblet, men app-sessionen fejler stadig

Tunnelen er tilbage, klienten siger forbundet, og browseren kører stadig rundt på en side, den var ved at indlæse før afbrydelsen. En genopkobling af VPN gendanner en rute og gendanner ikke den forbindelsestilstand, som applikationerne og den fjerne side har samlet på den gamle. Det er to forskellige ting at reparere, og forveksler man dem, ryger man tilbage i VPN-indstillingerne uden grund.

Én test skiller dem rent, og den tager ti sekunder. Send en ny forespørgsel til samme destination, mens den gamle hænger.

Hvad overlever en genopkobling, og hvad gør ikke

En tunnel er et sæt ruter, nøgler og adresser, og en genopkobling kan gendanne alle tre, mens hvert etableret flow forbliver dødt. Styresystemet holder en socket åben, fordi applikationen bad om det, og den sockets timeout kan være minutter eller timer væk. Under det har modparten glemt flowet, en oversættelsespost er udløbet, eller ruten går nu gennem et endepunkt, som aldrig har set håndtrykket. Intet i genopkoblingsforløbet går applikationens sockets igennem og reparerer dem.

Nogle klienter tilføjer et hook, der dropper forældede forbindelser ved genopkobling, og de fleste gør ikke. Adfærden her varierer efter klient, platform og version.

Den fjerne side har også glemt dig

Den fjerne ende holder sin egen tilstand: en TLS-session, en TCP-kontrolblok og muligvis en mapping-post, der binder din adresse og port til flowet. En oversættelsesenhed undervejs kan lade den mapping udløbe i hullet, selv når tunnelen genetableres hurtigt. Når mappingen er væk, ankommer pakker til et flow, serveren ikke længere kender, og svaret kan være en reset, klienten aldrig viser. Applikationer rapporterer dette som en fastlåsning og ikke som en fejl, fordi de stadig venter på en socket, der aldrig svarer.

Idle-timeouts på serversiden gør det samme efter deres egen tidsplan, og derfor kan en session dø helt uden en netværkshændelse. En forbindelse, der har været inaktiv længere, end serveren forventer, er allerede væk, før du opdager, at tunnelen har flyttet sig.

En ny forespørgsel er testen, der skiller dem

Send en ny forespørgsel til samme vært, mens den gamle stadig hænger, og hold øje med begge. Hvis den nye forespørgsel lykkes, virker tunnelen, ruten og navneopløsningen, og fejlen er begrænset til det forældede flow. Hvis den nye forespørgsel også fejler, har du et ruteproblem, og applikationens sessionstilstand er et falsk spor.

Lad enhver blokering af direkte trafik blive stående under testen. En forespørgsel, der lykkes gennem en tilfældig reservevej, beviser intet om tunnelen.

Bekræft med en ny forbindelse, ikke den gamle

Kommandoerne nedenfor viser de sockets, der stadig er åbne, starter én ny forespørgsel og tjekker, om sessionstabellen stadig har en post for flowet. Kør den første før og efter genopkoblingen, så forskellen er synlig. Erstat værten 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 etableret socket uden trafik i bevægelse er det signatur, du skal lede efter, og en ny forespørgsel, der returnerer en statuskode, viser, at ruten er levende. Forbindelsestabellen svarer på, om noget stadig mapper flowet, og det er den del, klienten ikke kan se. Resolver-forespørgslen dækker den anden halvdel af en sideindlæsning, fordi en navnefejl og en fastlåst forbindelse ser ens ud i en browser. Sammen skiller de fire output en forældet session fra en brudt tunnel.

Noter afbrydelsestidspunktet, genopkoblingstidspunktet og forskellen mellem den gamle og den nye forespørgsel. Den note gør en vag klage til en rapport, nogen kan handle på.