Wie die hybride IKEv1-Authentifizierung in die IKEv2-Benutzerauthentifizierung übergeht
Der Hybridmodus trennte den Nachweis des Gateways vom Nachweis des Benutzers. Der Wechsel zu IKEv2 behält diese Trennung, ändert aber den Austausch, die EAP-Methode und die Zertifikatsprüfungen.
Jedes alte VPN-Profil, das erst ein Serverzertifikat und dann einen Benutzernamen verlangt, trägt zwei Authentifizierungsvorgänge in einem einzigen Austausch, und diese Form überlebt das Protokoll, das sie eingeführt hat. Der IKEv1-Hybridmodus wurde genau dafür gebaut: Das Gateway weist sich mit einem öffentlichen Schlüssel aus, der Benutzer weist sich später über XAuth aus. IKEv2 drückt dieselbe Zwei-Schritt-Idee mit anderer Mechanik aus, und in diesen Unterschieden scheitern Migrationen. Keine Versionsnummer wandelt das eine in das andere um, und wer die alten Optionsnamen in ein neues Profil kopiert, erhält einen Client, der aushandelt und dann nichts authentifiziert.
Was der Hybridmodus in IKEv1 tat
In einem Hybridprofil signiert der Responder den Austausch der Phase eins mit seinem Zertifikat, während der Initiator bewusst keines vorlegt. Der Identitätsnachweis ist also asymmetrisch, und genau das erlaubte es einem Gateway, seine bestehende PKI zu behalten, während die Benutzer ihre Verzeichniskennwörter behielten. Ist Phase eins abgeschlossen, läuft XAuth als Anfrage und Antwort, die Benutzername und Kennwort als Attribute im nun verschlüsselten ISAKMP-Kanal transportiert.
Beachten Sie, wo das Vertrauen landet. Das Zertifikat beantwortet, welches Gateway der Client erreicht hat; XAuth beantwortet, welcher Benutzer Zugriff will. Keines ersetzt das andere, und ein Client, der jedes Serverzertifikat akzeptiert, hat die erste Antwort still verworfen. Das Etikett hybrid wird auch für Aggressive-Mode-Pre-Shared-Key plus XAuth verwendet, eine andere Anordnung mit derselben Benutzererfahrung, also lesen Sie das Profil statt den Namen. Beide Varianten stammen aus Entwürfen, die nie Standards wurden, weshalb zwei Hersteller den Hybridmodus implementieren können und mit keinem interoperieren.
Wie IKEv2 zu denselben zwei Nachweisen kommt
IKEv2 teilt die Arbeit auf IKE_SA_INIT und IKE_AUTH auf. Der erste Austausch vereinbart Vorschläge und Schlüssel ganz ohne Identitäten; der zweite trägt IDi, IDr und die AUTH-Nutzlasten. Unter EAP geht die erste AUTH-Nutzlast des Initiators leer hinaus, der Responder authentifiziert sich zuerst mit Zertifikat und Signatur, und danach läuft die EAP-Konversation in den IKE_AUTH-Nachrichten.
Der Mechanismus, der das sicher macht, ist Schlüsselmaterial. Eine erfolgreiche EAP-Methode exportiert einen Sitzungsschlüssel, und die abschließende AUTH-Nutzlast des Initiators wird daraus berechnet, sodass der Nachweis des Benutzers und die Schlüssel des Tunnels aneinander gebunden sind. XAuth hat kein Gegenstück: Seine Attribute kommen nach Phase eins und tragen nichts zu den Schlüsseln bei. Genau diese Lücke sollte der IKEv2-Rahmen schließen, und deshalb prüft eine funktionierende IKEv2-Anmeldung das Serverzertifikat, bevor sie irgendetwas abfragt.
Diese Reihenfolge ist auch eine nützliche Diagnose. Wenn ein Client sich über Anmeldedaten beschwert, bevor er Ihnen ein Zertifikat gezeigt hat, führt er überhaupt keinen IKEv2-EAP-Austausch durch.
Halten Sie drei Identitäten getrennt
Eine Migration geht schief, wenn drei Identitäten in einem Feld zusammenfallen. Da ist die Gateway-Identität, die der Client prüft, meist ein DNS-Name im Subjekt oder SAN des Zertifikats. Da ist die Benutzeridentität, die in EAP vorgelegt wird, sei es eine Domänenanmeldung, eine Adresse oder eine explizite EAP-Identitätszeichenkette. Und da ist die Autorisierungsquelle, die diesen Benutzer auf Netze und Routen abbildet.
Die swanctl-Syntax von strongSwan macht die Trennung sichtbar: Die Verbindung setzt remote { auth = pubkey } für das Gateway und local { auth = eap-mschapv2 } für den Benutzer, während die EAP-Identität getrennt übertragen wird.
Wenn die Benutzeridentität im neuen Profil von den alten XAuth-Attributen abweicht, etwa ein UPN statt eines Kurznamens, sieht der Authentifizierungsserver einen unbekannten Benutzer und der Fehler sieht nach einem falschen Kennwort aus. Prüfen Sie die Identitätszeichenkette, bevor Sie die Anmeldedaten prüfen.
Ordnen Sie die Optionen zu und rechnen Sie mit den Fallen
Die Zuordnung ist kurz, und jede Zeile hat eine Falle, die erst bei der Authentifizierung auftaucht.
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
Keine dieser Zeilen ist eine bloße Umbenennung. Die Konfigurationsnutzlast liefert Adressen und Resolver über eine typisierte Attributliste, während der Attributraum von XAuth eine eigene Erfindung war; sie als austauschbar zu behandeln, ist der Weg, auf dem ein Profil eine Einstellung verlangt, die das Gateway nie senden wird.
Traffic Selectors verdienen eine eigene Warnung. IKEv1 drückte interessanten Verkehr über Proxy-IDs aus, die an einen Quick-Mode-Austausch gebunden waren, während IKEv2 die Selektoren während IKE_AUTH aushandelt und der Responder sie einschränken darf. Eine Abweichung erzeugt eine etablierte IKE SA ohne Child SA, die manche Clients fröhlich als verbunden anzeigen.
Behandeln Sie die alte Verbindung als Grenze
RFC 9395 erklärt IKEv1 für veraltet, eine alte Hybridverbindung ist also eine Kompatibilitätsgrenze mit Datum, kein Fundament. Betreiben Sie beide Profile während der Umstellung parallel, denn der entscheidende Test ist nicht, ob das neue Profil hochkommt, sondern ob derselbe Benutzer auf demselben Gerät dieselben Ressourcen erreicht.
Halten Sie die Zertifikatsprüfung durchgehend streng. Sobald der Client sein eigenes Zertifikat nicht mehr vorlegt, ist die Versuchung groß, die Serverprüfung zu lockern, bis der Handshake durchläuft, und das tauscht den einzigen verbliebenen Nachweis gegen ein grünes Symbol.
Notieren Sie vier Dinge, bevor Sie das alte Profil stilllegen: die EAP-Methode, die Identitätszeichenkette, die Autorisierungsquelle und das Datum, an dem der Support endet.