Automatisere ASA-tunnelreset: tre porter før du tillater det

Se på en automatisk tunnelreset som en gjenopprettingshandling med en eksplosjonsradius, ikke som et planlagt humørsving. Beslutningen foran deg er smalere enn verktøyet antyder: hvilken feil som rettferdiggjør den, hvilken peer den kan berøre, og hva som får den til å stoppe. Tar du feil på disse tre, har du bygget en maskin for å slette bevis. Jeg har sett en av disse fyre hvert femtende minutt mot en frisk peer i det meste av en uke, og ingen la merke til det fordi tunnelen kom tilbake hver gang.

Port én: bevis at feilen ligger inne i tunnelen

Korreler fersk tilstand før du godkjenner noe. show crypto ikev2 sa detailed forteller deg om IKEv2-assosiasjonen finnes og hvor langt forhandlingen kom, og show vpn-sessiondb detail l2l gir sesjonsvisningen som passer til samme peer. Deretter viser show crypto ipsec sa peer 203.0.113.10 barne-SA-ene, encaps- og decaps-tellerne og velgerne som brukes. En stigende encaps-teller med flat decaps-teller er et helt annet problem enn ingen assosiasjon i det hele tatt.

Deretter sjekker du hva en gjenoppbygging ikke kan reparere: en manglende returrute, en MTU som sluker store pakker, en policy som avviser porten etter dekryptering, eller asymmetrisk ruting som sender svar rundt enheten. Å slette SA-er mot noe av dette gir et kort grønt blink og samme billett i morgen. Hver av dem ser ut som en død tunnel fra applikasjonssiden, derfor betyr tellerne mer enn alarmen.

Ta et øyeblikksbilde før handlingen. Noter peeren, assosiasjonsidentifikatorene, tellerne i utløserøyeblikket og bevisene som utløste det. En reset som løper foran øyeblikksbildet ødelegger de mest nyttige dataene hendelsen hadde.

Port to: begrens omfanget til peeren, aldri 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 operasjoner. De samme kommandoene uten peer-argument sletter hver assosiasjon i konteksten, noe som gjør dem til en skrivevariant og til et avbrudd i effekt. Ciscos referanse for slettekommandoer skiller disse formene fra statistikkvarianten, som nullstiller tellere og ikke reparerer noe. I flerkontekstmodus virker kommandoen bare på gjeldende kontekst, så automatiseringen må også vite hvilken kontekst den er i.

Valider peeren før kommandoen bygges. En tom eller uløst variabel må feile jobben høyt i stedet for å kollapse til en clear-all, og den kontrollen hører hjemme i kode en anmelder kan lese.

Kartlegg eksplosjonsradiusen ærlig. Én peer kan bære flere beskyttede nettverk, tusenvis av sesjoner og en andre tunnel for administrasjon, så en peer-begrenset sletting er fortsatt en hendelse for flere kunder på en hub. Kjør handlingen fra en administrasjonsvei som ikke avhenger av tunnelen som nullstilles. Ellers kan ikke automatiseringen verifisere sitt eget resultat, og neste steg er et menneske som kjører til stedet.

Port tre: nye forsøk, nedkjøling, definert suksess

Gi jobben en lås per peer, en nedkjølingsperiode og en hard forsøksgrense som telles fra ferske observasjoner. Uten låsen sletter to monitorer som utløses i samme øyeblikk samme peer mens reforhandlingen pågår, og hver konkluderer med at den andre feilet.

Suksess betyr at assosiasjonen er tilbake og den tillatte arbeidslasten passerer, ikke at kommandoen kom tilbake uten feil. Probe med samme kontroll som oppdaget feilen, og bekreft deretter at barne-SA-tellerne beveger seg i begge retninger. En kommando som avslutter med null mens tunnelen blir nede, er en overvåkingsfeil kledd som gjenoppretting.

Hold ukjent adskilt fra mislykket. Hvis telemetrien er utdatert eller administrasjonsveien er utilgjengelig, er den ærlige tilstanden ukjent, og et budsjett for nye forsøk bør ikke lese det som tillatelse til å fyre igjen.

Når den første godkjente gjenopprettingen ikke gjenoppretter tjenesten, eskaler med øyeblikksbildet i stedet for å loope. Planlagte resets er den verste versjonen av mønsteret, fordi de skjuler en feil i nøkkelnying, rute eller policy mens de kutter friske sesjoner på en timer.

Eierskap, en avbryter og én øvelse

Navngi en eier, dokumenter hvordan appletten eller tidsplanen deaktiveres i ett steg, og sett en revisjonsdato. Automasjon uten deaktiveringsvei blir permanent infrastruktur den dagen forfatteren bytter team.

Øv på den i et laboratorium eller et vedlikeholdsvindu med peer-valget bevisst ødelagt, så du finner ut om jobben feiler lukket. Øv deretter suksessveien, fordi en jobb som bare kjører mens noe er galt, ikke lærer deg noe om normal oppførsel.