VPN neu verbunden, doch die App-Sitzung scheitert weiterhin

Der Tunnel kommt zurück, der Client meldet „verbunden“, und der Browser dreht sich weiter auf einer Seite, die er vor dem Abbruch lud. Ein VPN-Reconnect stellt einen Pfad wieder her und stellt nicht den Verbindungszustand wieder her, den Anwendungen und Gegenseite auf dem alten aufgebaut haben. Das sind zwei verschiedene Dinge zum Reparieren, und wer sie verwechselt, landet ohne Grund wieder in den VPN-Einstellungen.

Ein Test trennt beide sauber, und er dauert zehn Sekunden. Senden Sie eine neue Anfrage an dasselbe Ziel, während die alte noch hängt.

Was einen Reconnect übersteht und was nicht

Ein Tunnel ist eine Menge von Routen, Schlüsseln und Adressen, und ein Reconnect kann alle drei wiederherstellen, während jeder etablierte Flow tot bleibt. Das Betriebssystem hält einen Socket offen, weil die Anwendung darum gebeten hat, und das Timeout dieses Sockets kann Minuten oder Stunden entfernt sein. Darunter hat der Peer den Flow vergessen, ein Übersetzungseintrag ist abgelaufen, oder der Pfad läuft jetzt über einen Endpunkt, der den Handshake nie gesehen hat. Nichts in der Reconnect-Sequenz geht die Sockets der Anwendung durch und repariert sie.

Manche Clients fügen einen Hook hinzu, der beim Reconnect veraltete Verbindungen verwirft, und die meisten nicht. Das Verhalten unterscheidet sich hier je nach Client, Plattform und Version.

Die Gegenseite hat auch Sie vergessen

Das ferne Ende hält eigenen Zustand: eine TLS-Sitzung, einen TCP-Kontrollblock und womöglich einen Mapping-Eintrag, der Ihre Adresse und Ihren Port an den Flow bindet. Ein Übersetzungsgerät auf dem Pfad kann dieses Mapping während der Lücke ablaufen lassen, selbst wenn der Tunnel schnell wieder steht. Ist das Mapping weg, kommen Pakete für einen Flow an, den der Server nicht mehr kennt, und die Antwort kann ein Reset sein, den der Client nie anzeigt. Anwendungen melden das als Hänger und nicht als Fehler, weil sie noch auf einen Socket warten, der nie antworten wird.

Idle-Timeouts auf Serverseite tun dasselbe nach ihrem eigenen Zeitplan, weshalb eine Sitzung ohne jedes Netzwerkereignis sterben kann. Eine Verbindung, die länger inaktiv war, als der Server erwartet, ist schon weg, bevor Sie merken, dass der Tunnel sich bewegt hat.

Eine neue Anfrage ist der Test, der beide trennt

Senden Sie eine neue Anfrage an denselben Host, während die alte noch hängt, und beobachten Sie beide. Klappt die neue Anfrage, dann funktionieren Tunnel, Route und Namensauflösung, und der Fehler beschränkt sich auf den veralteten Flow. Scheitert auch die neue Anfrage, haben Sie ein Pfadproblem, und der Sitzungszustand der Anwendung ist eine falsche Spur.

Lassen Sie jede Sperre für direkten Verkehr während des Tests bestehen. Eine Anfrage, die über einen versehentlichen Ausweichpfad gelingt, beweist nichts über den Tunnel.

Bestätigen Sie mit einer neuen Verbindung, nicht der alten

Die folgenden Befehle zeigen die noch offenen Sockets, starten eine neue Anfrage und prüfen, ob die Sitzungstabelle noch einen Eintrag für den Flow hält. Führen Sie den ersten vor und nach dem Reconnect aus, damit der Unterschied sichtbar wird. Ersetzen Sie Host und Port durch Ihren eigenen 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

Ein etablierter Socket ohne laufenden Verkehr ist die Signatur, nach der Sie suchen, und eine neue Anfrage, die einen Statuscode zurückgibt, zeigt, dass der Pfad lebt. Die Verbindungstabelle beantwortet, ob noch etwas den Flow abbildet, und das ist der Teil, den der Client nicht sehen kann. Die Resolver-Abfrage deckt die andere Hälfte eines Seitenaufrufs ab, denn ein Namensfehler und eine hängende Verbindung sehen im Browser gleich aus. Zusammen trennen diese vier Ausgaben eine veraltete Sitzung von einem kaputten Tunnel.

Notieren Sie den Zeitpunkt der Unterbrechung, den des Reconnects und den Unterschied zwischen alter und neuer Anfrage. Diese Notiz macht aus einer vagen Beschwerde einen Bericht, mit dem jemand arbeiten kann.