Automatizarea resetărilor de tunel ASA: trei porți înainte de a permite

Priviți un reset automat de tunel ca pe o acțiune de recuperare cu rază de impact, nu ca pe o schimbare de dispoziție programată. Decizia din fața dumneavoastră este mai îngustă decât sugerează instrumentele: ce defecțiune o justifică, ce peer poate atinge și ce o oprește. Greșiți aceste trei și ați construit o mașină de șters dovezi. Am văzut unul dintre acestea trăgând la fiecare cincisprezece minute împotriva unui peer sănătos cea mai mare parte a unei săptămâni, și nimeni nu a observat pentru că tunelul revenea de fiecare dată.

Prima poartă: dovediți că defecțiunea este în tunel

Corelați starea proaspătă înainte de a autoriza ceva. show crypto ikev2 sa detailed vă spune dacă asociația IKEv2 există și cât de departe a ajuns negocierea, iar show vpn-sessiondb detail l2l oferă vederea sesiunii care corespunde aceluiași peer. Apoi show crypto ipsec sa peer 203.0.113.10 arată SA-urile copil, contoarele encaps și decaps și selectorii utilizați. Un contor encaps care crește cu un contor decaps plat este o problemă complet diferită de absența totală a asocierii.

Apoi verificați ce nu poate repara o reconstrucție: o rută de retur lipsă, un MTU care înghite pachetele mari, o politică ce refuză portul după decriptare sau un rutare asimetrică ce trimite răspunsurile în jurul echipamentului. Ștergerea SA împotriva oricăreia dintre acestea produce o scurtă licărire verde și același tichet mâine. Fiecare arată ca un tunel mort din partea aplicației, de aceea contoarele contează mai mult decât alerta.

Faceți un instantaneu înainte de acțiune. Înregistrați peerul, identificatorii asocierii, contoarele în momentul declanșării și dovezile care au declanșat-o. Un reset care precede instantaneul distruge cele mai utile date pe care le-a avut incidentul.

A doua poartă: limitați domeniul la peer, niciodată la lume

În CLI-ul ASA, clear crypto ikev2 sa peer 203.0.113.10 și clear crypto ipsec sa peer 203.0.113.10 sunt operațiuni țintite. Aceleași comenzi fără argument de peer șterg fiecare asociere din context, ceea ce le face o variație de scriere și o cădere ca efect. referința comenzilor de ștergere de la Cisco separă acele forme de varianta doar cu statistici, care resetează contoarele și nu repară nimic. În modul multi-context comanda acționează doar asupra contextului curent, așa că automatizarea trebuie să știe și în ce context se află.

Validați peerul înainte de a construi comanda. O variabilă goală sau nerezolvată trebuie să eșueze zgomotos sarcina, în loc să se prăbușească într-o ștergere totală, iar verificarea respectivă aparține codului pe care un recenzent îl poate citi.

Desenați raza de impact cu onestitate. Un peer poate transporta mai multe rețele protejate, mii de sesiuni și un al doilea tunel pentru administrare, așa că o ștergere limitată la peer rămâne un eveniment cu mai mulți clienți pe un concentrator. Executați acțiunea dintr-o cale de administrare care nu depinde de tunelul resetat. Altfel automatizarea nu își poate verifica propriul rezultat, iar pasul următor este o persoană care conduce la fața locului.

A treia poartă: reîncercări, răcire, succes definit

Dați sarcinii o blocare pe peer, o perioadă de răcire și o limită dură de încercări numărată din observații proaspete. Fără blocare, două monitoare declanșate în același moment șterg același peer în timp ce renegocierea este în curs, și fiecare concluzionează că celălalt a eșuat.

Succesul înseamnă că asocierea a revenit și sarcina permisă trece, nu că comanda s-a întors fără eroare. Sondați cu aceeași verificare care a detectat defecțiunea, apoi confirmați că contoarele SA copil se mișcă în ambele direcții. O comandă care iese cu zero în timp ce tunelul rămâne jos este o defecțiune de monitorizare deghizată în recuperare.

Țineți necunoscutul separat de eșec. Dacă telemetria este învechită sau calea de administrare este inaccesibilă, starea onestă este necunoscută, iar un buget de reîncercări nu trebuie să citească asta ca permisiune de a trage din nou.

Când prima recuperare aprobată nu restaurează serviciul, escaladați cu instantaneul în loc să buclați. Resetările programate sunt cea mai proastă versiune a modelului, pentru că ascund un defect de reînnoire a cheilor, de rută sau de politică în timp ce taie sesiuni sănătoase pe un temporizator.

Proprietate, un întrerupător și o repetiție

Numiți un proprietar, documentați cum se dezactivează appletul sau programarea într-un singur pas și stabiliți o dată de revizuire. O automatizare fără cale de dezactivare devine infrastructură permanentă în ziua în care autorul ei schimbă echipa.

Repetați-o într-un laborator sau într-o fereastră de mentenanță cu selecția peerului ruptă intenționat, ca să aflați dacă sarcina eșuează în siguranță. Apoi repetați calea de succes, pentru că o sarcină care rulează doar când ceva este greșit nu vă învață nimic despre comportamentul ei normal.