Cisco ASA zu Azure VPN: Präfixpaare der Traffic Selectors

Der Tunnel kommt hoch, IKE sieht gesund aus, und nichts geht hindurch. Das ist die übliche Form eines ASA-zu-Azure-Selector-Problems, und deshalb schreibe ich den Vertrag, bevor ich eine der beiden Konsolen anfasse. Der Vertrag besteht aus vier Dingen: den Objekten, die jeden Peer identifizieren, dem Verbindungsmodell, den exakten Präfixpaaren und der Prüfung, die jedes Paar belegt. Macht man diese falsch, debuggt jeder spätere Befehl eine Konfiguration, die man nicht hätte bauen sollen. Dieses Runbook ist die Reihenfolge, die ich verwende, mit den Befehlen, die zeigen, welches Objekt tatsächlich falsch ist.

Notieren Sie die vier Objekte, bevor Sie konfigurieren

Beginnen Sie mit ASA-Release und -Plattform, dem öffentlichen Endpunkt, Typ und SKU des Azure VPN Gateway und dem Local Network Gateway, das Ihre Seite repräsentiert. Diese vier Namen sind das Vokabular für alles Folgende, und jedes hat einen anderen Verantwortlichen, wenn etwas kaputtgeht.

Wenn zwei davon noch Vermutungen sind, hören Sie auf. Eine falsche Präfixliste im Local Network Gateway ist kein Tuning-Problem.

Wählen Sie ein Verbindungsmodell und mischen Sie keine Vorlagen

Ein Crypto-Map-Design und ein Tunnel-Interface-Design sind unterschiedliche Konfigurationen, und eine Vorlage für das eine wird nicht dadurch für das andere gültig, dass man die Peer-Adresse ändert. Halten Sie fest, welches Sie bauen, bevor Sie etwas einfügen, denn die Unstimmigkeit zeigt sich später als Selector-Problem und nicht als Konfigurationsfehler. Der Interoperabilitätsleitfaden für ASA von Microsoft deckt beide Muster ab und nennt, welches Azure-Gatewaymodell jeweils vorausgesetzt wird. Wenn Ihre Notizen das Modell nicht benennen, haben Sie noch kein Design.

Ein routenbasiertes Azure-Gateway mit policybasierten Traffic Selectors ist eine spezifische dokumentierte Option, nicht der Standard. Wenn Ihr Design davon abhängt, muss das Design es sagen, denn das routenbasierte Standard-Selector-Modell verhält sich auf der Azure-Seite anders.

Versionsgrenzen gehören ebenfalls in den Vertrag. Ein alter Felderfahrungsbericht über eine Obergrenze für Verschlüsselungsdomänen ist ein Datenpunkt zu bestimmten Releases, keine dauerhafte Eigenschaft jeder ASA.

Zählen Sie die Präfixpaare auf, nicht die Aggregate

Schreiben Sie die Matrix. Lokales A und B nach Azure X und Y sind vier Paare, und jedes braucht entweder Abdeckung oder einen ausdrücklichen Ausschluss. A und B zu einem Aggregat zusammenzufassen schließt auch alles ein, was dazwischen liegt, und so bekommt ein Design still ein Loch.

Prüfen Sie, was die Peers ausgehandelt haben, nicht was Sie gespeichert haben. Eine Liste lokaler und entfernter Netzwerke auf der ASA ist Absicht; die CHILD SAs sind das Ergebnis.

Wenn ein Paar fehlt, ist die Korrektur meist eine Access-List-Zeile oder ein Selector-Eintrag, kein neuer Tunnel.

Prüfen Sie mit Befehlen, die das Objekt benennen

Bestätigen Sie auf der ASA die IKE-Sitzung, dann die IPsec SAs, dann die Selector-Paare. Jeder Befehl beantwortet eine andere Frage, und nur den ersten auszuführen ist der Weg, auf dem aus der Aussage, der Tunnel sei oben, eine falsche Schlussfolgerung wird. Lesen Sie die Ausgabe für den Peer, den Sie tatsächlich konfiguriert haben, nicht für die SA, die zufällig die erste in der Liste ist. Die Azure-Seite beantwortet dieselben drei Fragen aus ihrer eigenen Sicht.

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

Fragen Sie dann Azure nach dem Verbindungsstatus mit az network vpn-connection show --name <connection> --query connectionStatus. Connected mit null Bytes im Datenpfad ist ein Selector-Problem, kein Routing-Problem.

Testen Sie einen erlaubten Fluss pro Paar, prüfen Sie die auf der Gegenseite sichtbare Quelladresse und versuchen Sie eine Ressource, die abgelehnt werden sollte. Dieser letzte Test ist der einzige, der beweist, dass die Grenze noch existiert.

Halten Sie den Verschlüsselungsumfang getrennt von der Zugriffsberechtigung

Ein breiter Selector ist keine Berechtigung. Wenn das unterstützte Layout breiter ist als die Anwendungsrichtlinie, behalten Sie die schmalen Dienste in den Firewallregeln und lassen Sie den Verschlüsselungsumfang dort, wo er sein muss.

Azure-Workload-Routen und lokale Rückrouten werden getrennt geprüft. BGP-Ankündigungen, statischer Netzwerkumfang und benutzerdefinierte Routen müssen alle denselben Pfad beschreiben, und keine davon darf den Peer-Transport rekursiv erfassen.

Rollback und der Beweis, dass er funktioniert hat

Behalten Sie die vorherige laufende Konfiguration, bevor Sie Selektoren ändern, und kennen Sie den einen Befehl, der sie zurücksetzt. Auf der ASA bedeutet das eine gespeicherte Kopie und den passenden Wiederherstellungspfad, nicht die Erinnerung daran, was Sie geändert haben. Schreiben Sie den Wiederherstellungsbefehl ins Change-Ticket, solange die Änderung noch hypothetisch ist. Führen Sie dann dieselben drei Prüfungen erneut aus: IKE-Status, IPsec-SA-Paare, ein erlaubter Fluss pro Paar.

Wenn ein Paar nach der Wiederherstellung immer noch fehlschlägt, war die Änderung nicht die Ursache, und Sie haben sich gerade einen zweiten Ausfall erspart.