Hängendes VPN nach einem Router-Neustart: drei Dinge, die sich geändert haben

Der Router ist fertig gebootet, der Laptop tritt demselben SSID wieder bei, und das VPN steht auf verbunden, ohne dass sich etwas bewegt. Das gespeicherte Profil ist unversehrt. Was darunter abgelaufen ist, war der Pfad, und der Client hält noch den Zustand, den er für den alten aufgebaut hat.

Drei Bedingungen entscheiden über die Lösung. Prüfen Sie sie der Reihe nach, denn die späteren sind vergeudete Mühe, wenn die erste den Stillstand bereits erklärt.

Bedingung eins: die lokale Adresse hat sich geändert

Ein Neustart kann der Maschine eine andere Adresse geben. Ein VPN, das mit einem festen lokalen Endpunkt konfiguriert ist, nutzt dann weiter eine Bindung, die nicht mehr existiert. Dasselbe gilt für einen Client, der seinen Socket an die alte Adresse gebunden hat. Die Tunnelschnittstelle kann oben bleiben, während jedes von ihr erzeugte Paket ins Leere geht.

Vergleichen Sie die Adresse, die der Client nutzt, mit der Adresse, die die Schnittstelle gerade hat. Eine Standardroute, die auf ein Gateway zeigt, das sich ebenfalls geändert hat, ist dieselbe Art Problem unter anderem Namen.

ip -4 addr show
ip route show default
ip route get 203.0.113.10

Bedingung zwei: das übersetzte Mapping ist weg

Heimrouter übersetzen ausgehende Ströme, und diese Mappings leben im Speicher. Ein Neustart löscht jedes einzelne davon. Für eine neue Verbindung ist das harmlos, für einen Tunnel tödlich, der glaubt, sein bestehender Strom sei noch gültig. Dann sieht die Gegenseite nichts, und der Client bekommt nie einen Fehler, auf den er reagieren könnte.

Hier bleibt ein Tunnel ohne Keepalives still hängen, statt laut zu scheitern. WireGuards dokumentierte Einschränkungen beschreiben dieselbe Form des Fehlers. Ein falscher Endpunktzustand erzeugt verworfene Pakete statt einer Diagnose.

Ein dauerhaftes Keepalive von 25 Sekunden ist die übliche Abhilfe, weil es das Mapping auffrischt, bevor ein Leerlauf-Timeout ablaufen kann. Es repariert kein Mapping, das bereits weg ist. Kombinieren Sie das Keepalive mit Wiederverbindungslogik, statt es als Lösung zu behandeln.

Bedingung drei: die öffentliche Adresse hat sich geändert

Wenn sich die eigene externe Adresse des Routers geändert hat, sieht alles auf der anderen Seite, das nach Quelladresse filtert, jetzt eine andere Gegenseite. Der Tunnel kann hochkommen, und der Server verwirft den Verkehr trotzdem; das sieht nach einem defekten Client aus und ist in Wahrheit eine Richtlinie am anderen Ende.

Notieren Sie die externe Adresse vor und nach dem Neustart. Wenn sich beide unterscheiden, wandert die Frage vom Client zu dem, der die Allowlist pflegt, und das Zurücksetzen der Zugangsdaten auf dem Laptop kann nicht helfen.

In der richtigen Reihenfolge wiederherstellen

Schließen Sie zuerst eine nötige Captive-Portal-Anmeldung ab, und lassen Sie den Client dann über sein unterstütztes Verfahren neu verbinden, statt den Prozess zu beenden. Beobachten Sie, ob Identität und Datenverkehr beide zurückkommen, denn das sind zwei verschiedene Phasen derselben Verbindung.

Eine zwischengespeicherte Seite beweist nichts, und eine Chat-App, die sich selbst neu verbunden hat, ebenso wenig. Testen Sie den Endpunkt, der Ihnen wirklich wichtig ist, mit einer frischen Anfrage. Lassen Sie die Direktverkehrsrichtlinie während der Unterbrechung in Kraft, denn ein Wiederverbindungsversuch ist keine Sperre.

Wenn sich das nach jedem Neustart wiederholt, zählt die Aufzeichnung mehr als der neue Versuch. Notieren Sie lokale Adresse, Gateway, externe Adresse und Clientzustand vorher und nachher und vergleichen Sie dann die beiden Spalten. Das macht aus einer vagen Beschwerde einen Lebenszyklusfehler, den jemand beheben kann, und es verhindert, dass die Zertifikate wegen eines Mapping-Timeouts zum dritten Mal ersetzt werden.