Automatizzare i reset dei tunnel ASA: tre porte prima di consentirlo

Considerate un reset automatico del tunnel come un'azione di ripristino con un raggio d'impatto, non come uno sbalzo d'umore programmato. La decisione davanti a voi è più stretta di quanto suggerisca lo strumento: quale guasto lo giustifica, quale peer può toccare e che cosa lo ferma. Sbagliate quei tre e avete costruito una macchina per cancellare prove. Ne ho visto uno scattare ogni quindici minuti contro un peer sano per gran parte di una settimana, e nessuno se ne è accorto perché il tunnel tornava ogni volta.

Prima porta: dimostrate che il guasto è dentro il tunnel

Correlate stato fresco prima di autorizzare qualsiasi cosa. show crypto ikev2 sa detailed vi dice se l'associazione IKEv2 esiste e fin dove è arrivata la negoziazione, e show vpn-sessiondb detail l2l fornisce la vista di sessione che corrisponde allo stesso peer. Poi show crypto ipsec sa peer 203.0.113.10 mostra le SA figlie, i contatori encaps e decaps e i selettori in uso. Un contatore encaps che sale con un contatore decaps piatto è un problema molto diverso dall'assenza totale di associazione.

Poi controllate ciò che una ricostruzione non può riparare: una rotta di ritorno mancante, una MTU che inghiotte i pacchetti grandi, una policy che nega la porta dopo la decifratura, o un routing asimmetrico che manda le risposte attorno all'apparecchio. Cancellare SA contro uno di questi produce un breve lampo verde e lo stesso ticket domani. Ognuno sembra un tunnel morto dal lato dell'applicazione, per questo i contatori contano più dell'allarme.

Scattate un'istantanea prima dell'azione. Registrate il peer, gli identificatori dell'associazione, i contatori al momento del trigger e le prove che lo hanno attivato. Un reset che precede l'istantanea distrugge i dati più utili che l'incidente avesse.

Seconda porta: limitate l'ambito al peer, mai al mondo

Nella CLI dell'ASA, clear crypto ikev2 sa peer 203.0.113.10 e clear crypto ipsec sa peer 203.0.113.10 sono operazioni mirate. Gli stessi comandi senza argomento peer cancellano ogni associazione nel contesto, il che li rende una variante di scrittura e un'interruzione di effetto. La riferimento dei comandi di cancellazione di Cisco separa quelle forme dalla variante solo statistiche, che azzera i contatori e non ripara nulla. In modalità multicontext il comando agisce solo sul contesto corrente, quindi l'automazione deve sapere anche in quale contesto si trova.

Validate il peer prima che il comando venga costruito. Una variabile vuota o non risolta deve far fallire il lavoro in modo rumoroso invece di collassare in una cancellazione totale, e quel controllo appartiene a codice che un revisore può leggere.

Disegnate il raggio d'impatto con onestà. Un peer può portare diverse reti protette, migliaia di sessioni e un secondo tunnel per la gestione, quindi una cancellazione limitata al peer resta un evento multi-cliente su un concentratore. Eseguite l'azione da un percorso di gestione che non dipenda dal tunnel che viene resettato. Altrimenti l'automazione non può verificare il proprio risultato, e il passo successivo è una persona che guida fino al sito.

Terza porta: tentativi, raffreddamento, successo definito

Date al lavoro un lock per peer, un periodo di raffreddamento e un limite rigido di tentativi contato da osservazioni fresche. Senza il lock, due monitor che scattano nello stesso momento cancellano lo stesso peer mentre la rinegoziazione è in corso, e ognuno conclude che l'altro ha fallito.

Successo significa che l'associazione è tornata e che il carico consentito passa, non che il comando è tornato senza errore. Sondate con lo stesso controllo che ha rilevato il guasto, poi confermate che i contatori delle SA figlie si muovono in entrambe le direzioni. Un comando che esce con zero mentre il tunnel resta giù è un guasto di monitoraggio travestito da ripristino.

Tenete l'ignoto separato dal fallito. Se la telemetria è obsoleta o il percorso di gestione non è raggiungibile, lo stato onesto è sconosciuto, e un budget di tentativi non deve leggerlo come permesso di sparare di nuovo.

Quando il primo ripristino approvato non riporta il servizio, escalate con l'istantanea invece di fare cicli. I reset programmati sono la peggiore versione dello schema, perché nascondono un difetto di rinegoziazione chiavi, rotta o policy mentre tagliano sessioni sane a tempo.

Proprietà, un interruttore e una prova

Nominate un proprietario, documentate come disattivare l'applet o la pianificazione in un solo passo e fissate una data di revisione. Un'automazione senza percorso di disattivazione diventa infrastruttura permanente il giorno in cui il suo autore cambia team.

Provatela in laboratorio o in una finestra di manutenzione con la selezione del peer volutamente rotta, per scoprire se il lavoro fallisce in sicurezza. Poi provate il percorso di successo, perché un lavoro che gira solo quando qualcosa va storto non vi insegna nulla sul suo comportamento normale.