Cisco ASA k Azure VPN: dvojice prefixů selektorů provozu

Tunel se zvedne, IKE vypadá zdravě a nic přes něj neprochází. To je obvyklý tvar problému se selektory ASA k Azure, a proto píšu smlouvu dřív, než se dotknu kterékoliv z obou konzolí. Smlouva jsou čtyři věci: objekty, které identifikují každý protějšek, model připojení, přesné dvojice prefixů a ověření, které každou dvojici prokáže. Popleťte je a každý další příkaz ladí konfiguraci, kterou jste neměli stavět. Tento runbook je pořadí, které používám, spolu s příkazy, které ukážou, který objekt je skutečně špatný.

Než začnete konfigurovat, zapište čtyři objekty

Začněte vydáním a platformou ASA, veřejným koncovým bodem, typem a SKU brány Azure VPN a místní síťovou bránou, která zastupuje vaši stranu. Tyto čtyři názvy jsou slovník pro všechno, co následuje, a každý má jiného vlastníka, když se něco rozbije.

Pokud jsou dva z nich stále dohady, zastavte se. Špatný seznam prefixů v místní síťové bráně není problém ladění.

Vyberte jeden model připojení a přestaňte míchat šablony

Návrh s crypto map a návrh s tunnel interface jsou různé konfigurace a šablona pro jeden se úpravou adresy protějšku nestane platnou pro druhý. Zapište si, který stavíte, než něco vložíte, protože nesoulad se později projeví jako problém se selektory, ne jako chyba konfigurace. Průvodce interoperabilitou ASA od Microsoftu pokrývá oba vzory a uvádí, který model brány Azure každý předpokládá. Pokud vaše poznámky model nepojmenují, ještě nemáte návrh.

Brána Azure založená na trasách se selektory provozu založenými na zásadách je konkrétní dokumentovaná volba, ne výchozí. Pokud na ní váš návrh závisí, musí to návrh říct, protože výchozí model selektorů založený na trasách se na straně Azure chová jinak.

Omezení verzí patří do smlouvy také. Starý terénní záznam o stropu šifrovacích domén je údaj o konkrétních vydáních, ne trvalá vlastnost každé ASA.

Vypište dvojice prefixů, ne agregáty

Napište matici. Místní A a B k Azure X a Y jsou čtyři dvojice a každá potřebuje buď pokrytí, nebo výslovné vyloučení. Sloučení A a B do jednoho agregátu zahrne i všechno mezi nimi, a tak návrh tiše získá díru.

Kontrolujte, na čem se protějšky dohodly, ne co jste uložili. Seznam místních a vzdálených sítí na ASA je úmysl; CHILD SA jsou výsledek.

Když dvojice chybí, oprava je obvykle řádek access-listu nebo položka selektoru, ne nový tunel.

Ověřujte příkazy, které pojmenují objekt

Na ASA potvrďte relaci IKE, pak IPsec SA, pak dvojice selektorů. Každý příkaz odpovídá na jinou otázku a spuštění jen prvního je způsob, jak se z tvrzení, že tunel je nahoře, stane chybný závěr. Čtěte výstup pro protějšek, který jste skutečně nakonfigurovali, ne pro to SA, které je náhodou první v seznamu. Strana Azure odpovídá na stejné tři otázky ze svého pohledu.

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

Pak se Azure zeptejte na stav připojení pomocí az network vpn-connection show --name <connection> --query connectionStatus. Connected s nulou bajtů v datové cestě je problém selektorů, ne směrování.

Otestujte jeden povolený tok na dvojici, prohlédněte zdrojovou adresu viditelnou na druhé straně a zkuste jeden prostředek, který má být odmítnut. Ten poslední test jako jediný dokazuje, že hranice stále existuje.

Držte rozsah šifrování odděleně od oprávnění přístupu

Široký selektor není oprávnění. Pokud je podporované uspořádání širší než zásada aplikace, ponechte úzké služby v pravidlech firewallu a rozsah šifrování tam, kde musí být.

Trasy úloh Azure a zpětné trasy místní sítě se posuzují odděleně. Ohlášení BGP, statický rozsah sítě a trasy definované uživatelem musí všechny popisovat stejnou cestu a žádná z nich nesmí rekurzivně zachytit transport protějšku.

Návrat zpět a důkaz, že fungoval

Před změnou selektorů si uložte předchozí běžící konfiguraci a vězte jediný příkaz, který ji vrátí. Na ASA to znamená uloženou kopii a odpovídající cestu obnovy, ne vzpomínku na to, co jste upravili. Napište příkaz pro obnovu do tiketu změny, dokud je změna ještě hypotetická. Pak znovu spusťte stejné tři kontroly: stav IKE, dvojice IPsec SA, jeden povolený tok na dvojici.

Pokud dvojice po obnově stále selhává, změna nebyla příčinou a právě jste si ušetřili druhý výpadek.