Il reset del peer sull’ASA cancella le SA IPsec, non lo stato IKE né le sessioni
Un clear limitato al peer abbatte solo il percorso dati IPsec. Guardate cosa sopravvive, perché il tunnel si ricostruisce in pochi secondi e quale strato conviene pulire invece.
Il tunnel cade per una sola applicazione, qualcuno esegue un clear IPsec limitato al peer e il ticket viene chiuso perché il comando è stato accettato. Nulla in quella sequenza dimostra che il guasto sia stato riparato. Su un ASA la parola reset copre tre ambiti distinti, e il clear limitato al peer ne tocca esattamente uno, per questo lo stesso tunnel è spesso di nuovo su prima che l’operatore abbia finito di leggere l’output.
Tre ambiti si nascondono dietro una parola
Una coppia di SA IPsec è il percorso dati stesso, un’associazione per direzione, con numeri di sequenza e contatori. Una SA IKE è il canale di negoziazione che ha prodotto quelle associazioni e che tiene ancora insieme la relazione con il peer. Una sessione VPN è il record nel database delle sessioni per un utente, un peer sito a sito o una connessione senza client.
| 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 |
Gli ambiti sono abbastanza indipendenti che pulirne uno lascia funzionare gli altri, e questa indipendenza produce gran parte della confusione. Cancellate le SA IPsec mentre la SA IKE è sana e il traffico provoca nuove associazioni in pochi secondi, così il tunnel sembra essersi guarito da solo. La discrepanza della proposta, il buco nella rotta o il fallimento dell’autenticazione sono ancora lì.
Se il guasto è nella negoziazione, un clear IPsec non cambia nulla di osservabile.
Leggete lo stato finché esiste ancora
Annotate l’indirizzo del peer, la versione IKE in uso, le reti protette e i contatori direzionali prima di toccare qualcosa. Le viste supportate variano per versione, ma le forme sono stabili: show crypto ipsec sa peer, show crypto ikev2 sa detailed o l’equivalente per IKEv1, e show vpn-sessiondb per lo strato delle sessioni.
Scrivete il timestamp e il guasto esatto visibile all’utente accanto a quell’output. Un peer porta spesso più reti protette, quindi il raggio d’azione di un clear limitato al peer è ogni selettore su quel peer, non l’unica applicazione del ticket. Un reset senza immagine precedente non è diagnosticabile dopo, perché il clear cancella proprio i contatori con cui avreste confrontato.
Raccogliete prima le prove. Il clear le rimuove, e uno screenshot scattato dopo vi dice cosa si è ricostruito, non cosa era rotto.
Che cosa fa realmente il clear limitato al peer
La referenza dei comandi clear di Cisco documenta la forma IPsec limitata al peer. Con un indirizzo di documentazione sostituito, appare così:
clear crypto ipsec sa peer 198.51.100.42Quel comando abbatte le associazioni IPsec che corrispondono al peer. Non rimuove la SA IKE, non cancella la configurazione e non azzera il database delle sessioni. Eseguitelo da un percorso di gestione che non dipende dal tunnel che state modificando, perché una sessione SSH trasportata dentro quel tunnel morirà con esso e potrebbe non tornare da sola. Tutto il resto del dispositivo continua a funzionare, ed è proprio per questo che il comando sembra innocuo.
Quando la ricerca del bersaglio è incerta, non ricadete su un clear non qualificato. La forma più ampia raggiunge ogni peer del dispositivo, e il disservizio che create sarà più grande di quello per cui siete stati chiamati.
Verificate lo strato che volevate riparare
Dopo il clear, confermate che le associazioni sono tornate con contatori nuovi invece di supporre che il reset abbia funzionato perché la lista dei peer si è ripopolata. Poi provate l’applicazione nominata nel ticket, perché un ping riuscito non dice nulla su un permesso di servizio o su una sessione scaduta.
Se le associazioni si ricostruiscono e l’applicazione continua a fallire, i candidati rimasti sono lo strato IKE e lo strato delle sessioni. Scegliete quello di cui potete ancora ispezionare lo stato. Usate l’operazione mirata per la versione realmente in esecuzione, che sia un clear IKEv2, un clear IKEv1 o un clear del database delle sessioni limitato al tipo di sessione corretto. Cancellare e ricreare configurazioni crypto-map persistenti per forzare una ricostruzione è una congettura con un rollback più lungo.
Escalate con entrambe le immagini, prima e dopo, invece di pulire di nuovo.
Quando il reset allunga il disservizio
I clear ripetuti nascondono i guasti che un reset non può riparare: una rotta mancante, un selettore che non corrisponde più alla nuova sottorete, una chiave precondivisa cambiata su un lato o un rinnovo di chiave che fallisce ripetutamente su una proposta che il peer non accetterà. Ogni clear interrompe traffico sano su ogni selettore di quel peer mentre la causa reale resta intatta. Ecco come un’indagine di cinque minuti diventa una finestra di cambiamento.
Un reset circoscritto resta utile. La versione utile è mirata, registrata e seguita da un’ispezione dello strato che doveva riparare.
Ordine di lavoro: rilevate peer, versione, selettori e contatori; confermate a quale ambito appartiene il guasto; eseguite il clear più stretto che corrisponde; verificate le associazioni e l’applicazione; escalate con prove se lo strato si riprende ma il sintomo no.