Cisco ASA till Azure VPN: prefixpar för trafikväljaren

Tunneln kommer upp, IKE ser frisk ut och ingenting går igenom. Det är den vanliga formen av ett ASA-till-Azure-väljarproblem, och därför skriver jag kontraktet innan jag rör någon av konsolerna. Kontraktet är fyra saker: objekten som identifierar varje peer, anslutningsmodellen, de exakta prefixparen och verifieringen som bevisar varje par. Gör fel här och varje senare kommando felsöker en konfiguration du inte borde ha byggt. Den här runbooken är ordningen jag använder, med kommandona som visar vilket objekt som faktiskt är fel.

Skriv ner de fyra objekten innan du konfigurerar

Börja med ASA-utgåvan och plattformen, den publika slutpunkten, Azure VPN-gatewayens typ och SKU samt den lokala nätverksgatewayen som representerar din sida. De fyra namnen är vokabulären för allt som följer, och var och en har en annan ägare när något går sönder.

Om två av dem fortfarande är gissningar, stanna. En felaktig prefixlista på den lokala nätverksgatewayen är inte ett inställningsproblem.

Välj en anslutningsmodell och sluta blanda mallar

En crypto map-design och en tunnel interface-design är olika konfigurationer, och mallen för den ena blir inte giltig för den andra genom att redigera peer-adressen. Anteckna vilken du bygger innan du klistrar in något, eftersom avvikelsen senare dyker upp som ett väljarproblem och inte som ett konfigurationsfel. Microsofts ASA-interoperabilitetsguide täcker båda mönstren och anger vilken Azure-gatewaymodell var och en förutsätter. Om dina anteckningar inte namnger modellen har du ännu ingen design.

En rutbaserad Azure-gateway med policybaserade trafikväljare är ett specifikt dokumenterat alternativ, inte standard. Om din design beror på det måste designen säga det, eftersom den rutbaserade standardmodellen för väljare beter sig annorlunda på Azure-sidan.

Versionsgränser hör också till kontraktet. En gammal fältrapport om en gräns för krypteringsdomäner är en datapunkt om särskilda utgåvor, inte en permanent egenskap hos varje ASA.

Räkna upp prefixparen, inte aggregaten

Skriv matrisen. Från lokala A och B till Azure X och Y är fyra par, och varje par behöver täckning eller ett uttryckligt undantag. Att slå ihop A och B till ett aggregat inkluderar också allt som ligger mellan dem, och så växer designen tyst ett hål.

Kontrollera vad peerarna förhandlade fram, inte vad du sparade. Listan över lokala och avlägsna nätverk på ASA:n är avsikt; CHILD SA:erna är resultatet.

När ett par saknas är rättelsen oftast en access-list-rad eller en väljaruppgift, inte en ny tunnel.

Verifiera med kommandon som namnger objektet

På ASA:n bekräfta IKE-sessionen, sedan IPsec SA:erna, sedan väljarparen. Varje kommando svarar på en annan fråga, och att bara köra det första är hur «tunneln är uppe» blir en falsk slutsats. Läs utdata för den peer du faktiskt konfigurerade, inte för det SA som råkar vara först i listan. Azure-sidan svarar på samma tre frågor från sin egen synvinkel.

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

Fråga sedan Azure om anslutningsstatusen med az network vpn-connection show --name <connection> --query connectionStatus. Ansluten med noll byte i datavägen är ett väljarproblem, inte ett routingproblem.

Testa ett tillåtet flöde per par, inspektera källadressen som syns på andra sidan och prova en resurs som borde nekas. Bara det sista testet bevisar att gränsen fortfarande finns.

Håll krypteringsomfånget skilt från åtkomstbehörigheten

En bred väljare är inte behörighet. Om den layout som stöds är bredare än applikationspolicyn, håll de smala tjänsterna i brandväggsreglerna och låt krypteringsomfånget stå där det måste vara.

Azure-arbetsbelastningsrutter och lokala returrutter granskas separat. BGP-annonseringar, statiskt nätverksomfång och användardefinierade rutter måste alla beskriva samma väg, och ingen av dem får fånga peer-transporten rekursivt.

Återställning och beviset att det fungerade

Spara den föregående körande konfigurationen innan du ändrar väljare, och känn till det enda kommando som sätter tillbaka den. På ASA:n betyder det en sparad kopia och motsvarande återställningsväg, inte ett minne av vad du redigerade. Skriv återställningskommandot i ändringsärendet medan ändringen fortfarande är hypotetisk. Kör sedan samma tre kontroller igen: IKE-status, IPsec SA-par, ett tillåtet flöde per par.

Om ett par fortfarande misslyckas efter återställningen var ändringen inte orsaken, och du har just sparat dig ett andra avbrott.