Cisco ASA papuntang Azure VPN: Mga pares ng prefix ng tagapili ng trapiko
Isulat ang koneksyon ng ASA papuntang Azure VPN bilang kontrata: modelo ng koneksyon, eksaktong mga pares ng prefix, pagpapatunay ng tagapili, pagkatapos ay rollback. Isang runbook na tugma sa release.
Bumangon ang tunnel, mukhang malusog ang IKE, at walang dumadaan dito. Ito ang karaniwang hugis ng problema sa tagapili mula ASA papuntang Azure, at iyon ang dahilan kung bakit isinusulat ko ang kontrata bago hawakan ang alinman sa dalawang console. Ang kontrata ay apat na bagay: ang mga bagay na kumikilala sa bawat peer, ang modelo ng koneksyon, ang eksaktong mga pares ng prefix, at ang pagpapatunay na nagpapatunay sa bawat pares. Magkamali dito at bawat susunod na utos ay magde-debug ng isang configuration na hindi mo dapat itinayo. Ang runbook na ito ang pagkakasunod-sunod na ginagamit ko, kasama ang mga utos na nagpapakita kung aling bagay ang talagang mali.
Isulat ang apat na bagay bago mag-configure
Magsimula sa release at platform ng ASA, pampublikong endpoint, uri at SKU ng Azure VPN gateway, at lokal na network gateway na kumakatawan sa iyong panig. Ang apat na pangalang iyon ay bokabularyo para sa lahat ng susunod, at bawat isa ay may ibang may-ari kapag may nasira.
Kung dalawa sa kanila ay haka-haka pa, huminto. Ang maling listahan ng prefix sa lokal na network gateway ay hindi problema sa tuning.
Pumili ng isang modelo ng koneksyon at itigil ang paghahalo ng mga template
Ang disenyong crypto map at disenyong tunnel interface ay magkaibang configuration, at ang template ng isa ay hindi nagiging wasto para sa isa sa pamamagitan ng pag-edit ng address ng peer. Itala kung alin ang itinatayo mo bago i-paste ang anuman, dahil ang hindi pagkakatugma ay lumalabas mamaya bilang problema sa tagapili at hindi bilang error sa configuration. Sinasaklaw ng gabay sa interoperability ng ASA ng Microsoft ang dalawang pattern at isinasaad kung aling modelo ng Azure gateway ang ipinapalagay ng bawat isa. Kung hindi pinangalanan ng iyong mga tala ang modelo, wala ka pang disenyo.
Ang Azure gateway na batay sa ruta na may mga tagapili ng trapikong batay sa patakaran ay isang partikular na dokumentadong opsyon, hindi ang default. Kung umaasa ang iyong disenyo dito, dapat sabihin iyon ng disenyo, dahil iba ang kilos ng default na modelo ng tagapiling batay sa ruta sa panig ng Azure.
Ang mga limitasyon ng bersyon ay bahagi rin ng kontrata. Ang lumang ulat sa field tungkol sa limitasyon ng mga domain ng encryption ay datos tungkol sa partikular na mga release, hindi permanenteng katangian ng bawat ASA.
Bilangin ang mga pares ng prefix, hindi ang mga aggregate
Isulat ang matrix. Mula sa lokal na A at B patungong Azure X at Y ay apat na pares, at bawat isa ay nangangailangan ng saklaw o malinaw na pagbubukod. Ang pagsama ng A at B sa isang aggregate ay kasama rin ang lahat ng nasa pagitan nila, at ganoon tumutubo nang tahimik ang isang butas sa disenyo.
Suriin ang napagkasunduan ng mga peer, hindi ang inimbak mo. Ang listahan ng lokal at malayong network sa ASA ay intensyon; ang CHILD SA ang resulta.
Kapag kulang ang isang pares, ang pagwawasto ay karaniwang isang linya ng access-list o entry ng tagapili, hindi bagong tunnel.
Patunayan gamit ang mga utos na nagpapangalan sa bagay
Sa ASA kumpirmahin ang sesyon ng IKE, pagkatapos ang mga IPsec SA, pagkatapos ang mga pares ng tagapili. Bawat utos ay sumasagot sa ibang tanong, at ang pagpapatakbo lamang ng una ay ang paraan kung paano nagiging maling konklusyon ang «bumangon ang tunnel». Basahin ang output para sa peer na talagang na-configure mo, hindi para sa SA na nagkataong una sa listahan. Ang panig ng Azure ay sumasagot sa parehong tatlong tanong mula sa sarili nitong pananaw.
show crypto ikev2 sa detailed
show crypto ipsec sa peer 203.0.113.10
show run access-list AZURE-SELECTORS
packet-tracer input inside icmp 10.1.10.10 8 0 10.2.20.20 detailed
Pagkatapos tanungin ang Azure tungkol sa estado ng koneksyon gamit ang az network vpn-connection show --name <connection> --query connectionStatus. Nakakonekta na may zero byte sa landas ng datos ay problema sa tagapili, hindi sa routing.
Subukan ang isang pinapayagang daloy bawat pares, suriin ang source address na nakikita sa kabilang panig, at subukan ang isang resource na dapat tanggihan. Tanging ang huling pagsubok na iyon ang nagpapatunay na umiiral pa ang hangganan.
Panatilihing hiwalay ang saklaw ng encryption sa pahintulot sa pag-access
Ang malawak na tagapili ay hindi pahintulot. Kung ang sinusuportahang layout ay mas malawak kaysa sa patakaran ng application, panatilihin ang makitid na serbisyo sa mga patakaran ng firewall at iwanan ang saklaw ng encryption kung saan dapat ito.
Ang mga ruta ng workload ng Azure at mga ruta ng pagbabalik sa lokal ay hiwalay na sinusuri. Ang mga anunsyo ng BGP, static na saklaw ng network at mga rutang tinukoy ng gumagamit ay dapat ilarawan ang parehong landas, at wala sa kanila ang maaaring humuli nang paulit-ulit sa transport ng peer.
Rollback at ang patunay na gumana ito
Itago ang nakaraang running configuration bago baguhin ang mga tagapili, at alamin ang nag-iisang utos na nagbabalik nito. Sa ASA nangangahulugan iyon ng naka-save na kopya at tugmang landas ng pagpapanumbalik, hindi memorya ng kung ano ang in-edit mo. Isulat ang utos ng pagpapanumbalik sa ticket ng pagbabago habang hypothetical pa ang pagbabago. Pagkatapos ay patakbuhin muli ang parehong tatlong pagsusuri: estado ng IKE, mga pares ng SA ng IPsec, isang pinapayagang daloy bawat pares.
Kung nabigo pa rin ang isang pares pagkatapos ng pagpapanumbalik, hindi ang pagbabago ang dahilan, at katatapos mo lang iligtas ang iyong sarili sa ikalawang pagkaabala.