IKEv2-Profil definiert, aber nicht gebunden: die Kette nachverfolgen

Das IKEv2-Profil steht in der gespeicherten Konfiguration, der Keyring ist ebenfalls vorhanden, und der Tunnel kommt trotzdem nicht hoch. Auf Cisco IOS XE ist ein Profil ein Objekt, das Identitätsabgleich und Authentifizierungsoptionen trägt, und ein Objekt bewirkt nichts, bis ein anderes Objekt darauf verweist und eine Schnittstelle dieses Objekt an einen Pfad bindet. Die meisten fehlgeschlagenen Debugging-Sitzungen zu Phase 1 übersehen eine dieser Referenzen. Lesen Sie die Kette vom Keyring nach außen, bevor Sie einen Vorschlag oder eine Policy ändern.

Was ein Profilobjekt tatsächlich ist

Das IKEv2-Profil enthält den Abgleich der Remote-Identität, die lokalen und entfernten Authentifizierungsmethoden und einen Verweis auf einen Keyring für Designs mit Pre-Shared-Key. Es beschreibt, wie ein Peer erkannt wird und wie er sich ausweist, und es nennt keine Schnittstelle.

Der Keyring ist ein separates Objekt, das die Pre-Shared-Keys enthält. Die Crypto Map oder das IPsec-Profil ist ein drittes Objekt, das auf das IKEv2-Profil verweist und die Schutzparameter liefert. Die Schnittstellenbindung ist der vierte Schritt, bei dem eine Crypto Map angewendet oder Tunnel Protection aktiviert wird. Jeder Sprung ist eine eigene Referenz, und ein fehlender Sprung lässt jedes Objekt für sich korrekt aussehen.

Die Referenzkette der Reihe nach verfolgen

Beginnen Sie beim Keyring, den das Profil nennt, bestätigen Sie dann den Profilnamen, auf den die Crypto Map oder das IPsec-Profil verweist, und suchen Sie dann die Schnittstelle, die dieses letzte Objekt nutzt. Schreiben Sie jeden Namen neben das Objekt, das ihn nutzt; diese kurze Liste ist nützlicher, als zu prüfen, ob jeder erwartete Abschnitt irgendwo in der Konfiguration existiert.

Die üblichen Brüche sind mechanisch. Ein Profilname unterscheidet sich in einem Zeichen von dem, auf den die Crypto Map verweist. Die Crypto Map existiert, wurde aber nie auf die Schnittstelle angewendet. Der Befehl tunnel protection zeigt auf ein IPsec-Profil, das auf ein anderes IKEv2-Profil verweist. Ein Responder ohne ausdrückliche Bindung ist ein dokumentierter Fall, aber ein Initiator ohne Bindung ist schlicht nicht für den Pfad konfiguriert.

crypto ikev2 keyring KR-SITE
 peer SITE-B
  address 203.0.113.9
crypto ikev2 profile IKEV2-SITE
 match identity remote address 203.0.113.9 255.255.255.255
 keyring local KR-SITE
crypto ipsec profile IPSEC-SITE
 set ikev2-profile IKEV2-SITE
interface Tunnel100
 tunnel protection ipsec profile IPSEC-SITE

Lesen Sie das Snippet als Kette und nicht als Vorlage. Die Schnittstelle nennt das IPsec-Profil, das IPsec-Profil nennt das IKEv2-Profil, und das IKEv2-Profil nennt den Keyring. Brechen Sie einen dieser Namen, und die Konfiguration wird trotzdem geparst, weshalb der Router sie akzeptiert und der Tunnel unten bleibt.

Crypto Map und Tunnel Protection sind Alternativen

Cisco dokumentiert zwei Bindungsvarianten. Eine Crypto Map kann auf eine Schnittstelle angewendet werden und über ihren set-Befehl auf das IKEv2-Profil verweisen. Tunnel Protection bindet ein IPsec-Profil an eine Tunnelschnittstelle. Beide sind gültig, und sie sind nicht dafür gedacht, gemeinsam als zusätzliche Absicherung installiert zu werden.

Quelle und Ziel des Tunnels bestimmen die äußere Zustellung und sind von der Schutzbindung getrennt. Eine LAN-Schnittstelle, die Tunnelschnittstelle und die äußere Quellschnittstelle spielen drei verschiedene Rollen. Eine Crypto Map auf der LAN-Schnittstelle schützt den Tunnel nicht, und ein Tunnel mit aktiviertem Schutz, aber ohne erreichbare Quelladresse sendet nie ein Paket an seinen Peer.

Prüfen Sie den geladenen Zustand, nicht nur den Text. Die installierte Version hat Befehle, die die konfigurierten Objekte mit der ausgehandelten Sitzung verbinden, und diese sollten Sie in einem Ticket zitieren. Eine gespeicherte Konfiguration belegt die Absicht; eine Sitzungstabelle belegt den Pfad.

Die Responder-Ausnahme ist keine Regel für Initiatoren

Das IOS XE-Handbuch merkt an, dass eine ausdrückliche IKEv2-Profilbindung auf einem Responder optional sein kann. Diese Ausnahme hebt weder Authentifizierung noch Identitätsprüfungen auf, und sie macht das Profil auf der Seite, die die Verbindung startet, nicht optional.

Wenn Ihr Router initiiert, behandeln Sie die Bindung als Pflicht und verfolgen Sie sie durchgängig. Wenn Ihr Router nur antwortet, prüfen Sie, welches Profil tatsächlich zum eingehenden Peer passte, denn ein Responder kann ein Profil über die Identität statt über eine Schnittstellenreferenz auswählen.

Den Pfad prüfen, nicht die gespeicherte Konfiguration

Wenn die Bindungen stimmen, testen Sie eine erlaubte Anwendung und protokollieren Sie deren innere Quelle, ihr Ziel und ihre Route. Eine vom Router selbst gestartete Anfrage kann eine andere Quelladresse verwenden als Verkehr, der vom LAN weitergeleitet wird, und der Schutzbereich deckt möglicherweise nur eines von beiden ab.

Eine korrekt gebundene Definition belegt nicht, dass Selektoren, Rückroute und Schnittstellen-Policy Ihren Fluss abdecken. Senden Sie echten Verkehr und lesen Sie den ausgehandelten Zustand, und wiederholen Sie das nach einem Reconnect, damit Sie wissen, dass die Kette eine neue Aushandlung übersteht. Halten Sie die Erklärung auf IOS XE IKEv2 begrenzt; eine historische IKEv1-Crypto-Map-Bereitstellung hat ein anderes Objektmodell und sollte nicht mit dieser Kette debuggt werden.

Schreiben Sie die vier Namen in den Change Record, wenn der Tunnel läuft. Die nächste Person, die die Crypto Map anfasst, braucht sie, und die Kette ist der Teil des Designs, den die laufende Konfiguration nicht erklärt.