WAN-IP geändert und Tunnel abgebrochen: die Prüfungen in Reihenfolge

Halten Sie das WAN-Ereignis fest und schauen Sie dann, was ihm nicht gefolgt ist: veraltete Übersetzungseinträge, an das alte Gateway gebundene Routen, Peers, die noch an die alte Adresse senden.

Der Tunnel bricht ab, der Router protokolliert eine Wiederverbindung, und im LAN hat sich nichts bewegt. Eine neue WAN-Adresse macht die äußere Verbindung ungültig, ohne innen etwas zu ändern: Die Quelladresse des Clients hat sich geändert, der alte NAT-Zustand zeigt auf eine Quelle, die es nicht mehr gibt, und der entfernte Peer sendet möglicherweise noch an die vorherige Adresse. Die Wiederherstellung ist normales Verhalten, und die nützliche Frage ist, welcher Zustand nicht aktualisiert wurde.

Benennen Sie das Ereignis, bevor Sie das Protokoll lesen

Prüfen Sie, was auf der Zugriffsschicht tatsächlich passiert ist. Eine Verlängerung des ISP-Lease ist ein Ereignis. Eine PPPoE-Sitzung, die sich neu verbunden hat, ist ein anderes. Ein neu gestartetes Glasfasermodem oder ein WAN-Failover von einem Uplink auf einen anderen ändert die äußere Adresse oder ihren Pfad auf eine dritte Weise. Sie sind nicht dasselbe Ereignis und hinterlassen nicht dieselben Rückstände.

Eine Wiederverbindungszeile im VPN-Protokoll ist ebenfalls kein Beweis für eine WAN-Änderung. Ein Leerlauf-Timeout, ein Reauthentifizierungsintervall und die Erkennung toter Peers erzeugen alle Wiederverbindungen ohne jede Adressänderung. Vergleichen Sie Zeitstempel aus dem Zugriffsprotokoll mit dem VPN-Protokoll, bevor Sie etwas schließen, und halten Sie das Vergleichsfenster weit genug, um eine Änderung zu erfassen, die nachts passiert ist.

Roaming und Wiederverbindung sind verschiedene Protokolle

WireGuard hat authentifiziertes Roaming in das Protokoll eingebaut: Wenn ein Peer ein korrekt authentifiziertes Paket von einer neuen Quelladresse erhält, aktualisiert er den Endpunkt dieses Peers. Der WireGuard-Schnellstart beschreibt die Peer-Konfiguration, die das ermöglicht, weshalb sich ein Client auf einer wechselnden Adresse oft ohne sichtbaren Neustart erholt.

OpenVPN verhält sich standardmäßig anders. Eine UDP-Sitzung kann enden und sich neu verbinden, und das optionale Float-Verhalten erlaubt es einem authentifizierten Peer, von einer neuen Adresse fortzufahren, wo die Konfiguration es zulässt. TCP-basierte Tunnel sind strenger, weil die Verbindung selbst an das Adresspaar gebunden ist. Dieser Unterschied entscheidet, ob die Wiederherstellung unsichtbar wirkt oder sich jedes Mal im Protokoll meldet.

Keines der beiden Verhaltensweisen sagt etwas über die Anwendungen im Inneren. Ein wiederhergestellter Tunnel stellt keine TCP-Sitzung wieder her, die der Peer bereits als tot betrachtet hat.

Zustand, den der Tunnel nicht besitzt

Übersetzungs- und Routingzustand überlebt die Wiederverbindung auf Weisen, die Menschen überraschen. Ein conntrack-Eintrag, der für die alte Quelle angelegt wurde, hält den Antwortpfad an eine Adresse gebunden, die es nicht mehr gibt, und er läuft nach seinem eigenen Zeitplan ab, nicht wenn der Tunnel zurückkam. Ein Neustart des Tunnel-Dienstes verkürzt diese Wartezeit nicht, sodass eine reparierte Verbindung eine Weile noch kaputt aussehen kann.

Routen und Regeln der Richtlinie können auf das alte Gateway oder Interface verweisen. Ein Regelsatz, der vor einem WAN-Wechsel korrekt war, kann auf ein Gerät zeigen, das jetzt ausgefallen ist, was einen Tunnel ergibt, der sich als verbunden meldet, und Verkehr, der nirgendwohin geht. Dynamisches DNS für einen Server, den Sie hosten, ist ein separates Problem von einem Client, der eine neue Quelle erhält. Der Eintrag muss aktualisiert werden, damit entfernte Clients Sie finden, und keine Konfiguration auf Client-Seite gleicht eine Adresse aus, die die Übersetzung weiter oben nicht weiterleitet.

Ordnen Sie die Prüfungen von außen nach innen

Die Reihenfolge unten läuft von der äußeren Verbindung nach innen, und das Anhalten beim ersten fehlschlagenden Schritt macht sie nützlich: Jeder Durchlauf schließt die Schicht darüber aus. Halten Sie diese Reihenfolge ein, auch wenn der Fehler offensichtlich aussieht.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

Der erste Befehl zeigt den aktuellen Endpunkt und das Alter des Handshakes für jeden Peer. Der zweite und dritte zeigen, ob das äußere Interface und die Route zum Endpunkt noch Sinn ergeben. Die conntrack-Zahl ist eine grobe Prüfung für Zustand, der von der vorherigen Adresse übrig ist, und das Journal ist der Ort, an dem der Grund der Wiederverbindung festgehalten wird.

Testen Sie dann von einem LAN-Client statt vom Router. Ein Ping der vom Router selbst stammt nutzt einen anderen Pfad als weitergeleiteter Verkehr, sodass ein erfolgreicher Router-Ping beweist, dass der Tunnel existiert, und nichts über die Erreichbarkeit des Clients.

Legen Sie das erwartete Verhalten fest und schreiben Sie es auf

Wiederverbinden ist für die meisten Bereitstellungen korrektes Verhalten, das Ziel ist also nicht, es zu verhindern. Legen Sie stattdessen fest, was während der Lücke mit dem Verkehr geschehen soll: stoppen, halten oder auf einen anderen Pfad ausweichen. Diese Entscheidung gehört in die Firewall und die Routing-Richtlinie, nicht in das VPN-Profil.

Halten Sie die Zugriffsereignisse und die Wiederverbindungszeiten eine Woche lang gemeinsam fest. Wiederholte Änderungen ohne passendes Zugriffsereignis deuten auf den Zugriffsdienst hin, und der Austausch des VPN-Profils behebt keinen Uplink, der ständig neu verhandelt. Ein einzelnes Paar Einträge in derselben Minute klärt die Frage für diesen Vorfall und gibt dem nächsten eine Basislinie.

Ähnliche Artikel