Cisco ASA til Azure VPN: prefikspar for trafikkvelgeren

Tunnelen kommer opp, IKE ser sunn ut, og ingenting går gjennom. Det er den vanlige formen på et ASA-til-Azure-velgerproblem, og derfor skriver jeg kontrakten før jeg rører noen av konsollene. Kontrakten er fire ting: objektene som identifiserer hver peer, tilkoblingsmodellen, de eksakte prefiksparene og verifiseringen som beviser hvert par. Tar du feil her, vil hver senere kommando feilsøke en konfigurasjon du ikke burde ha bygget. Denne runbooken er rekkefølgen jeg bruker, med kommandoene som viser hvilket objekt som faktisk er galt.

Skriv ned de fire objektene før du konfigurerer

Start med ASA-utgivelsen og -plattformen, det offentlige endepunktet, Azure VPN-gatewaytypen og -SKUen, og den lokale nettverksgatewayen som representerer din side. De fire navnene er vokabularet for alt som følger, og hver av dem har en annen eier når noe bryter.

Hvis to av dem fortsatt er gjetninger, stopp. En feil prefiksliste på den lokale nettverksgatewayen er ikke et tuningproblem.

Velg én tilkoblingsmodell og slutt å blande maler

En crypto map-design og en tunnel interface-design er forskjellige konfigurasjoner, og malen for den ene blir ikke gyldig for den andre ved å redigere peer-adressen. Noter hvilken du bygger før du limer inn noe, fordi avviket senere dukker opp som et velgerproblem og ikke som en konfigurasjonsfeil. Microsofts ASA-interoperabilitetsveiledning dekker begge mønstrene og sier hvilken Azure-gatewaymodell hver av dem forutsetter. Hvis notatene dine ikke navngir modellen, har du ennå ikke en design.

En rutbasert Azure-gateway med policybaserte trafikkvelgere er et spesifikt dokumentert alternativ, ikke standarden. Hvis designet ditt avhenger av det, må designet si det, fordi standard rutbasert velgermodell oppfører seg annerledes på Azure-siden.

Versjonsgrenser hører også hjemme i kontrakten. En gammel feltrapport om en grense for krypteringsdomener er et datapunkt om bestemte utgivelser, ikke en permanent egenskap ved hver ASA.

List opp prefiksparene, ikke aggregatene

Skriv matrisen. A og B lokalt til X og Y i Azure er fire par, og hvert av dem trenger dekning eller en eksplisitt utelukkelse. Å slå A og B sammen til ett aggregat inkluderer også det som ligger mellom dem, og slik vokser designet stille et hull.

Sjekk hva peerne forhandlet frem, ikke hva du lagret. Listen over lokale og eksterne nettverk på ASAen er intensjon; CHILD SAene er resultatet.

Når et par mangler, er rettelsen vanligvis en access-list-linje eller en velgeroppføring, ikke en ny tunnel.

Verifiser med kommandoer som navngir objektet

På ASAen bekreft IKE-økten, deretter IPsec SAene, deretter velgerparene. Hver kommando svarer på et annet spørsmål, og å kjøre bare den første er hvordan «tunnelen er oppe» blir en falsk konklusjon. Les utdataene for peeren du faktisk konfigurerte, ikke for SAen som tilfeldigvis er først i listen. Azure-siden svarer på de samme tre spørsmålene fra sitt eget ståsted.

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

Spør deretter Azure om tilkoblingstilstanden med az network vpn-connection show --name <connection> --query connectionStatus. Tilkoblet med null byte i databanen er et velgerproblem, ikke et rutingproblem.

Test én tillatt flyt per par, inspiser kildeadressen som sees på den andre siden, og prøv én ressurs som skal avvises. Bare den siste testen beviser at grensen fortsatt finnes.

Hold krypteringsomfanget atskilt fra tilgangstillatelsen

En bred velger er ikke tillatelse. Hvis oppsettet som støttes er bredere enn applikasjonspolicyen, hold de smale tjenestene i brannmurreglene og la krypteringsomfanget stå der det må.

Azure-arbeidsbelastningsruter og lokale returruter gjennomgås separat. BGP-annonseringer, statisk nettverksomfang og brukerdefinerte ruter må alle beskrive samme bane, og ingen av dem kan fange peer-transporten rekursivt.

Tilbakerulling og beviset på at det virket

Ta vare på forrige kjørende konfigurasjon før du endrer velgere, og kjenn den ene kommandoen som setter den tilbake. På ASAen betyr det en lagret kopi og den tilhørende gjenopprettingsbanen, ikke en erindring om hva du redigerte. Skriv gjenopprettingskommandoen i endringssaken mens endringen fortsatt er hypotetisk. Kjør deretter de samme tre sjekkene på nytt: IKE-status, IPsec SA-par, én tillatt flyt per par.

Hvis et par fortsatt feiler etter gjenopprettingen, var ikke endringen årsaken, og du har nettopp spart deg en andre driftsstans.