Ang peer reset sa ASA ay nagbubura ng IPsec SA, hindi ng IKE state o mga session
Isang clear na limitado sa peer ang bumubuwag lamang sa IPsec data path. Tingnan kung ano ang natitira, bakit naikakabit muli ang tunnel sa ilang segundo at aling layer ang dapat linisin.
Bumabagsak ang tunnel para sa isang application, may nagpapatakbo ng IPsec clear na limitado sa peer, at isinasara ang ticket dahil tinanggap ang command. Wala sa sekwensiyang iyon ang nagpapakita na naayos ang depekto. Sa isang ASA ang salitang reset ay sumasaklaw sa tatlong magkahiwalay na saklaw, at ang clear na limitado sa peer ay tumatama sa eksaktong isa sa kanila, kaya madalas ay nakabangon na muli ang parehong tunnel bago pa matapos basahin ng operator ang output.
Tatlong saklaw ang nakatago sa likod ng isang salita
Ang pares ng IPsec SA ay ang data path mismo, isang association bawat direksiyon, may mga sequence number at counter. Ang IKE SA ay ang negotiation channel na lumikha ng mga association na iyon at hawak pa rin ang ugnayan sa peer. Ang session ng VPN ay ang rekord sa session database para sa isang user, peer na site-to-site o koneksiyong walang 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 |
Sapat na independyente ang mga saklaw kaya ang paglinis ng isa ay hinahayaang tumakbo ang iba, at ang independiyensiyang iyon ang lumilikha ng malaking bahagi ng kalituhan. Linisin ang mga IPsec SA habang malusog ang IKE SA, at ang trapiko ay mag-uudyok ng bagong association sa loob ng ilang segundo, kaya parang nagpagaling ang tunnel sa sarili nito. Ngunit ang hindi pagkakatugma ng proposal, ang puwang sa ruta o ang kabiguan sa authentication ay nandiyan pa rin.
Kung nasa negotiation ang depekto, walang binabago ang IPsec clear na mapapansin.
Basahin ang estado habang umiiral pa ito
Itala ang address ng peer, ang IKE version na ginagamit, ang mga protektadong network at ang mga counter ayon sa direksiyon bago hawakan ang anuman. Nagkakaiba ang mga suportadong view ayon sa release, ngunit matatag ang mga anyo: show crypto ipsec sa peer, show crypto ikev2 sa detailed o katumbas para sa IKEv1, at show vpn-sessiondb para sa layer ng session.
Isulat ang timestamp at ang eksaktong depektong nakikita ng user sa tabi ng output na iyon. Karaniwang may dalang ilang protektadong network ang isang peer, kaya ang saklaw ng isang clear na limitado sa peer ay bawat selector sa peer na iyon, hindi ang nag-iisang application sa ticket. Ang reset na walang larawan bago ay hindi masusuri pagkatapos, dahil binubura ng clear ang mismong mga counter na sana ay inihambing mo.
Kunin muna ang ebidensiya. Binubura ito ng clear, at ang screenshot na kinuha pagkatapos ay nagsasabi kung ano ang naibalik, hindi kung ano ang sira.
Ano ang aktuwal na ginagawa ng clear na limitado sa peer
Ang reference ng mga clear command ng Cisco ay nagdodokumento ng anyong IPsec na limitado sa peer. Kapag inilagay ang documentation address, ganito ang hitsura:
clear crypto ipsec sa peer 198.51.100.42Binubuwag ng command na iyon ang mga IPsec association na tumutugma sa peer. Hindi nito inaalis ang IKE SA, hindi binubura ang configuration at hindi nire-reset ang session database. Patakbuhin ito mula sa management path na hindi umaasa sa tunnel na binabago mo, dahil ang SSH session na dala sa loob ng tunnel na iyon ay mamamatay kasama nito at maaaring hindi na bumalik nang mag-isa. Patuloy na gumagana ang lahat ng iba pa sa device, at iyon mismo ang dahilan kung bakit parang walang panganib ang command.
Kapag hindi tiyak ang paghahanap ng target, huwag bumalik sa clear na walang kwalipikasyon. Naaabot ng mas malawak na anyo ang bawat peer sa device, at ang pagkaantala na iyong gagawin ay mas malaki kaysa sa dahilan kung bakit ka tinawag.
Beripikahin ang layer na gusto mong ayusin
Pagkatapos ng clear, kumpirmahin na bumalik ang mga association na may sariwang counter sa halip na ipagpalagay na gumana ang reset dahil napuno muli ang listahan ng peer. Pagkatapos ay subukan ang application na binanggit ng ticket, dahil ang matagumpay na ping ay walang sinasabi tungkol sa permiso ng serbisyo o sa isang session na nag-expire.
Kung muling nabuo ang mga association at nabibigo pa rin ang application, ang natitirang kandidato ay ang IKE layer at ang session layer. Piliin ang may estado pang masusuri mo. Gamitin ang naka-target na operasyon para sa version na aktuwal na tumatakbo, maging clear ng IKEv2, clear ng IKEv1 o clear ng session database na limitado sa tamang uri ng session. Ang pagbura at muling paggawa ng persistenteng crypto-map configuration para pilitin ang muling pagbuo ay hulaan na may mas mahabang rollback.
I-eskalo gamit ang dalawang larawan, bago at pagkatapos, sa halip na linisin muli.
Kapag pinahaba ng reset ang pagkaantala
Ang paulit-ulit na clear ay nagtatago ng mga depektong hindi kayang ayusin ng reset: nawawalang ruta, selector na hindi na tumutugma sa bagong subnet, pre-shared key na binago sa isang panig, o key renewal na paulit-ulit na nabibigo sa proposal na hindi tatanggapin ng peer. Bawat clear ay humaharang sa malusog na trapiko sa bawat selector ng peer na iyon habang ang tunay na dahilan ay nananatiling hindi nagalaw. Ganiyan nagiging window ng pagbabago ang limang minutong pagsisiyasat.
May gamit pa rin ang limitadong reset. Ang kapaki-pakinabang na bersiyon ay naka-target, naitala at sinusundan ng pagsusuri sa layer na dapat nitong ayusin.
Pagkakasunod ng trabaho: itala ang peer, version, selector at counter; kumpirmahin kung aling saklaw nabibilang ang depekto; patakbuhin ang pinakamakitid na tugmang clear; beripikahin ang mga association at ang application; i-eskalo gamit ang ebidensiya kung gumaling ang layer ngunit hindi nawala ang sintomas.