Warum dein VPN abreißt, wenn Wi-Fi wechselt oder Ethernet eingesteckt wird

Zwei Dinge werden als ein Fehler gemeldet: Das Notebook ist in ein anderes Wi-Fi-Netz gewechselt, oder ein Kabel wurde eingesteckt, während Wi-Fi weiterlief. Der Client sagt weiterhin verbunden, das Symbol sieht gesund aus, und der Tunnel überträgt nichts. Unter der Oberfläche können sich nur drei Stücke Zustand verschieben - die Verbindung, die lokale Adresse, die Standardroute - und welches sich verschoben hat, entscheidet, ob sich der Tunnel von selbst erholt oder ein neues Verbinden braucht. Ich prüfe sie in dieser Reihenfolge, weil Änderungen an Kontoeinstellungen noch nie eines davon behoben haben.

Verbindung, Adresse und Route verschieben sich unabhängig

Roaming zwischen Access Points im selben Netz ist normalerweise ein L2-Ereignis. Das Funkmodul reassoziiert, die Schnittstelle behält ihre Adresse und ihr Gateway, und nichts, wovon der Tunnel abhängt, ändert sich, weshalb ein Gang durch ein großes Büro manchmal unbemerkt bleibt. Der Beitritt zu einer anderen SSID ist das nicht: Die alte Schnittstelle kann heruntergehen, DHCP vergibt eine neue Adresse, ein neues Gateway und neue Resolver, und der äußere Flow, den der Tunnel nutzte, existiert nicht mehr.

Ethernet fügt eine dritte Form hinzu. Wi-Fi fällt nie aus, es wird also überhaupt kein Verbindungsereignis ausgelöst, doch die kabelgebundene Schnittstelle erscheint mit eigener Adresse und gewinnt oft die Standardroute über die Metrik. Der Tunnel läuft weiter über einen Pfad, der nicht mehr bevorzugt wird, oder der Client hält seinen Socket an das WLAN geheftet, in dem er gestartet ist. Vom Browser aus sehen beide gleich aus: Seiten stocken in dem Moment, in dem das Kabel einrastet.

Die erste Frage ist also nicht, ob sich Wi-Fi geändert hat. Sie ist, ob sich die Adresse, an die du gebunden bist, oder die Route zum Endpunkt geändert hat, während der Tunnel lief.

Der äußere Socket ist an eine Adresse geheftet, die gerade verschwunden ist

Jeder Tunnel ist ein äußerer Flow: eine lokale Adresse und ein Port, die mit Adresse und Port des Servers sprechen. Unter Linux ist das ein UDP-Socket, gebunden an die alte Quelle; wird die Schnittstelle entfernt, die die Adresse hält, schlagen Sends entweder mit EADDRNOTAVAIL fehl oder verlassen die neue Schnittstelle mit einer Quelle, die der Server nie gesehen hat.

Die Gegenseite hält ihre eigene Heftung. Eine IKEv2-SA ohne MOBIKE wird über das Adresspaar identifiziert, und eine OpenVPN-Sitzung ist an die Peer-Adresse gebunden, die sie gelernt hat, und ein NAT-Mapping gehört zu der privaten Adresse, dem Port und der öffentlichen Adresse, die es erzeugt haben. Wechsle hinter ein anderes NAT, und jede Antwort geht an ein Mapping, das nicht mehr existiert. Auf deiner Maschine ist nichts falsch konfiguriert; das Fünftupel zeigt auf ein Netz, das du verlassen hast.

Lies den Zustand, bevor du theoretisierst:

• ss -unp zeigt die lokale Adresse und den Port, die jeder Tunnel-Socket tatsächlich hält.
• ip route get 203.0.113.10 gibt die Quelladresse und das Gerät aus, die der Kernel jetzt für den Endpunkt verwenden würde.
• wg show wg0 endpoints, swanctl --list-sas oder das Client-Log zeigt die Peer-Adresse, mit der die Gegenseite zu sprechen glaubt.

Wenn Socket-Adresse und Routenabfrage nicht übereinstimmen, hast du den Bruch gefunden, und keine Änderung an Zugangsdaten wird ihn berühren.

Was jedes Protokoll mit einer neuen Quelladresse macht

Clients verdauen die Änderung unterschiedlich stark, und die Tabelle ist das, womit ich die Client-Konfiguration vergleiche, statt aus dem Wiederverbindungsverhalten zu raten.

Die Roaming-Regel von WireGuard funktioniert nur in eine Richtung: Der Client muss zuerst von der neuen Adresse senden. Ein Socket, der noch an die alte Schnittstelle gebunden ist, tut das nie, weshalb ein Tunnel lebendig aussehen kann, während sein Handshake-Timer altert. Protokollbeschreibung nennt die Bedingung für die Endpunkt-Aktualisierung genau, und sie ist es wert, gelesen zu werden, bevor du eine Konfiguration änderst.

MOBIKE wird ausgehandelt, nicht angenommen. Bietet der Server es nicht an, muss der Client neu aufbauen, und das ist eine Tatsache, die du aus der SA-Liste oder dem Log bestätigst, statt sie aus einem drehenden Rad zu schließen.

Die Routenpräferenz entscheidet den Pfad, nicht das Wi-Fi-Symbol

Sind beide Schnittstellen oben, wählt der Kernel nach Metrik und Präfixlänge. ip route show default listet die Kandidaten und ip route get 203.0.113.10 löst die tatsächliche Entscheidung auf, einschließlich der Quelladresse. Eine kabelgebundene Standardroute mit Metrik 100 und eine drahtlose mit 600 bedeuten, dass der Endpunkt sich in dem Moment verschiebt, in dem das Kabel sitzt, während jede Anwendung, die früher einen Socket geöffnet hat, ihre alte Quelle behält.

Windows macht dasselbe mit automatischen Schnittstellen-Metriken, beeinflusst von der Linkgeschwindigkeit. Get-NetRoute -DestinationPrefix 0.0.0.0/0 sortiert die Kandidaten und Find-NetRoute -RemoteIPAddress 203.0.113.10 liefert die Schnittstelle und Quelle zurück, die der Stack wählen würde. Ein Client, der seinen äußeren Socket an eine Schnittstelle bindet, nutzt sie weiter, nachdem die Metrik kippt; das ist eine Bindungsentscheidung, kein Routingfehler.

Android macht die Trennung sichtbar: ConnectivityManager meldet verfügbare Netze und eine separate Standardverbindung, und eine VPN-App, die einen Socket an ein Network-Objekt bindet, hält diese Bindung, bis sie neu bindet. Unter macOS scutil --nwi gibt die primäre Schnittstelle und die Reihenfolge aus, die das System verwenden würde.

DNS, MTU und IPv6 verschieben sich mit dem Anschluss

Ein neuer Anschluss bringt neue Resolver. Mit systemd-resolved ist DNS pro Link, resolvectl status zeigt, welcher Link einen Namen beantwortet, und ein Gästenetz, das seinen eigenen Resolver ausgibt, kann das vom Tunnel geschobene DNS ungenutzt lassen, bis der Link wieder bevorzugt wird. Ein Captive Portal macht es schlimmer: Die erste HTTPS-Anfrage beantwortet das Portal statt der Endpunkt, und der Client vermerkt einen toten Server.

Auch die Pfad-MTU ändert sich. Ethernet und Wi-Fi tragen meist 1500 Byte, PPPoE 1492, und Mobilfunklinks oft weniger. Ein Tunnel, der eine kleinere MTU erbt, stockt bei großen Paketen, während kleine Anfragen durchgehen, was wie eine halb kaputte Verbindung wirkt. ping -M do -s 1472 203.0.113.10 sendet ein Paket mit 1500 Byte und gesetztem DF; Stille bedeutet, dass der Pfad kleiner ist, als du angenommen hast.

IPv6 ist die andere Hälfte. Ein Netz, das ein neues Präfix ausgibt, ändert die Quelle, die ein Dual-Stack-Client nutzen würde, und ein reiner v4-Tunnel lässt v6-Verkehr draußen, bis die Policy nachzieht. ip -6 route show default und ip -6 addr show beantworten, ob der neue Link überhaupt einen v6-Pfad hat.

Reproduziere den Übergang, statt ihn zu beschreiben

Wähle eine harmlose Anfrage und führe dieselben drei Befehle beiderseits der Änderung aus: ip -br addr, ip route show default, ip route get 203.0.113.10. Beobachte dann, ob der Tunnel noch Pakete sendet - tcpdump -ni any udp port 51820 für WireGuard, den passenden Port für alles andere. Pakete, die von der alten Quelle ausgehen, bedeuten ein Bindungsproblem. Pakete von der neuen Quelle ohne Antwort bedeuten die Gegenseite oder das NAT dazwischen.

Notiere, welches Ereignis mit dem ersten Fehler zusammenfiel: Verbindungsabbruch, Adresswechsel oder Wechsel der Standardroute. Die zeigen auf verschiedene Verantwortliche - einen Client, der neu binden muss, eine Adresse, die neu bezogen werden muss, oder eine Route, die zu einer Konfigurationsdatei gehört und nicht zu einer dauerhaften Bypass-Regel.

Bevor du es als behoben bezeichnest, bestätige, dass der Block für direkten Verkehr während der Lücke noch hält und dass Namen über den neuen Anschluss aufgelöst werden. Hält der Client nach dem Wechsel den alten Endpunkt, repariere zuerst die Roaming- oder Float-Einstellung. Roamt er korrekt und bekommt weiterhin keine Antwort, sieh dir die Peer-Identität des Servers und das NAT auf dem Pfad an, und halte beide Netzkontexte im Bericht fest, damit die nächste Person sie vergleichen kann.