VPN bricht nach einer DHCP-Erneuerung ab? Vergleichen Sie die Adressen

Lease-Erneuerung und VPN-Ausfall erscheinen in Protokollen oft genug gemeinsam, dass Menschen daraus schließen, das eine verursache das andere. Die zeitliche Koinzidenz ist real; die Kausalität meist nicht. Eine Erneuerung ist eine Unicast-Anfrage an den Server, der die Lease ausgegeben hat, dieselbe Bindung weiter zu verwenden, und der Server kann sie verlängern, ohne dass der Client eine einzige Adresse ändert. Die eigenen Werte des Clients rund um das Ereignis zu prüfen, trennt eine still erneuerte Lease von einem Netzwerk, das sich unter einem laufenden Tunnel tatsächlich verändert hat.

Beginnen Sie beim Client, der ausgefallen ist

Öffnen Sie zuerst das Verbindungsprotokoll des Clients und notieren Sie den Zeitpunkt des Abbruchs auf die Sekunde. Öffnen Sie dann das Netzwerkprotokoll des Betriebssystems für dieselbe Minute und lesen Sie der Reihe nach, was die Schnittstelle getan hat. Diese Reihenfolge ist die ganze Untersuchung: ein DHCP-Ereignis vor der Trennung, eine Trennung vor dem DHCP-Ereignis und zwei Ereignisse ohne etwas dazwischen sind drei verschiedene Befunde. Eine Protokollzeile, die nur die Lease erwähnt, während der Tunnel bereits neu verband, ist Dekoration, kein Beweis.

Schreiben Sie die Zeitachse mit, statt sie im Kopf zu behalten. Zeitstempel verschiedener Werkzeuge stimmen selten exakt überein, und die Abweichung selbst ist manchmal die Erklärung.

Vergleichen Sie die vier Werte rund um das Ereignis

Vier Werte beschreiben die lokale Seite einer Verbindung gut genug, um eine echte Änderung zu erfassen: die Schnittstellenadresse, das Standard-Gateway, die Resolver-Liste und den Betriebszustand der Schnittstelle. Erfassen Sie sie innerhalb einer Minute nach dem Abbruch und vergleichen Sie sie mit einer Aufnahme, die bei gesundem Tunnel entstanden ist.

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

Eine unveränderte Adresse mit unverändertem Gateway und veränderter Resolver-Liste deutet auf Namensauflösung statt Routing hin, und der Tunnel kann überlebt haben, während Anwendungen keine Hosts mehr fanden. Ein verändertes Gateway bedeutet, dass sich der Weg aus dem lokalen Netz verschoben hat, was ausreicht, um eine Route ungültig zu machen, die auf das vorherige zeigte. Wenn alle vier Werte mit der gesunden Aufnahme übereinstimmen, ist die Lease nicht Ihre Ursache, und die eigene Wiederverbindungslogik des Clients wird zum Thema. Nehmen Sie den Vergleich auf, solange der Fehler sichtbar ist, denn eine gesunde Aufnahme nach einem Neustart hat eine andere Adresshistorie und wird nicht passen.

Was eine Erneuerung ändern kann und was nicht

RFC 2131 beschreibt die Erneuerung als Anfrage an den ursprünglichen Server zur Hälfte der Lease-Zeit, mit Neubindung an einen beliebigen Server bei sieben Achteln, falls der erste Versuch unbeantwortet bleibt. Keiner der Schritte verlangt, dass der Client eine andere Adresse erwirbt, und ein kooperativer Server verlängert normalerweise die bestehende Bindung. Eine echte Adressänderung kommt meist über einen anderen Weg: ein Server lehnt die Erneuerung ab, ein Client hat seinen Zustand verloren und neu begonnen, oder ein Netz hat das Gerät in ein anderes Segment verschoben.

Die öffentliche Seite der Verbindung kann sich ohne jede lokale Änderung ändern. Hinter Carrier-Grade-Übersetzung kann die Adresse, die der VPN-Peer sieht, unabhängig von allem, was die lokale Lease getan hat, neu zugewiesen werden, und diese Neuzuweisung sieht von innen im Client identisch aus wie ein lokaler Netzwerkfehler. Den lokal gemeldeten mit einem peer-seitig beobachteten Adresswert zu vergleichen, ist der einzige Weg, sie zu unterscheiden.

Wenn der Client sich nicht anpasst

Ein Client, der seinen Transport an die alte Adresse gebunden, eine veraltete Route zum Peer zwischengespeichert oder eine Schnittstellenidentität gespeichert hat, versucht möglicherweise weiter einen Weg, den es nicht mehr gibt. Das ist ein Anpassungsfehler, und er zeigt sich als wiederholte Übertragungen an eine Adresse, die der Host nicht mehr erreichen kann. Manche Clients lösen das konstruktiv: WireGuard etwa aktualisiert den Endpunkt eines Peers, wenn ein korrekt authentifiziertes Paket von einer neuen Quelle ankommt.

Ein manueller Neustart, der den Dienst wiederherstellt, ist ein Hinweis darauf, wo die Anpassung versagt hat, kein Beweis, dass Leases und Tunnel unvereinbar sind. Lassen Sie die Sperrrichtlinie beim Testen bestehen, sonst wird der Test selbst zu einem Ausfall mit anderer Ursache. Halten Sie fest, ob der Client sich selbst erholt hat, wie lange es dauerte und welche Adresse er erneut versuchte; diese Abfolge sagt Ihnen mehr als der in der Oberfläche angezeigte Trennungsgrund.

Wiederholen Sie das Ereignis, bevor Sie es beschuldigen

Reproduzieren Sie die Bedingung, statt auf den Zeitplan zu warten: Geben Sie die Lease frei und erneuern Sie sie, oder erzwingen Sie das entsprechende kontrollierte Ereignis, und beobachten Sie, ob der Tunnel überlebt. In einem verwalteten Netz koordinieren Sie jede Adressänderung mit dem Netzverantwortlichen, denn eine willkürliche statische Zuweisung kann mit einem Gerät kollidieren, das diese Adresse bereits hält.

Wiederholen Sie nach einer unterstützten Korrektur dasselbe Ereignis und testen Sie dann eine Anwendung und eine Namensauflösung, denn ein Tunnel, der sich wieder verbindet, aber DNS bricht, besteht einen schwächeren Test als den, der zählt. Melden Sie die konkrete beobachtete Änderung mit ihrem Zeitstempel, statt die geplante Lease als Ursache zu benennen. Der Unterschied zwischen diesen beiden Berichten ist, ob die nächste Person den Fehler reproduzieren kann oder nur das Gerücht.