Tunnelen faller for én enkelt applikasjon, noen kjører en peer-begrenset IPsec-clear, og saken lukkes fordi kommandoen ble godtatt. Ingenting i den sekvensen viser at feilen ble rettet. På en ASA dekker ordet reset tre atskilte områder, og den peer-begrensede clearen berører nøyaktig ett av dem, og derfor er samme tunnel ofte oppe igjen før operatøren har lest ferdig utskriften.

Tre områder skjuler seg bak ett ord

Et IPsec-SA-par er selve databanen, én assosiasjon per retning, med sekvensnumre og tellere. En IKE-SA er forhandlingskanalen som laget disse assosiasjonene og fortsatt holder peer-forholdet sammen. En VPN-sesjon er posten i sesjonsdatabasen for en bruker, en site-til-site-peer eller en klientløs forbindelse.

ScopeWhat a clear removesWhat usually survives
IPsec SAData-path associations for the matching peer or selectorIKE SA, session records, crypto-map or tunnel-group config
IKE SANegotiation channel and the IPsec children derived from itSession records until they age out or are cleared
VPN sessionSession-database entry for that user or peer typeConfiguration, and any SA that is not tied to the session

Områdene er uavhengige nok til at tømming av ett lar de andre gå, og den uavhengigheten skaper mesteparten av forvirringen. Tøm IPsec-SA-ene mens IKE-SA-en er sunn, og trafikk utløser ferske assosiasjoner i løpet av sekunder, så tunnelen ser ut til å ha leget seg selv. Den bakenforliggende proposal-avviket, rutegapet eller autentiseringsfeilen er fortsatt der.

Hvis feilen ligger i forhandlingen, endrer en IPsec-clear ingenting du kan observere.

Les tilstanden mens den fortsatt finnes

Noter peer-adressen, IKE-versjonen som brukes, de beskyttede nettene og retningstellene før du rører noe. De støttede visningene varierer etter versjon, men formene er stabile: show crypto ipsec sa peer, show crypto ikev2 sa detailed eller IKEv1-motstykket, og show vpn-sessiondb for sesjonslaget.

Skriv tidsstempelet og den nøyaktige brukervisbare feilen ved siden av den utskriften. En peer bærer ofte flere beskyttede nett, så slagradiusen til en peer-begrenset clear er hver selector på den peeren, ikke den ene applikasjonen i saken. En reset uten før-bilde kan ikke diagnostiseres i ettertid, fordi clearen sletter nettopp tellerne du ville sammenlignet med.

Sikre bevisene først. Clearen fjerner dem, og et skjermbilde tatt etterpå forteller hva som ble bygget opp igjen, ikke hva som var ødelagt.

Hva den peer-begrensede clearen faktisk gjør

Ciscos referanse for clear-kommandoer dokumenterer den peer-begrensede IPsec-formen. Med en dokumentasjonsadresse satt inn ser den slik ut:

clear crypto ipsec sa peer 198.51.100.42

Kommandoen river ned IPsec-assosiasjonene som passer til peeren. Den fjerner ikke IKE-SA-en, sletter ikke konfigurasjon og nullstiller ikke sesjonsdatabasen. Kjør den fra en administrasjonsvei som ikke avhenger av tunnelen du endrer, fordi en SSH-sesjon som bæres inne i den tunnelen dør med den og kommer kanskje ikke tilbake av seg selv. Alt annet på enheten fortsetter å gå, og nettopp derfor føles kommandoen ufarlig.

Når målsøket er usikkert, fall ikke tilbake på en ukvalifisert clear. Den bredere formen når hver peer på enheten, og utfallet du skaper blir større enn det du ble tilkalt for.

Verifiser laget du mente å reparere

Etter clearen, bekreft at assosiasjonene kom tilbake med ferske tellere i stedet for å anta at reseten virket fordi peer-listen ble fylt på nytt. Test deretter applikasjonen saken nevnte, fordi en vellykket ping ikke sier noe om en tjenestetillatelse eller en utløpt sesjon.

Hvis assosiasjonene bygges opp igjen og applikasjonen fortsatt feiler, er de gjenværende kandidatene IKE-laget og sesjonslaget. Velg det du fortsatt kan inspisere tilstanden til. Bruk den målrettede operasjonen for versjonen som faktisk kjører, enten det er en IKEv2-clear, en IKEv1-clear eller en sesjonsdatabase-clear begrenset til riktig sesjonstype. Å slette og gjenopprette vedvarende crypto-map-konfigurasjon for å tvinge frem en gjenoppbygging er gjetting med lengre tilbakerulling.

Eskaler med begge bildene, før og etter, i stedet for å tømme igjen.

Når reseten gjør utfallet lengre

Gjentatte clears skjuler feilene en reset ikke kan rette: en manglende rute, en selector som ikke lenger passer det nye subnettet, en forhåndsdelt nøkkel endret på én side, eller en nøkkelfornyelse som feiler gang på gang på et forslag peeren ikke vil godta. Hver clear avbryter sunn trafikk på hver selector til den peeren mens den egentlige årsaken forblir urørt. Slik blir en fem minutters undersøkelse til et endringsvindu.

En avgrenset reset er fortsatt nyttig. Den nyttige versjonen er målrettet, dokumentert og fulgt av en inspeksjon av laget den skulle reparere.

Arbeidsrekkefølge: noter peer, versjon, selectors og tellere; bekreft hvilket område feilen hører til; kjør den smaleste clearen som passer; verifiser assosiasjoner og applikasjon; eskaler med bevis hvis laget kommer seg men symptomet ikke forsvinner.

Relaterte artikler