Ein kürzerer DPD-Timer macht VPN-Failover nicht schneller

Tunnel brechen ab, die Wiederherstellung dauert neunzig Sekunden, und der Dead-Peer-Timer steht auf zehn, also wird der Timer beschuldigt. Diese Argumentation überspringt drei Phasen, die nach der Erkennung ablaufen und normalerweise den größten Teil der Zeit verbrauchen. Die Lebendigkeitserkennung bemerkt die Stille; danach nehmen Peer-Auswahl, Authentifizierung, Routeninstallation und Anwendungsneuverbindung jeweils ihre eigene Zeit in Anspruch. Die erste Phase zu verkürzen kann die anderen nicht verkürzen, und es kann einem System, das ohnehin kämpfte, zusätzliche Unruhe hinzufügen.

Vier Phasen, von denen Sie eine messen können

Schreiben Sie die Wiederherstellung als vier Ereignisse mit Zeitstempeln. Der Fehler wird beobachtbar: der letzte nützliche geschützte Verkehr und die erste fehlgeschlagene Anforderung. Der zuständige Mechanismus reagiert: Lebendigkeitserkennung, ein Routenmonitor oder ein anderer dokumentierter Auslöser. Die Alternative wird nutzbar: Peer-Auswahl, Authentifizierung, eine neue Assoziation und eine Route, die tatsächlich den beabsichtigten Verkehr trägt. Die Anwendung erholt sich: eine neue Operation gelingt, und was in Bearbeitung war, hat ein definiertes Ergebnis.

Die Lebendigkeitsregeln von IKEv2 beschreiben Belege über den Peer und dessen Austausch und sagen nichts über eine Datenbank oder einen Dateidienst hinter diesem Peer. Ein Lebendigkeits-Timeout als Gesundheitsprüfung für den gesamten Pfad zu lesen ist der Fehler, der die Timersuche beginnt.

Warum der Timer die am wenigsten interessante Zahl ist

Konfigurierte Werte sind keine austauschbaren Einheiten. Manche sind Wiederholungsintervalle, manche sind Obergrenzen für einen Versuch, und manche laufen gleichzeitig mit anderen. Sie zu addieren ergibt eine Zahl, die wie eine Vorhersage aussieht und sich wie ein Gerücht verhält. Lesen Sie die Dokumentation für das Feld, das Sie gleich anfassen, und notieren Sie, welche der drei Arten es ist.

Andere Phasen sind überhaupt keine Timer. Ein Wiederverbindungs-Backoff, eine interaktive Authentifizierungsabfrage oder ein Client, der seine Konfiguration nur beim Neustart neu bewertet, können jeweils den Ausfall dominieren, während jeder Protokoll-Timer bequem niedrig steht.

Messen Sie die Phase, die tatsächlich langsam ist

Erfassen Sie den Fehler einmal, mit Zeitstempeln auf beiden Seiten, und vergleichen Sie dann die vier Ereignisse statt die eigenen Zähler des Protokolls. Ein ordentlich durchgeführtes Beobachtungsfenster schlägt einen Monat Tuning.

ip -4 route get 203.0.113.10
tcpdump -ni any -c 20 "esp or icmp"

Wenn der alternative Endpunkt nie antwortet, hilft keine Timer-Änderung, denn Unerreichbarkeit ist kein Erkennungsproblem. Wenn neuer Sicherheitszustand schnell entsteht, die Route aber weiter auf den toten Pfad zeigt, liegt das Problem in der Routeninstallation, und eine weitere Lebendigkeitsanpassung fügt nur Unruhe hinzu.

Die Alternative muss bereits nutzbar sein

Ein in einer Konfiguration definiertes Backup ist kein Backup, das funktioniert. Es muss aus dem aktuellen Netz des Clients erreichbar sein, dieselbe Identität authentifizieren können und berechtigt sein, denselben Verkehr unter derselben Richtlinie zu tragen. Entdecken Sie eine dieser drei Lücken während eines Ausfalls, wird die Timer-Diskussion irrelevant. Testen Sie die Alternative, solange die primäre gesund ist, denn nur dann können Sie beide Protokolle nebeneinander lesen.

Stellen Sie die Alternative im Voraus bereit, testen Sie sie bewusst, solange die primäre gesund ist, und notieren Sie, welche der vier Phasen die Zeit beansprucht. Diese Aufzeichnung macht die nächste Änderung zu einer Messung statt zu einer Vermutung.

Rückfall-Unruhe und der Verwaltungspfad

Die primäre wiederherzustellen ist eine separate Entscheidung. Ein aggressiver Rückfall kann Arbeit unterbrechen, die sich bereits auf dem Backup erholt hatte, und ein flatternder Pfad kann wie ein instabiler Tunnel aussehen, wenn der eigentliche Fehler eine Route ist, die zwischen zwei gleichwertigen Optionen pendelt.

Zwei gleichwertige Pfade ohne Präferenz sind die übliche Quelle sichtbaren Flatterns, weil jeder Monitor auf die Wahl des anderen reagiert. Entscheiden Sie, welcher Pfad unter normalen Bedingungen bevorzugt wird, und machen Sie diese Präferenz in der Konfiguration explizit, statt sie der Routenreihenfolge zu überlassen. Definieren Sie das gewünschte Rückfallverhalten und wer es besitzt, im Voraus. Behalten Sie die bisherigen Einstellungen und einen unabhängigen Verwaltungspfad, denn eine Änderung, die Ihren eigenen Zugang während eines Ausfalls entfernt, verwandelt einen Netzwerkvorfall in einen Vor-Ort-Termin.

Wiederholen Sie dann dieselbe Arbeitslast und vergleichen Sie dieselben vier Zeitstempel. Eine kürzere Wiederherstellung, die die Anwendung weiter auf dieselbe fehlende Route oder Anmeldung warten lässt, ist kein Fortschritt, sie ist eine andere Zahl im selben Diagramm.