Cisco ASA és Azure VPN: forgalomszelektor-előtagpárok

Az alagút feljön, az IKE egészségesnek tűnik, és semmi nem halad át rajta. Ez az ASA–Azure szelektorprobléma szokásos formája, és ezért írom meg a szerződést, mielőtt bármelyik konzolhoz nyúlnék. A szerződés négy dolog: az egyes partnereket azonosító objektumok, a kapcsolódási modell, a pontos előtagpárok és az ellenőrzés, amely minden párt bizonyít. Ha ezeket elrontja, minden későbbi parancs egy olyan konfigurációt debugol, amelyet nem lett volna szabad megépítenie. Ez a runbook az általam használt sorrend, azokkal a parancsokkal, amelyek megmutatják, melyik objektum valójában hibás.

A konfigurálás előtt írja fel a négy objektumot

Kezdje az ASA kiadásával és platformjával, a nyilvános végponttal, az Azure VPN-átjáró típusával és SKU-jával, valamint a helyi hálózati átjáróval, amely az Ön oldalát képviseli. Ez a négy név minden további dolog szótára, és mindegyiknek más a tulajdonosa, amikor valami elromlik.

Ha ezek közül kettő még találgatás, álljon meg. A helytelen előtaglista a helyi hálózati átjárón nem hangolási probléma.

Válasszon egy kapcsolódási modellt, és hagyja abba a sablonok keverését

A crypto map kialakítás és a tunnel interface kialakítás különböző konfigurációk, és az egyik sablonja nem válik érvényessé a másik számára a partner címének szerkesztésével. Jegyezze fel, melyiket építi, mielőtt bármit beilleszt, mert az eltérés később szelektorproblémaként jelenik meg, nem konfigurációs hibaként. A Microsoft ASA-interoperabilitási útmutatója mindkét mintát lefedi, és megmondja, melyik Azure-átjárómodellt feltételezi mindegyik. Ha a jegyzetei nem nevezik meg a modellt, még nincs kialakítása.

A házirend-alapú forgalomszelektorokkal rendelkező útvonal-alapú Azure-átjáró egy konkrét, dokumentált lehetőség, nem az alapértelmezés. Ha a kialakítása ettől függ, a kialakításnak ezt ki kell mondania, mert az alapértelmezett útvonal-alapú szelektormodell az Azure oldalán másképp viselkedik.

A verziókorlátok is a szerződéshez tartoznak. A titkosítási tartományok felső korlátjáról szóló régi terepi jelentés adott kiadásokra vonatkozó adat, nem minden ASA állandó tulajdonsága.

Az előtagpárokat sorolja fel, ne az összesítéseket

Írja meg a mátrixot. A helyi A és B az Azure X és Y felé négy pár, és mindegyiknek vagy lefedettségre vagy kifejezett kizárásra van szüksége. Az A és B egyetlen összesítésbe vonása mindent magában foglal, ami közöttük van, és így lesz a kialakításban csendesen egy lyuk.

Azt ellenőrizze, miről egyeztek meg a partnerek, ne azt, amit mentett. A helyi és távoli hálózatok listája az ASA-n szándék; a CHILD SA-ok az eredmény.

Ha egy pár hiányzik, a javítás általában egy access-list sor vagy egy szelektorbejegyzés, nem új alagút.

Az objektumot megnevező parancsokkal ellenőrizzen

Az ASA-n erősítse meg az IKE-munkamenetet, majd az IPsec SA-okat, majd a szelektorpárokat. Minden parancs más kérdésre válaszol, és csak az első futtatása az az út, amelyen az az állítás, hogy az alagút fent van, hamis következtetéssé válik. A kimenetet ahhoz a partnerhez olvassa, amelyet valóban konfigurált, ne ahhoz az SA-hoz, amely véletlenül az első a listán. Az Azure oldala ugyanarra a három kérdésre a saját nézőpontjából válaszol.

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

Ezután kérdezze meg az Azure-t a kapcsolat állapotáról a az network vpn-connection show --name <connection> --query connectionStatus paranccsal. A Connected nulla bájttal az adatútvonalon szelektorprobléma, nem útvonalválasztási probléma.

Teszteljen egy engedélyezett folyamot páronként, vizsgálja meg a túloldalon látott forráscímet, és próbáljon ki egy erőforrást, amelyet el kellene utasítani. Az utolsó teszt az egyetlen, amely bizonyítja, hogy a határ még létezik.

Tartsa külön a titkosítási hatókört a hozzáférési engedélytől

A széles szelektor nem engedély. Ha a támogatott elrendezés szélesebb az alkalmazásházirendnél, tartsa a szűk szolgáltatásokat a tűzfalszabályokban, és hagyja a titkosítási hatókört ott, ahol lennie kell.

Az Azure-beli számítási feladatok útvonalait és a helyi visszatérési útvonalakat külön vizsgálják. A BGP-hirdetéseknek, a statikus hálózati hatókörnek és a felhasználó által meghatározott útvonalaknak mind ugyanazt az útvonalat kell leírniuk, és egyik sem foghatja el rekurzívan a partner átvitelét.

Visszaállítás és a bizonyíték, hogy működött

A szelektorok módosítása előtt mentse el az előző futó konfigurációt, és ismerje azt az egy parancsot, amely visszaállítja. Az ASA-n ez mentett másolatot és a hozzá tartozó helyreállítási útvonalat jelent, nem annak emlékét, hogy mit szerkesztett. Írja be a helyreállítási parancsot a változásjegybe, amíg a változás még hipotetikus. Ezután futtassa újra ugyanazt a három ellenőrzést: IKE állapot, IPsec SA párok, egy engedélyezett folyam páronként.

Ha egy pár a helyreállítás után is meghiúsul, a változás nem volt az ok, és éppen megspórolt magának egy második kiesést.