Peer-Reset auf der ASA löscht IPsec-SAs, nicht den IKE-Zustand oder Sitzungen
Ein peer-begrenztes Clear reißt nur den IPsec-Datenpfad ab. Lesen Sie, was überlebt, warum der Tunnel in Sekunden wieder aufgebaut ist und welche Schicht Sie stattdessen leeren sollten.
Der Tunnel fällt für eine einzelne Anwendung aus, jemand führt ein peer-begrenztes IPsec-Clear aus, und das Ticket wird geschlossen, weil der Befehl akzeptiert wurde. Nichts in dieser Abfolge zeigt, dass die Störung behoben wurde. Auf einer ASA deckt das Wort Reset drei getrennte Bereiche ab, und das peer-begrenzte Clear berührt genau einen davon – deshalb ist derselbe Tunnel oft wieder oben, bevor der Operator die Ausgabe zu Ende gelesen hat.
Drei Bereiche verbergen sich hinter einem Wort
Ein IPsec-SA-Paar ist der Datenpfad selbst, eine Assoziation pro Richtung, mit Sequenznummern und Zählern. Eine IKE-SA ist der Aushandlungskanal, der diese Assoziationen erzeugt hat und die Peer-Beziehung noch zusammenhält. Eine VPN-Sitzung ist der Datensatz in der Sitzungsdatenbank für einen Benutzer, einen Site-to-Site-Peer oder eine clientlose Verbindung.
| Scope | What a clear removes | What usually survives |
|---|---|---|
| IPsec SA | Data-path associations for the matching peer or selector | IKE SA, session records, crypto-map or tunnel-group config |
| IKE SA | Negotiation channel and the IPsec children derived from it | Session records until they age out or are cleared |
| VPN session | Session-database entry for that user or peer type | Configuration, and any SA that is not tied to the session |
Die Bereiche sind unabhängig genug, dass das Leeren des einen die anderen weiterlaufen lässt, und diese Unabhängigkeit erzeugt den größten Teil der Verwirrung. Leeren Sie die IPsec-SAs, während die IKE-SA gesund ist, und Verkehr löst innerhalb von Sekunden neue Assoziationen aus, sodass der Tunnel sich selbst geheilt zu haben scheint. Die zugrunde liegende Proposal-Abweichung, die Routenlücke oder der Authentifizierungsfehler sind weiterhin da.
Liegt die Störung in der Aushandlung, ändert ein IPsec-Clear nichts Beobachtbares.
Lesen Sie den Zustand, solange er noch existiert
Notieren Sie Peer-Adresse, verwendete IKE-Version, die geschützten Netze und die richtungsbezogenen Zähler, bevor Sie irgendetwas anfassen. Die unterstützten Ansichten unterscheiden sich je nach Release, aber die Formen sind stabil: show crypto ipsec sa peer, show crypto ikev2 sa detailed oder das IKEv1-Äquivalent und show vpn-sessiondb für die Sitzungsschicht.
Schreiben Sie den Zeitstempel und die genaue benutzersichtbare Störung neben diese Ausgabe. Ein Peer trägt häufig mehrere geschützte Netze, daher ist der Wirkungsradius eines peer-begrenzten Clears jeder Selektor auf diesem Peer, nicht die einzelne Anwendung im Ticket. Ein Reset ohne Vorher-Bild lässt sich hinterher nicht diagnostizieren, weil das Clear genau die Zähler löscht, mit denen Sie verglichen hätten.
Sichern Sie zuerst die Beweise. Das Clear entfernt sie, und ein danach aufgenommener Screenshot sagt Ihnen, was neu aufgebaut wurde, nicht was defekt war.
Was das peer-begrenzte Clear tatsächlich tut
Ciscos Referenz der clear-Befehle dokumentiert die peer-begrenzte IPsec-Form. Mit eingesetzter Dokumentationsadresse sieht sie so aus:
clear crypto ipsec sa peer 198.51.100.42Dieser Befehl reißt die IPsec-Assoziationen ab, die zum Peer passen. Er entfernt die IKE-SA nicht, löscht keine Konfiguration und setzt die Sitzungsdatenbank nicht zurück. Führen Sie ihn über einen Managementpfad aus, der nicht von dem Tunnel abhängt, den Sie ändern, denn eine über diesen Tunnel laufende SSH-Sitzung stirbt mit ihm und kommt möglicherweise nicht von selbst zurück. Alles andere auf dem Gerät läuft weiter – genau deshalb wirkt der Befehl harmlos.
Ist die Zielsuche unsicher, greifen Sie nicht auf ein unqualifiziertes Clear zurück. Die breitere Form erreicht jeden Peer auf dem Gerät, und der Ausfall, den Sie erzeugen, wird größer sein als der, für den Sie gerufen wurden.
Prüfen Sie die Schicht, die Sie reparieren wollten
Bestätigen Sie nach dem Clear, dass die Assoziationen mit frischen Zählern zurückgekommen sind, statt anzunehmen, der Reset habe gewirkt, weil die Peer-Liste sich wieder gefüllt hat. Testen Sie dann die im Ticket genannte Anwendung, denn ein erfolgreicher Ping sagt nichts über eine Dienstberechtigung oder eine abgelaufene Sitzung.
Bauen sich die Assoziationen neu auf und schlägt die Anwendung weiterhin fehl, bleiben die IKE-Schicht und die Sitzungsschicht als Kandidaten. Wählen Sie die, deren Zustand Sie noch einsehen können. Verwenden Sie die gezielte Operation für die tatsächlich laufende Version, ob das ein IKEv2-Clear, ein IKEv1-Clear oder ein auf den richtigen Sitzungstyp begrenztes Sitzungsdatenbank-Clear ist. Persistente crypto-map-Konfiguration zu löschen und neu zu erstellen, um einen Neuaufbau zu erzwingen, ist Rätselraten mit längerem Rückweg.
Eskalieren Sie mit beiden Bildern, vorher und nachher, statt erneut zu leeren.
Wenn der Reset den Ausfall verlängert
Wiederholte Clears verbergen die Fehler, die ein Reset nicht beheben kann: eine fehlende Route, ein Selektor, der nicht mehr zum neuen Subnetz passt, ein auf einer Seite geänderter vorab geteilter Schlüssel oder ein Rekey, das an einem Proposal scheitert, das der Peer nicht akzeptiert. Jedes Clear unterbricht gesunden Verkehr auf jedem Selektor dieses Peers, während die eigentliche Ursache unangetastet bleibt. So wird aus einer fünfminütigen Untersuchung ein Änderungsfenster.
Ein begrenzter Reset bleibt nützlich. Die nützliche Variante ist gezielt, dokumentiert und von einer Prüfung der Schicht gefolgt, die er reparieren sollte.
Reihenfolge der Arbeit: Peer, Version, Selektoren und Zähler erfassen; bestätigen, zu welchem Bereich die Störung gehört; das engste passende Clear ausführen; Assoziationen und Anwendung prüfen; mit Belegen eskalieren, wenn die Schicht sich erholt, das Symptom aber bleibt.