ASA-Tunnel-Resets automatisieren: drei Gates, bevor Sie es zulassen

Betrachten Sie einen automatischen Tunnel-Reset als Wiederherstellungsaktion mit Sprengradius, nicht als geplante Stimmungsschwankung. Die Entscheidung vor Ihnen ist enger, als das Werkzeug nahelegt: welcher Fehler ihn rechtfertigt, welchen Peer er treffen darf und was ihn stoppt. Machen Sie diese drei falsch, haben Sie eine Maschine zum Löschen von Beweisen gebaut. Ich habe erlebt, wie einer davon eine Woche lang alle fünfzehn Minuten gegen einen gesunden Peer feuerte, und niemand merkte es, weil der Tunnel jedes Mal zurückkam.

Gate eins: Beweisen Sie, dass der Fehler im Tunnel liegt

Korrelieren Sie frischen Zustand, bevor Sie irgendetwas genehmigen. show crypto ikev2 sa detailed sagt Ihnen, ob die IKEv2-Assoziation existiert und wie weit die Aushandlung kam, und show vpn-sessiondb detail l2l liefert die Sitzungsansicht, die zum selben Peer passt. Dann zeigt show crypto ipsec sa peer 203.0.113.10 die Child-SAs, die Encaps- und Decaps-Zähler und die verwendeten Selektoren. Ein steigender Encaps-Zähler bei flachem Decaps-Zähler ist ein ganz anderes Problem als gar keine Assoziation.

Prüfen Sie als Nächstes, was ein Neuaufbau nicht reparieren kann: eine fehlende Rückroute, eine MTU, die große Pakete verschluckt, eine Richtlinie, die den Port nach der Entschlüsselung verweigert, oder asymmetrisches Routing, das Antworten um die Appliance herum schickt. Das Löschen von SAs gegen irgendeines davon erzeugt einen kurzen grünen Blitz und morgen dasselbe Ticket. Jedes davon sieht von der Anwendungsseite wie ein toter Tunnel aus, deshalb zählen die Zähler mehr als der Alarm.

Machen Sie vor der Aktion einen Schnappschuss. Notieren Sie den Peer, die Assoziationskennungen, die Zähler im Moment des Auslösers und die Beweise, die ihn ausgelöst haben. Ein Reset, der dem Schnappschuss vorauseilt, zerstört die nützlichsten Daten des Vorfalls.

Gate zwei: Begrenzen Sie den Umfang auf den Peer, niemals auf die Welt

In der ASA-CLI sind clear crypto ikev2 sa peer 203.0.113.10 und clear crypto ipsec sa peer 203.0.113.10 gezielte Operationen. Dieselben Befehle ohne Peer-Argument löschen jede Assoziation im Kontext, was sie zu einer Schreibvariante und im Effekt zu einem Ausfall macht. Ciscos Referenz der Löschbefehle trennt diese Formen von der reinen Statistikvariante, die Zähler zurücksetzt und nichts repariert. Im Mehrkontextmodus wirkt der Befehl nur auf den aktuellen Kontext, daher muss die Automatisierung auch sicher wissen, in welchem Kontext sie sich befindet.

Validieren Sie den Peer, bevor der Befehl zusammengesetzt wird. Eine leere oder unaufgelöste Variable muss den Job laut scheitern lassen, statt in ein Clear-All zu kollabieren, und diese Prüfung gehört in Code, den ein Reviewer lesen kann.

Zeichnen Sie den Sprengradius ehrlich auf. Ein Peer kann mehrere geschützte Netze, Tausende Sitzungen und einen zweiten Tunnel für das Management tragen, ein peer-begrenztes Löschen ist auf einem Hub also weiterhin ein Ereignis für mehrere Kunden. Führen Sie die Aktion von einem Managementpfad aus, der nicht von dem zurückgesetzten Tunnel abhängt. Sonst kann die Automatisierung ihr eigenes Ergebnis nicht prüfen, und der nächste Schritt ist ein Mensch, der zum Standort fährt.

Gate drei: Wiederholungen, Abkühlung, definierter Erfolg

Geben Sie dem Job eine Sperre pro Peer, eine Abkühlzeit und ein hartes Versuchslimit, das aus frischen Beobachtungen gezählt wird. Ohne die Sperre löschen zwei Monitore, die im selben Moment auslösen, denselben Peer, während die Neuverhandlung läuft, und jeder schließt, der andere sei gescheitert.

Erfolg heißt, die Assoziation ist zurück und die erlaubte Last läuft, nicht dass der Befehl ohne Fehler zurückkam. Prüfen Sie mit demselben Test, der den Fehler erkannt hat, und bestätigen Sie dann, dass sich die Child-SA-Zähler in beide Richtungen bewegen. Ein Befehl, der mit Null endet, während der Tunnel unten bleibt, ist ein Monitoring-Fehler im Gewand einer Wiederherstellung.

Unbekannt getrennt von fehlgeschlagen halten. Sind Telemetriedaten veraltet oder ist der Managementpfad nicht erreichbar, ist der ehrliche Zustand unbekannt, und ein Wiederholungsbudget darf das nicht als Erlaubnis lesen, erneut zu feuern.

Stellt die erste genehmigte Wiederherstellung den Dienst nicht wieder her, eskalieren Sie mit dem Schnappschuss, statt zu schleifen. Geplante Resets sind die schlechteste Variante des Musters, weil sie einen Fehler bei Rekey, Route oder Richtlinie verbergen und dabei gesunde Sitzungen per Timer abschneiden.

Verantwortlichkeit, ein Ausschalter und eine Übung

Benennen Sie einen Verantwortlichen, dokumentieren Sie, wie das Applet oder der Zeitplan in einem Schritt deaktiviert wird, und setzen Sie ein Überprüfungsdatum. Eine Automatisierung ohne Abschaltpfad wird an dem Tag dauerhafte Infrastruktur, an dem ihr Autor das Team wechselt.

Üben Sie sie im Labor oder in einem Wartungsfenster mit absichtlich kaputter Peer-Auswahl, damit Sie herausfinden, ob der Job fail-closed arbeitet. Üben Sie dann den Erfolgspfad, denn ein Job, der nur läuft, während etwas falsch ist, lehrt Sie nichts über sein normales Verhalten.