Cisco ASA naar Azure VPN: prefixparen van de traffic selector

De tunnel komt omhoog, IKE ziet er gezond uit en er gaat niets doorheen. Dat is de gebruikelijke vorm van een ASA-naar-Azure-selectorprobleem, en daarom schrijf ik het contract voordat ik een van beide consoles aanraak. Het contract bestaat uit vier dingen: de objecten die elke peer identificeren, het verbindingsmodel, de exacte prefixparen en de verificatie die elk paar bewijst. Doe dit fout en elk later commando debugt een configuratie die je niet had moeten bouwen. Dit runbook is de volgorde die ik gebruik, met de commando’s die laten zien welk object echt fout is.

Schrijf de vier objecten op voordat je configureert

Begin met de ASA-release en het platform, het openbare endpoint, het type en de SKU van de Azure VPN-gateway, en de lokale netwerkgateway die jouw kant vertegenwoordigt. Die vier namen zijn het vocabulaire voor alles wat volgt, en elk heeft een andere eigenaar als er iets stukgaat.

Als twee ervan nog gissingen zijn, stop. Een verkeerde prefixlijst op de lokale netwerkgateway is geen tuningprobleem.

Kies één verbindingsmodel en stop met het mixen van templates

Een crypto map-ontwerp en een tunnel interface-ontwerp zijn verschillende configuraties, en een template voor het ene wordt niet geldig voor het andere door het peeradres te wijzigen. Leg vast welke je bouwt voordat je iets plakt, want de mismatch komt later naar boven als een selectorprobleem en niet als een configuratiefout. De ASA-interoperabiliteitsgids van Microsoft behandelt beide patronen en vermeldt welk Azure-gatewaymodel elk veronderstelt. Als je notities het model niet noemen, heb je nog geen ontwerp.

Een route-based Azure-gateway met policy-based traffic selectors is een specifieke gedocumenteerde optie, niet de standaard. Als je ontwerp ervan afhangt, moet het ontwerp dat zeggen, omdat het standaard route-based selectormodel zich aan de Azure-kant anders gedraagt.

Versielimieten horen ook in het contract. Een oud veldrapport over een limiet op encryptiedomeinen is een datapunt over bepaalde releases, geen permanente eigenschap van elke ASA.

Som de prefixparen op, niet de aggregaten

Schrijf de matrix. On-premises A en B naar Azure X en Y zijn vier paren, en elk heeft dekking of een expliciete uitsluiting nodig. A en B samenvoegen tot één aggregaat omvat ook alles wat ertussen zit, en zo groeit een ontwerp stilletjes een gat.

Controleer wat de peers hebben onderhandeld, niet wat je hebt opgeslagen. De lijst met lokale en externe netwerken op de ASA is intentie; de CHILD SA’s zijn het resultaat.

Als een paar ontbreekt, is de oplossing meestal een access-listregel of een selectorvermelding, geen nieuwe tunnel.

Verifieer met commando’s die het object benoemen

Bevestig op de ASA de IKE-sessie, dan de IPsec SA’s, dan de selectorparen. Elk commando beantwoordt een andere vraag, en alleen de eerste uitvoeren is hoe «de tunnel staat omhoog» een verkeerde conclusie wordt. Lees de uitvoer voor de peer die je echt hebt geconfigureerd, niet voor de SA die toevallig bovenaan de lijst staat. De Azure-kant beantwoordt dezelfde drie vragen vanuit zijn eigen gezichtspunt.

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

Vraag Azure dan naar de verbindingsstatus met az network vpn-connection show --name <connection> --query connectionStatus. Verbonden met nul bytes in het datapad is een selectorprobleem, geen routingprobleem.

Test één toegestane stroom per paar, inspecteer het bronadres dat aan de andere kant te zien is, en probeer één resource die geweigerd zou moeten worden. Alleen die laatste test bewijst dat de grens nog bestaat.

Houd encryptiebereik gescheiden van toegangsrechten

Een brede selector is geen toestemming. Als de ondersteunde indeling breder is dan het applicatiebeleid, houd de smalle services in de firewallregels en laat het encryptiebereik waar het moet zijn.

Azure-workloadroutes en on-premises retourroutes worden apart beoordeeld. BGP-aankondigingen, statisch netwerkbereik en door de gebruiker gedefinieerde routes moeten allemaal hetzelfde pad beschrijven, en geen ervan mag het peertransport recursief vastleggen.

Rollback en het bewijs dat het werkte

Bewaar de vorige running configuration voordat je selectors wijzigt, en ken het ene commando dat hem terugzet. Op de ASA betekent dat een opgeslagen kopie en het bijbehorende herstelpad, niet een herinnering aan wat je hebt bewerkt. Schrijf het herstelcommando in de wijzigingsticket terwijl de wijziging nog hypothetisch is. Voer daarna dezelfde drie controles opnieuw uit: IKE-status, IPsec SA-paren, één toegestane stroom per paar.

Als een paar na het herstel nog steeds faalt, was de wijziging niet de oorzaak, en heb je jezelf net een tweede storing bespaard.