Cisco ASA nei Azure VPN: pearen fan prefiksen fan ferkearsselekteurs

De tunnel komt omheech, IKE liket sûn, en der giet neat trochhinne. Dat is de gewoane foarm fan in ASA-nei-Azure-selekteurprobleem, en dêrom skriuw ik it kontrakt foardat ik ien fan de twa konsoles oanrekke. It kontrakt binne fjouwer dingen: de objekten dy't elke peer identifisearje, it ferbinningsmodel, de krekte prefiksparen en de ferifikaasje dy't elk pear bewiist. Dochst dat ferkeard, dan debugt elk folgjend kommando in konfiguraasje dy'tst net boud hawwe moatten. Dizze runbook is de folchoarder dy't ik brûk, mei de kommando's dy't sjen litte hokker objekt eins ferkeard is.

Skriuw de fjouwer objekten op foardatst konfigurearrest

Begjin mei de ASA-útjefte en -platfoarm, it publike einpunt, it type en de SKU fan 'e Azure VPN-gateway, en de lokale netwurkgateway dy't dyn kant fertsjintwurdiget. Dy fjouwer nammen binne it wurdskat foar alles wat folget, en elk hat in oare eigner as der wat stikken giet.

As twa fan har noch gissings binne, stop dan. In ferkearde prefikslist op 'e lokale netwurkgateway is gjin ôfstellingsprobleem.

Kies ien ferbinningsmodel en hâld op mei it mingjen fan sjabloanen

In crypto-map-ûntwerp en in tunnel-interface-ûntwerp binne ferskillende konfiguraasjes, en in sjabloan foar de iene wurdt net jildich foar de oare troch it peer-adres te bewurkjen. Skriuw op hokkerst bouwest foardatst wat plakke, want de misstimming komt letter nei foaren as in selekteurprobleem en net as in konfiguraasjeflater. De ASA-ynteroperabiliteitsgids fan Microsoft beslacht beide patroanen en seit hokker Azure-gatewaymodel elk oannimt. As dyn notysjes it model net neame, hast noch gjin ûntwerp.

In op rûtes basearre Azure-gateway mei op belied basearre ferkearsselekteurs is in spesifike dokumintearre opsje, net de standert. As dyn ûntwerp dêrfan ôfhinklik is, moat it ûntwerp dat sizze, want it standert op rûtes basearre selekteurmodel hâldt him oan 'e Azure-kant oars.

Ferzje-beheiningen hearre ek by it kontrakt. In âld fjildrapport oer in limyt op fersiferingsdomeinen is in datapunt oer bepaalde útjeften, net in permaninte eigenskip fan elke ASA.

List de prefiksparen op, net de aggregaaten

Skriuw de matrix. Lokaal A en B nei Azure X en Y is fjouwer pearen, en elk hat itsij dekking itsij in eksplisite útsluting nedich. A en B yn ien aggregaat ferfetsje slút ek alles yn wat der tusken sit, en sa krijt in ûntwerp stil in gat.

Kontrolearje wat de peers úthannele hawwe, net watst bewarre hast. In list fan lokale en fiere netwurken op 'e ASA is bedoeling; de CHILD SA's binne it resultaat.

As in pear mist, is de oplossing meastal in access-list-rigel of in selekteuryngong, net in nije tunnel.

Ferifiearje mei kommando's dy't it objekt neame

Op 'e ASA, befêstigje de IKE-sesje, dan de IPsec SA's, dan de selekteurpearen. Elk kommando beantwurdet in oare fraach, en allinnich de earste rinne is hoe't de bewearing dat de tunnel omheech is in ferkearde konklúzje wurdt. Lês de útfier foar de peer dy'tst echt konfigurearre hast, net foar de SA dy't tafallich earst yn 'e list stiet. De Azure-kant beantwurdet deselde trije fragen fan syn eigen eachpunt.

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

Freegje Azure dan om 'e ferbiningstatus mei az network vpn-connection show --name <connection> --query connectionStatus. Connected mei nul bytes yn it datapaad is in selekteurprobleem, net in rûteprobleem.

Test ien tastiene stream per pear, besjoch it boarne-adres dat oan 'e oare kant te sjen is, en probearje ien boarne dy't wegere wurde moat. Dy lêste test is de iennichste dy't bewiist dat de grins noch bestiet.

Hâld fersiferingsomfang los fan tagongsrjocht

In breed selekteur is gjin tastimming. As de stipe yndieling breder is as it applikaasjebelied, hâld de smelle tsjinsten yn 'e firewallregels en litte it fersiferingsomfang dêr't it wêze moat.

Azure-wurkbelastingsrûtes en lokale weromrûtes wurde apart besjoen. BGP-oankundigingen, statysk netwurkomfang en brûker-definiearre rûtes moatte allegear itselde paad beskriuwe, en gjinien fan harren mei it peer-transport rekursyf fange.

Weromrollen en it bewiis dat it wurke

Bewarje de foarige rinnende konfiguraasje foardatst selekteurs feroarrest, en witten hokker ien kommando it weromset. Op 'e ASA betsjut dat in bewarre kopy en it byhearrende werstelpaad, net in oantinken oan watst bewurke hast. Skriuw it werstelkommando yn 'e feroaringskaart wylst de feroaring noch hypotetysk is. Rin dan deselde trije kontrôles wer: IKE-steat, IPsec SA-pearen, ien tastiene stream per pear.

As in pear nei it werstel noch altyd mislearret, wie de feroaring net de oarsaak, en hast krekt in twadde ûnderbrekking foar dysels besparre.