VPN: et återanslöt, men appens session misslyckas fortfarande

Tunneln är tillbaka, klienten säger ansluten, och webbläsaren snurrar fortfarande på en sida den laddade före avbrottet. En VPN-återanslutning återställer en väg och återställer inte det anslutningstillstånd som applikationerna och fjärrsidan byggde upp på den gamla. Det är två olika saker att reparera, och att blanda ihop dem skickar tillbaka dig till VPN-inställningarna utan anledning.

Ett test skiljer dem rent, och det tar tio sekunder. Skicka en ny begäran till samma destination medan den gamla hänger.

Vad som överlever en återanslutning och vad som inte gör det

En tunnel är en uppsättning rutter, nycklar och adresser, och en återanslutning kan återställa alla tre medan varje etablerat flöde förblir dött. Operativsystemet håller en socket öppen eftersom applikationen bad om det, och den socketens timeout kan ligga minuter eller timmar bort. Under det har motparten glömt flödet, en översättningspost har löpt ut, eller vägen går nu genom en ändpunkt som aldrig såg handskakningen. Inget i återanslutningssekvensen går igenom applikationens sockets och reparerar dem.

Vissa klienter lägger till en krok som släpper gamla anslutningar vid återanslutning, och de flesta gör det inte. Beteendet här varierar med klient, plattform och version.

Fjärrsidan glömde dig också

Fjärränden håller sitt eget tillstånd: en TLS-session, ett TCP-kontrollblock och kanske en mappningspost som binder din adress och port till flödet. En översättningsenhet längs vägen kan låta den mappningen löpa ut under luckan även när tunneln återupprättas snabbt. När mappningen är borta kommer paket för ett flöde som servern inte längre känner igen, och svaret kan vara en reset som klienten aldrig visar. Applikationer rapporterar detta som en låsning och inte som ett fel, eftersom de fortfarande väntar på en socket som aldrig kommer att svara.

Inaktivitetstimeouts på serversidan gör samma sak enligt sitt eget schema, och därför kan en session dö utan någon nätverkshändelse alls. En anslutning som varit inaktiv längre än servern förväntar sig är redan borta innan du märker att tunneln har flyttat sig.

En ny begäran är testet som skiljer dem

Skicka en ny begäran till samma värd medan den gamla fortfarande hänger, och följ båda. Om den nya begäran lyckas fungerar tunneln, rutten och namnutlösningen, och felet begränsas till det gamla flödet. Om den nya begäran också misslyckas har du ett vägproblem och applikationens sessionstillstånd är ett falskt spår.

Låt varje blockering av direkt trafik stå kvar under testet. En begäran som lyckas via en oavsiktlig reservväg bevisar ingenting om tunneln.

Bekräfta med en ny anslutning, inte den gamla

Kommandona nedan visar socketarna som fortfarande är öppna, startar en ny begäran och kontrollerar om sessionstabellen fortfarande har en post för flödet. Kör den första före och efter återanslutningen så att skillnaden syns. Byt ut värden och porten mot din egen tjänst.

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 etablerad socket utan trafik som rör sig är signaturen du letar efter, och en ny begäran som returnerar en statuskod visar att vägen lever. Anslutningstabellen svarar på om något fortfarande mappar flödet, och det är den del som klienten inte kan se. Resolverfrågan täcker den andra halvan av en sidladdning, eftersom ett namnfel och en fastnad anslutning ser likadana ut i en webbläsare. Tillsammans skiljer de fyra utskrifterna en gammal session från en trasig tunnel.

Anteckna avbrottstiden, återanslutningstiden och skillnaden mellan den gamla och den nya begäran. Den anteckningen gör ett vagt klagomål till en rapport någon kan agera på.