IKEv2 ist kein einziger Handshake: erst IKE SA, dann Authentifizierung, dann CHILD SA

Man könnte meinen, eine IKEv2-Verbindung sei ein einziger Austausch, an dessen Ende der Datenverkehr verschlüsselt ist. Es sind mindestens zwei, und der erste authentifiziert niemanden. Die Peers beginnen mit Kontrollnachrichten, einigen sich auf kryptografische Parameter, weisen ihre Identität nach und handeln erst danach den Zustand aus, der Anwendungspakete trägt. Diese Reihenfolge erklärt die Diskrepanz, die häufig gemeldet wird: Das Gateway antwortet, der Client meldet „verbunden“, und die private Anwendung läuft trotzdem in eine Zeitüberschreitung. Hier steht, was jede Phase tatsächlich leistet und was danach gelten muss.

Der Mythos: Wenn das Gateway antwortet, sind Sie verbunden

Eine Antwort auf die erste Nachricht beweist, dass der Endpunkt erreichbar ist und kommunizieren will. Sie beweist nicht, dass ein Konto akzeptiert, eine Zertifikatskette validiert oder eine Datenrichtlinie installiert wurde.

Diese Fehler treten später auf und erzeugen andere Symptome. Eine Zertifikatsablehnung oder ein EAP-Fehler kommt erst, nachdem der erste Austausch bereits erfolgreich war; deshalb sagen ein Ping auf UDP 500 und ein grünes Client-Symbol so wenig.

IKE_SA_INIT: Parameter abstimmen, nicht Identität

Der erste Austausch trägt Vorschläge für die IKE-Sicherheitsassoziation: Verschlüsselungs- und Integritätsalgorithmen, eine Pseudozufallsfunktion und eine Diffie-Hellman-Gruppe. Die Peers tauschen außerdem Nonces aus, und jede Seite leitet Schlüsselmaterial für die IKE SA aus dem gemeinsamen Geheimnis ab, das diese Werte erzeugen. Nichts in diesem Austausch legt fest, wer die andere Partei ist. Er belegt, dass beide Seiten dieselben Schlüssel berechnen können und sich auf einen Vorschlag einigen. Ein Responder, dem kein Vorschlag gefällt, lehnt den Austausch hier ab; deshalb sieht eine Versions- oder Algorithmusabweichung aus, als wäre der Server ausgefallen.

Die an dieser Stelle erzeugte IKE SA schützt alle späteren Verwaltungsaustausche. Das ist ihre Aufgabe, und sie unterscheidet sich von der Aufgabe, Ihre Pakete zu schützen.

IKE_AUTH: Identität nachweisen, dann die erste CHILD SA aufbauen

Der zweite Austausch trägt die Identität. Mit Zertifikaten signiert jeder Peer mit seinem privaten Schlüssel und legt eine Kette vor, die die Gegenseite validieren muss; bei EAP fordert der Responder den Initiator über die gewählte Methode heraus. Hier zeigt sich endlich ein falscher Servername, ein abgelaufenes Zertifikat oder ein abgelehntes Passwort.

Im Normalfall handelt IKE_AUTH auch die erste CHILD SA aus, sodass der Datenschutz im selben Roundtrip vereinbart wird. Der Initiator schlägt Traffic Selectors vor, der Responder verengt oder verwirft sie, und die Schlüssel für den Datenpfad werden von der IKE SA abgeleitet. Das bedeutet, dass ein einzelner Austausch an zwei sehr verschiedenen Stellen scheitern kann: an der Identität oder an der Richtlinie. Lesen Sie die Notify-Payload oder den Fehler statt der allgemeinen Handshake-Fehlermeldung, denn die eine Ursache behebt ein Zertifikat und die andere eine Subnetz-Abweichung.

Zwei SAs, zwei Aufgaben

Die Trennung erklärt zwei Verhaltensweisen, die wie Fehler aussehen. Ein Tunnel kann als aufgebaut angezeigt werden, während im Hintergrund ein Rekey scheitert, und eine CHILD SA kann ersetzt werden, ohne dass der Client die Verbindung verliert.

Bei strongSwan zeigen die IKEv2-Konfigurationsreferenz und swanctl --list-sas beide Ebenen, und ip xfrm state plus ip xfrm policy zeigen, was der Kernel tatsächlich installiert hat. Der Vergleich dieser beiden Ansichten ist der schnellste Weg zu erkennen, ob die Aushandlung abgeschlossen wurde oder nur abgeschlossen aussah. Wenn der Daemon eine CHILD SA auflistet, für die der Kernel keinen Zustand hat, ist die Installation stillschweigend fehlgeschlagen. Wenn der Kernel Zustand hält, von dem der Daemon nichts weiß, sehen Sie einen Rest eines früheren Versuchs.

Was nach dem Aufbau des Tunnels noch gelten muss

Traffic Selectors legen fest, welche Adressen abgedeckt sind. Wenn der Client ein Subnetz vorschlägt und der Server ein anderes erwartet, wird die CHILD SA installiert, trägt aber nichts Nützliches, und der Fehler erscheint als Routingproblem statt als Aushandlungsproblem. Dann muss der lokale Stack mitspielen: Weiterleitung aktiviert, wo der Host routet, Routen zum Tunnel, Firewallregeln, die die entkapselten Pakete zulassen, und ein interner Resolver, wenn private Namen im Spiel sind. Jeder dieser Punkte scheitert einzeln, und keiner wird durch einen Neustart des IKE-Daemons behoben.

Halten Sie das Protokoll sichtbar, während Sie diagnostizieren: zuerst der initiale Austausch, dann die Identitätsprüfung, dann die Benutzerauthentifizierung, wo sie greift, dann die CHILD-Installation, dann der Anwendungsverkehr. Die Phase, in der es stoppt, ist die Phase, die zu reparieren ist, und ein späterer Routingfehler ist nie ein Grund, die bereits bestandenen Identitätsprüfungen zu lockern.