Router-VPN sieht nach einem Stromausfall gut aus? Prüfen Sie diese vier Schichten

Ein Router, der nach einem Ausfall aufleuchtet, hat seine Konfiguration wiederhergestellt, nicht seine Konnektivität. Nach einem Stromausfall kann ein Router sein gespeichertes VPN-Profil wiederherstellen, bevor die Abhängigkeiten bereit sind, die dieses Profil braucht: Das Modem stromaufwärts trainiert möglicherweise noch, die Uhr kann falsch sein, und die Authentifizierung ist vielleicht noch nicht abgeschlossen. Die Kontrollleuchte und die gespeicherte Konfiguration beschreiben die Absicht, nicht einen funktionierenden Tunnel. Prüfen Sie die vier Schichten unten der Reihe nach, statt das Profil zu ersetzen, denn das tun Leute als Zweites und bereuen es als Erstes.

Alles hier setzt voraus, dass Sie vor Ort sind oder einen Zugang haben, der nicht von dem Tunnel abhängt, den Sie testen. Wenn nicht, organisieren Sie das vor dem nächsten Ausfall.

Erste Schicht: Ist das WAN wirklich zurück

Fangen Sie beim Modem an, nicht beim Router-Dashboard. Ein Router, der das Booten abschließt, bevor sein Modem trainiert hat, zeigt eine gesunde Schnittstelle ohne etwas dahinter, und der Tunnel hat keinen Peer, den er erreichen kann. Bestätigen Sie, dass das Modem tatsächlich weiterleitet, und bestätigen Sie dann, dass der Router die erwarteten WAN-Einstellungen übernommen hat. Prüfen Sie auch, ob sich die WAN-Adresse geändert hat: Eine dynamische Adresse, die anders zurückkommt, kann eine adressbasierte Regel oder eine entfernte Positivliste ungültig machen, und von innen sieht das wie ein VPN-Fehler aus.

Manche Zugangsnetze verlangen nach einem Ausfall außerdem einen neuen Zulassungsschritt. Lesen Sie das Client-Log für die erste Fehlerstufe, statt zu raten: Der erste Fehler benennt die Schicht, und alles danach ist Folge. Notieren Sie die Adresse und das Zulassungsergebnis im Ticket, denn beide entscheiden, ob dasselbe Profil morgen funktioniert. Eine geänderte Adresse ist eine Fünf-Minuten-Korrektur und ein Zwei-Stunden-Rätsel.

Zweite Schicht: Prüfen Sie die Uhr vor dem Zertifikat

Eine falsche Uhr stört die Zertifikatsgültigkeit und alles Zeitbasierte, und ein eingebettetes Gerät, das ohne funktionierende Zeitquelle startet, kann eine Weile auf einem alten Datum sitzen. Dann schlägt die Zertifikatsprüfung aus einem Grund fehl, der nichts mit dem Berechtigungsnachweis zu tun hat. Ein Gültigkeitsfehler, dessen Daten um Jahre danebenliegen, deutet auf die Uhr; derselbe Fehler mit aktuellen Daten deutet auf das Zertifikat.

date -u
chronyc tracking

Nutzen Sie den unterstützten Zeitwiederherstellungsprozess und bestätigen Sie die Router-Uhr, bevor Sie das Profil anfassen. Die Validierung abzuschalten, um den Fehler zu umgehen, macht aus einem vorübergehenden Ordnungsproblem eine dauerhafte Schwächung, und das ist die häufigste schlechte Lösung in diesem Szenario. Hat das Gerät keine batteriegestützte Uhr, zählt die Startreihenfolge: Es braucht Netzwerkzugang, bevor es die Zeit synchronisieren kann, und Zeit, bevor es einen Tunnel validieren kann. Diese Reihenfolge ist zu korrigieren, wenn derselbe Fehler nach jedem Ausfall wiederkehrt.

Dritte Schicht: Lesen Sie, was der Tunnel sagt

Prüfen Sie den eigenen Zustand des Tunnels und das Ergebnis seines Handshakes oder seiner Authentifizierung, statt ob die Schnittstelle oben ist. Eine Schnittstelle kann ohne etablierten Peer existieren, und ein Client kann verbunden anzeigen, während die Schlüsselerneuerung fehlschlägt. Trennen Sie Transport-Timeouts von ausdrücklichen Ablehnungen: Ein Timeout deutet darauf hin, dass Pfad oder Peer noch nicht erreichbar sind, während eine Ablehnung bedeutet, dass die Gegenseite geantwortet und abgelehnt hat, meist wegen Zugangsdaten, eines Zertifikats oder einer Peer-Identität, die nicht mehr passt. Einen Nutzer wegen eines Timeouts durch einen Passwort-Reset zu schicken, kostet allen den Nachmittag.

Halten Sie die letzte bekannte gute Konfiguration bereit, damit Sie Felder vergleichen, statt sie zu rekonstruieren. Hat sich ein Feld geändert, ist diese Änderung der Befund. Vergleichen Sie es Feld für Feld mit der wiederhergestellten, statt nur die wiederhergestellte zu lesen. Die meisten Überraschungen nach einem Ausfall sind ein Feld, das still auf einen Vorlagenstandard zurückgefallen ist.

Vierte Schicht: Testen Sie von einem nachgelagerten Gerät

Öffnen Sie eine harmlose erlaubte Ressource von einem Client hinter dem Router und bestätigen Sie dann, welchen Ausgang oder welche private Route der Datenverkehr tatsächlich genutzt hat. Prüfen Sie DNS und jede Adressfamilie, die Sie abzudecken behaupten, denn die eigene Probe des Routers kann gelingen, während die Client-Richtlinie noch falsch ist — die Probe nutzt oft eine andere Quelle, eine andere Tabelle oder einen anderen Resolver-Pfad.

curl -s https://ifconfig.me
nslookup example.com

Ist der Tunnel ausgefallen und nicht bloß falsch konfiguriert, entscheiden Sie, ob betroffene Clients gesperrt werden müssen oder einen genehmigten Ausweichweg nutzen dürfen. Diese Wahl gehört in den Failover-Plan vor einem Ausfall, nicht in einen Chat-Thread während eines Ausfalls. Schreiben Sie den beobachteten Ausgang und Resolver ins Ausfall-Ticket. Zwei Zeilen ersparen der nächsten Person jetzt eine Stunde Rätselraten, welcher Pfad im Zeitfenster aktiv war.

Was zu reparieren ist, damit der nächste Ausfall kürzer wird

Wiederholt sich der Fehler, ist die Reparatur die Reihenfolge, nicht die Konfiguration: Bringen Sie das WAN hoch, dann die Zeit, dann den Tunnel, dann die Client-Richtlinie. Die meisten Router drücken das als Abhängigkeit oder Verzögerung aus, und eine kurze bewusste Verzögerung schlägt ein Umschreiben des Profils.

Wiederholen Sie dann den üblichen Neustarttest, nachdem Sie es geändert haben, einschließlich der Prüfung auf Client-Seite. Ein Neustarttest, der nur auf das Router-Dashboard schaut, prüft die am wenigsten aussagekräftige der vier Schichten.