Kann eine WAN-Schnittstelle Site-to-Site- und Remote-VPN zugleich bedienen?

Eine öffentliche Adresse kann gleichzeitig einen Filialtunnel und einen Pool roamingnder Nutzer bedienen. Sie kann aber keine gemeinsame Zulassungsregel bedienen. Der Filial-Peer und der Roaming-Nutzer unterscheiden sich darin, wer sie zu sein behaupten, wie dieser Nachweis geprüft wird, welche Adressen sie erhalten und welche Präfixe ihnen antworten dürfen. Sobald Sie die Außenadresse als Transportdetail statt als Identität behandeln, wird das Design deutlich einfacher.

Ein schneller Plausibilitätstest: Versuchen Sie, beide Zulassungsdatensätze zu schreiben, bevor Sie den Router anfassen. Muss eine einzige Übereinstimmungsbedingung beide abdecken, ist die Policy bereits mehrdeutig, und das erste Symptom sieht wie ein Routing- oder Firewallfehler aus, obwohl es ein Identitätsfehler ist.

Zwei Datensätze vor jeder Konfiguration

Der Filialdatensatz ist kurz und stabil. Er listet die Peer-Adresse oder den Zertifikatsnamen, den vorab geteilten Schlüssel oder den Zertifikats-Trustpoint, die geschützten Subnetze auf beiden Seiten, die Tunnel-Schnittstelle und die statische Route, die filialgebundenen Verkehr in diesen Tunnel schickt. Jedes Feld betrifft einen bekannten Peer und eine feste Präfixmenge.

Der Roaming-Datensatz ist breiter und persönlicher. Er listet das Client-Protokoll und den Port, wie sich ein Nutzer oder Gerät authentifiziert, den Adresspool, der beim Verbinden ausgegeben wird, die Ressourcen, die dieser Pool erreichen darf, Split-Tunneling-Präfixe, DNS-Server, die an den Client geschoben werden, und einen etwaigen zweiten Faktor. Jedes Feld beantwortet eine Frage zu einer unbekannten Zahl von Nutzern statt zu einem Gateway.

Dieser Unterschied in der Granularität ist der ganze Grund, warum die beiden Rollen auseinandergehen. Ein Filialprofil kann einem einzigen Schlüssel sicher vertrauen, weil der Schlüssel zu einem Gerät an einem Standort gehört. Ein Roamingprofil, das einem Gruppenschlüssel für alle vertraut, zerstört die Nachvollziehbarkeit pro Nutzer, was meist erst später entdeckt wird, bei der Incident-Nachbereitung statt beim Rollout.

Wo Peer-Matching und Authentifizierung auseinandergehen

Auf IOS XE trägt das IKEv2-Profil die Parameter, über die nicht verhandelt werden kann, und die Bedingungen, mit denen der Peer ausgewählt wird. Das heißt, die Filialseite und die Roamingseite brauchen jeweils ein eigenes Profil, selbst wenn sie auf derselben Schnittstelle terminieren und selbst wenn sie eine gemeinsame Krypto-PKI teilen. Cisco beschreibt die Rollen von Profil, Authentifizierung und Matching in seinem Konfigurationsleitfaden für IKEv2 unter IOS XE 17.

Das Filialprofil passt üblicherweise auf eine enge Identität: eine entfernte Adresse, einen FQDN oder einen Zertifikats-Subject. Etwas wie match identity remote address 198.51.100.10 255.255.255.255 pinnt einen Peer fest, und authentication remote pre-share mit einem pro Standort gespeicherten Schlüssel genügt. Halten Sie das Matching so spezifisch, wie es das Peer-Inventar zulässt, denn ein überlappendes Wildcard weiter oben in der Auswahlreihenfolge kann Filialverkehr in das falsche Profil ziehen.

Das Roamingprofil kann keine Adresse festpinnen, also passt es auf eine Gruppe, eine Key-ID oder ein Zertifikatsfeld und übergibt die eigentliche Nutzerprüfung an AAA oder an die an das Profil gehängte Autorisierungsrichtlinie. Diese Trennung ist wichtig: Die Peer-Authentifizierung beantwortet, ob der Client einen Tunnel bauen darf, und die Autorisierung pro Nutzer beantwortet, welchen Pool und welche Ressourcen er bekommt. Den Filialschlüssel als universellen Login zu verwenden, wirft die zweite Antwort weg.

Weiterleitung und Übersetzung brauchen dieselbe Trennung

Zulassung und Erreichbarkeit sind getrennte Probleme. Ein erfolgreicher IKE- und IPsec-Austausch beweist, dass sich die Seiten über Schlüssel einig sind; er schafft keine Route zu dem Pool, den der Client erhalten hat. Remote-Access-Pools brauchen daher einen Rückweg, entweder eine statische Route auf die Tunnel-Schnittstelle oder ein Routing-Protokoll, das die Pool-Zusammenfassung einbringt. Filialpräfixe kommen meist über denselben Routingprozess, der den Rest des Standorts bedient.

Bei der Übersetzung kollidieren die beiden Rollen am häufigsten. Site-to-Site-Verkehr, der seine privaten Adressen behalten muss, braucht eine NAT-Ausnahme, die auf diese zwei Präfixe begrenzt ist, in beiden Richtungen. Roaming-Clients brauchen meist ebenfalls eine Ausnahme für ihren Verkehr im Tunnel, doch ihr internetgebundener Verkehr umgeht den Tunnel per Split-Tunneling oder verlässt den Hub nach NAT. Alles auszunehmen, was aus einem Tunnel kommt, ist der klassische Fehler, weil es auch Verkehr die Übersetzung nimmt, der sie wirklich braucht.

Halten Sie die Ausnahmeregeln so eng wie die Zulassungsregeln. Überlappen sich eine Pool-Zusammenfassung und ein Filialpräfix, wird der Rückweg mehrdeutig, lange bevor irgendein Paket verworfen wird, und das Symptom zeigt sich als ein Standort, der zeitweise ein Subnetz verliert, statt als sauberer Tunnelfehler.

Abnahmefälle, die eine gekreuzte Policy aufdecken

Bauen Sie vier Fälle und führen Sie sie der Reihe nach aus. Ein Host in der Filiale erreicht eine Nur-Filial-Ressource. Ein Roaming-Client erreicht dieselbe Ressource über seine Pool-Adresse. Ein Roaming-Client versucht ein Filialpräfix, das er nicht anfassen darf. Ein Filial-Peer versucht, eine Adresse aus dem Remote-Access-Pool zu beziehen. Die letzten beiden fangen ein geteiltes Profil, weil sie in der normalen Überwachung still scheitern.

Bestätigen Sie dann die Datenebene statt der Konfiguration. show crypto ikev2 sa und show crypto ipsec sa sagen, welches Profil und welche Selektoren jeden Fluss getragen haben, während show ip nat translations und die Tunnelzähler zeigen, ob Rückweg und Ausnahme tatsächlich gepasst haben. Ein Tracer oder Paketmitschnitt auf der Tunnel-Schnittstelle schließt die Schleife.

Notieren Sie die beobachtete Identität, die Pool-Adresse und die gewählte Policy neben jedem Ergebnis. Der Lauf ist fertig, wenn jeder Fall genau einem Datensatz entspricht und kein Fall eine vorübergehende Ausnahme braucht, um zu bestehen.