VPN opnieuw verbonden, maar de appsessie faalt nog steeds

De tunnel komt terug, de client meldt verbonden, en de browser draait nog op een pagina die hij voor de onderbreking laadde. Een VPN-herverbinding herstelt een pad en herstelt niet de verbindingsstatus die applicaties en de andere kant op het oude hebben opgebouwd. Dat zijn twee verschillende dingen om te repareren, en ze verwarren stuurt u zonder reden terug naar de VPN-instellingen.

Eén test scheidt ze schoon, en hij duurt tien seconden. Stuur een nieuw verzoek naar dezelfde bestemming terwijl het oude nog hangt.

Wat een herverbinding overleeft en wat niet

Een tunnel is een set routes, sleutels en adressen, en een herverbinding kan alle drie herstellen terwijl elke opgezette flow dood blijft. Het besturingssysteem houdt een socket open omdat de applicatie daarom vroeg, en de time-out van die socket kan minuten of uren verder liggen. Daaronder is de peer de flow vergeten, is een vertaalvermelding verlopen, of loopt het pad nu via een eindpunt dat de handshake nooit heeft gezien. Niets in de herverbindingsreeks loopt de sockets van de applicatie langs en repareert ze.

Sommige clients voegen een haak toe die bij herverbinding verouderde verbindingen laat vallen, en de meeste niet. Het gedrag hier verschilt per client, platform en versie.

De andere kant is u ook vergeten

Het verre uiteinde houdt eigen status bij: een TLS-sessie, een TCP-controleblok en mogelijk een mapping-vermelding die uw adres en poort aan de flow bindt. Een vertaalapparaat op het pad kan die mapping tijdens de leemte laten verlopen, ook als de tunnel snel terugkeert. Zodra de mapping weg is, komen er pakketten voor een flow die de server niet meer herkent, en het antwoord kan een reset zijn die de client nooit toont. Applicaties melden dit als een stilstand en niet als een fout, omdat ze nog wachten op een socket die nooit antwoordt.

Time-outs voor inactiviteit aan de serverkant doen hetzelfde volgens hun eigen schema, waardoor een sessie kan sterven zonder enige netwerkgebeurtenis. Een verbinding die langer inactief was dan de server verwacht, is al weg voordat u merkt dat de tunnel is verschoven.

Een nieuw verzoek is de test die ze scheidt

Stuur een nieuw verzoek naar dezelfde host terwijl het oude nog hangt, en kijk naar beide. Als het nieuwe verzoek slaagt, werken de tunnel, de route en de naamresolutie, en de fout blijft beperkt tot de oude flow. Als het nieuwe verzoek ook faalt, hebt u een padprobleem en is de sessiestatus van de applicatie een valse aanwijzing.

Laat elke blokkade van direct verkeer tijdens de test staan. Een verzoek dat via een toevallige uitwijkroute slaagt, bewijst niets over de tunnel.

Bevestig met een nieuwe verbinding, niet met de oude

De opdrachten hieronder tonen de sockets die nog open zijn, starten één nieuw verzoek en controleren of de sessietabel nog een vermelding voor de flow heeft. Voer de eerste voor en na de herverbinding uit zodat het verschil zichtbaar is. Vervang de host en de poort door uw eigen dienst.

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

Een opgezette socket zonder verkeer dat beweegt is de signatuur om naar te zoeken, en een nieuw verzoek dat een statuscode teruggeeft laat zien dat het pad leeft. De verbindingstabel beantwoordt of er nog iets de flow mapt, en dat is het deel dat de client niet kan zien. De resolver-query dekt de andere helft van een paginalading, want een naamfout en een vastgelopen verbinding zien er in een browser hetzelfde uit. Samen scheiden die vier uitvoer een oude sessie van een kapotte tunnel.

Noteer het tijdstip van de onderbreking, het tijdstip van de herverbinding en het verschil tussen het oude en het nieuwe verzoek. Die notitie maakt van een vage klacht een rapport waar iemand iets mee kan.