Die IKEv2-Erkennung toter Gegenstellen prüft nicht Ihre Anwendung

Die Lebendprüfung in IKEv2 stellt eine Frage: Antwortet die andere Gegenstelle noch auf der geschützten Steuerbeziehung. Sie misst nicht, ob eine interne Anwendung gesund ist, ob hinter dem Gateway eine Route existiert oder ob das Surfen schnell wirkt. Die Prüfung kann bestehen, während alles Nützliche hinter dem Tunnel ausfällt.

Lesen Sie die beiden Beweisarten getrennt, bevor Sie einen Timer ändern.

Was die Lebendprüfung tatsächlich fragt

Ein Lebendaustausch wird innerhalb der bestehenden IKE-Sicherheitsassoziation gesendet und erwartet eine Antwort innerhalb eines konfigurierten Fensters. Erfolg bedeutet, dass die IKE-Implementierung der Gegenstelle noch da und noch bereit ist zu sprechen. Er sagt nichts über die untergeordneten Sicherheitsassoziationen aus, die Verkehr tragen, nichts über das Routing jenseits des Gateways und nichts über den Dienst, für den Sie den Tunnel geöffnet haben. Das sind drei getrennte Fragen mit drei getrennten Fehlerarten.

Diese Unterscheidung entscheidet, wo Sie hinsehen, wenn eine Sitzung verstummt. Eine Gegenstelle, die weiter antwortet, während ein Datenpfad defekt ist, deutet auf Richtlinie, Routing oder einen nachgelagerten Dienst hin. Eine Gegenstelle, die aufhört zu antworten, deutet auf Erreichbarkeit oder auf den eigenen Zustand des fernen Endes hin.

Lesen Sie die Sicherheitsassoziationen vor dem Browser

Der Steuerzustand und der Datenzustand werden getrennt aufgelistet, sobald Sie den Daemon fragen, und die Zähler sagen, ob überhaupt etwas versucht wurde. Eine untergeordnete Assoziation, die nie installiert wurde, sieht völlig anders aus als eine, die installiert wurde und dann aufhörte, Pakete durchzulassen, obwohl beide dieselbe Nutzerbeschwerde erzeugen.

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

Notieren Sie die Zustandsnamen wörtlich im Ticket, zusammen mit den Zählern im Moment der Beschwerde. Eine Beschreibung wie Tunnel unten verbirgt, welche der beiden Assoziationen endete, und das ist meist die einzige Tatsache, die man haben möchte.

Ein Routenfehler sieht genau wie eine tote Gegenstelle aus

Das Gateway kann Steueraustausche beantworten, während ein privater Server offline ist, eine weitergeleitete Route fehlt oder die interne Namensauflösung vollständig scheitert. Aus Sicht des Clients stellt sich all das als Sitzung dar, die steht, und Ziel, das nicht steht. Prüfen Sie den Rückweg so sorgfältig wie den Hinweg, denn asymmetrisches Routing auf der fernen Seite erzeugt Stille nur in einer Richtung.

Testen Sie die beabsichtigte Anwendung direkt und benennen Sie die Adresse, die sie versucht hat, statt zu testen, ob der Tunnel steht. Ein Ping zum Gateway beweist, dass das Gateway antwortet; er hat nie bewiesen, dass die Anwendung es tat. Notieren Sie die genaue Adresse, die die Anwendung versucht hat. Diese Zeichenkette verengt später die Suche, und sie ist die eine Tatsache, die das Ticket meist auslässt.

Halten Sie Timer aus der Diagnose heraus

Ein Erkennungsintervall zu verkürzen ist keine Leistungsänderung und fügt keine Kapazität hinzu. Bei Paketverlust ändert es, wie schnell ein Fehler erkannt wird, was ein Symptom anders aussehen lassen kann, ohne irgendetwas zu verbessern. Notieren Sie zuerst die tatsächliche Fehlerzeit und entscheiden Sie dann, ob die Toleranz für die Verbindung falsch ist, die Sie wirklich haben.

Aktualisierungen der NAT-Zuordnung gehören in dieselbe Kategorie. Sie halten einen übersetzten Pfad nutzbar und sind kein Beleg dafür, dass die entfernte Anwendung funktioniert.

Eine vollständige Wiederherstellungsrichtlinie sagt, was der Client tun soll, wenn eine Gegenstelle für tot erklärt wird: neu starten, schließen oder halten, und was anderer Verkehr währenddessen tun darf. Ohne sie wird derselbe Vorfall jedes Quartal von vorn diagnostiziert.