Automatisering af ASA-tunnelreset: tre gates, før du tillader det

Betragt et automatisk tunnelreset som en genopretningshandling med en sprængradius, ikke som et planlagt humørsving. Beslutningen foran dig er snævrere, end værktøjet antyder: hvilken fejl berettiger det, hvilken peer må det røre, og hvad får det til at stoppe. Tager du fejl af de tre, har du bygget en maskine til at slette beviser. Jeg har set en af disse fyre hvert femtende minut mod en sund peer det meste af en uge, og ingen lagde mærke til det, fordi tunnelen kom tilbage hver gang.

Gate et: bevis, at fejlen er inde i tunnelen

Korrelér frisk tilstand, før du godkender noget. show crypto ikev2 sa detailed fortæller, om IKEv2-associationen findes, og hvor langt forhandlingen nåede, og show vpn-sessiondb detail l2l giver det sessionsbillede, der passer til samme peer. Derefter viser show crypto ipsec sa peer 203.0.113.10 child-SA'erne, encaps- og decaps-tællerne og de anvendte selektorer. En stigende encaps-tæller med en flad decaps-tæller er et helt andet problem end slet ingen association.

Kontrollér derefter, hvad en genopbygning ikke kan reparere: en manglende returrute, en MTU, der sluger store pakker, en politik, der afviser porten efter dekryptering, eller asymmetrisk routing, der sender svar uden om enheden. Rydning af SA'er mod noget af dette giver et kort grønt blink og samme billet i morgen. Hvert af dem ser ud som en død tunnel fra applikationssiden, og derfor betyder tællerne mere end alarmen.

Tag et snapshot før handlingen. Notér peeren, associations-id'erne, tællerne i triggerøjeblikket og de beviser, der udløste det. Et reset, der løber foran snapshotet, ødelægger de mest nyttige data, hændelsen havde.

Gate to: afgræns omfanget til peeren, aldrig til verden

På ASA-CLI'en er clear crypto ikev2 sa peer 203.0.113.10 og clear crypto ipsec sa peer 203.0.113.10 målrettede operationer. De samme kommandoer uden peer-argument rydder hver association i konteksten, hvilket gør dem til en variation i stavning og et udfald i effekt. Ciscos reference for ryddekommandoer skiller disse former fra statistikvarianten, som nulstiller tællere og ikke reparerer noget. I multikonteksttilstand virker kommandoen kun på den aktuelle kontekst, så automatiseringen skal også være sikker på, hvilken kontekst den er i.

Validér peeren, før kommandoen bygges. En tom eller uafklaret variabel skal fejle jobbet højlydt i stedet for at kollapse til en clear-all, og den kontrol hører til i kode, en anmelder kan læse.

Kortlæg sprængradiusen ærligt. Én peer kan bære flere beskyttede netværk, tusindvis af sessioner og en anden tunnel til styring, så en peer-afgrænset rydning er stadig en begivenhed for flere kunder på en hub. Kør handlingen fra en styringsvej, der ikke afhænger af den tunnel, der nulstilles. Ellers kan automatiseringen ikke verificere sit eget resultat, og næste skridt er et menneske, der kører til stedet.

Gate tre: gentagelser, cooldown, defineret succes

Giv jobbet en lås pr. peer, en cooldown og en hård grænse for forsøg, talt fra friske observationer. Uden låsen rydder to monitorer, der udløses i samme øjeblik, den samme peer, mens genforhandlingen er i gang, og hver konkluderer, at den anden fejlede.

Succes betyder, at associationen er tilbage, og at den tilladte arbejdsbyrde passerer, ikke at kommandoen vendte tilbage uden fejl. Undersøg med samme kontrol, der fandt fejlen, og bekræft derefter, at child-SA-tællerne bevæger sig i begge retninger. En kommando, der afslutter med nul, mens tunnelen bliver nede, er en overvågningsfejl klædt ud som genopretning.

Hold ukendt adskilt fra fejlet. Hvis telemetrien er forældet, eller styringsvejen er utilgængelig, er den ærlige tilstand ukendt, og et genforsøgsbudget bør ikke læse det som tilladelse til at fyre igen.

Når den første godkendte genopretning ikke genskaber tjenesten, eskalér med snapshotet i stedet for at loope. Planlagte resets er den værste version af mønstret, fordi de skjuler en fejl i nøglefornyelse, rute eller politik, mens de skærer sunde sessioner over på en timer.

Ejerskab, en afbryder og én øvelse

Navngiv en ejer, dokumentér, hvordan appletten eller tidsplanen deaktiveres i ét trin, og sæt en revisionsdato. En automatisering uden deaktiveringsvej bliver permanent infrastruktur den dag, dens forfatter skifter team.

Øv den i et laboratorium eller et vedligeholdelsesvindue med peer-valget bevidst brudt, så du finder ud af, om jobbet fejler sikkert. Øv derefter succesvejen, fordi et job, der kun kører, mens noget er galt, ikke lærer dig noget om sin normale adfærd.