Resetul de peer pe ASA șterge SA-urile IPsec, nu starea IKE sau sesiunile
Un clear limitat la peer dărâmă doar calea de date IPsec. Vedeți ce supraviețuiește, de ce tunelul se reconstruiește în secunde și ce strat ar trebui curățat în schimb.
Tunelul cade pentru o singură aplicație, cineva rulează un clear IPsec limitat la peer, iar tichetul este închis pentru că comanda a fost acceptată. Nimic din acea secvență nu arată că defecțiunea a fost reparată. Pe un ASA cuvântul reset acoperă trei domenii separate, iar clear-ul limitat la peer atinge exact unul dintre ele, de aceea același tunel este adesea din nou sus înainte ca operatorul să termine de citit ieșirea.
Trei domenii ascunse în spatele unui cuvânt
O pereche SA IPsec este calea de date însăși, o asociere pe direcție, cu numere de secvență și contoare. O SA IKE este canalul de negociere care a produs acele asocieri și care încă ține relația cu peer-ul împreună. O sesiune VPN este înregistrarea din baza de date de sesiuni pentru un utilizator, un peer site-la-site sau o conexiune fără 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 |
Domeniile sunt suficient de independente încât curățarea unuia le lasă pe celelalte în funcțiune, iar această independență produce cea mai mare parte a confuziei. Curățați SA-urile IPsec cât timp SA-ul IKE este sănătos, iar traficul declanșează asocieri noi în câteva secunde, așa că tunelul pare să se fi vindecat singur. Dar nepotrivirea propunerii, lipsa rutei sau eșecul autentificării sunt încă acolo.
Dacă defecțiunea este în negociere, un clear IPsec nu schimbă nimic observabil.
Citiți starea cât timp mai există
Notați adresa peer-ului, versiunea IKE folosită, rețelele protejate și contoarele direcționale înainte de a atinge ceva. Vizualizările acceptate diferă în funcție de versiune, dar formele sunt stabile: show crypto ipsec sa peer, show crypto ikev2 sa detailed sau echivalentul pentru IKEv1, și show vpn-sessiondb pentru stratul de sesiuni.
Scrieți marca temporală și defecțiunea exactă vizibilă utilizatorului lângă acea ieșire. Un peer transportă de obicei mai multe rețele protejate, deci raza de acțiune a unui clear limitat la peer este fiecare selector de pe acel peer, nu singura aplicație din tichet. Un reset fără imagine prealabilă nu poate fi diagnosticat ulterior, pentru că clear-ul șterge exact contoarele cu care ați fi comparat.
Colectați mai întâi dovezile. Clear-ul le elimină, iar o captură făcută după aceea vă spune ce a fost reconstruit, nu ce era defect.
Ce face de fapt clear-ul limitat la peer
Referința comenzilor clear de la Cisco documentează forma IPsec limitată la peer. Cu o adresă de documentație substituită, arată astfel:
clear crypto ipsec sa peer 198.51.100.42Acea comandă dărâmă asocierile IPsec care corespund peer-ului. Nu elimină SA-ul IKE, nu șterge configurația și nu resetează baza de date de sesiuni. Rulați-o dintr-o cale de administrare care nu depinde de tunelul pe care îl modificați, pentru că o sesiune SSH purtată în acel tunel va muri împreună cu el și poate nu va reveni singură. Tot restul dispozitivului continuă să funcționeze, și exact de aceea comanda pare inofensivă.
Când căutarea țintei este incertă, nu recurgeți la un clear necalificat. Forma mai largă ajunge la fiecare peer de pe dispozitiv, iar întreruperea pe care o creați va fi mai mare decât cea pentru care ați fost chemat.
Verificați stratul pe care intenționați să îl reparați
După clear, confirmați că asocierile au revenit cu contoare noi în loc să presupuneți că resetul a funcționat pentru că lista de peer-uri s-a umplut din nou. Apoi testați aplicația numită în tichet, pentru că un ping reușit nu spune nimic despre o permisiune de serviciu sau o sesiune expirată.
Dacă asocierile se reconstruiesc și aplicația încă eșuează, candidații rămași sunt stratul IKE și stratul de sesiuni. Alegeți-l pe cel a cărui stare o mai puteți inspecta. Folosiți operația țintită pentru versiunea care rulează efectiv, fie că este un clear IKEv2, un clear IKEv1 sau un clear al bazei de date de sesiuni limitat la tipul corect de sesiune. Ștergerea și recrearea configurației persistente crypto-map pentru a forța o reconstrucție este o presupunere cu un rollback mai lung.
Escaladați cu ambele imagini, înainte și după, în loc să curățați din nou.
Când resetul prelungește întreruperea
Clear-urile repetate ascund defecțiunile pe care un reset nu le poate repara: o rută lipsă, un selector care nu mai corespunde noii subrețele, o cheie prepartajată schimbată pe o parte sau o reînnoire de cheie care eșuează repetat pe o propunere pe care peer-ul nu o va accepta. Fiecare clear întrerupe trafic sănătos pe fiecare selector al acelui peer, în timp ce cauza reală rămâne neatinsă. Așa se transformă o investigație de cinci minute într-o fereastră de schimbare.
Un reset delimitat rămâne util. Versiunea utilă este țintită, înregistrată și urmată de o inspecție a stratului pe care trebuia să îl repare.
Ordinea lucrului: notați peer-ul, versiunea, selectorii și contoarele; confirmați cărei domenii îi aparține defecțiunea; rulați cel mai îngust clear care se potrivește; verificați asocierile și aplicația; escaladați cu dovezi dacă stratul își revine dar simptomul nu.