Windows und strongSwan: die vier Transforms eines IKE-Vorschlags abgleichen

Beide Seiten unterstützen AES, beide akzeptieren SHA-256, und der Tunnel kommt trotzdem nicht hoch. Der Vorschlag scheiterte an einer Komponente, die niemand verglichen hatte, meist an der Schlüsselaustauschgruppe. Dieses Runbook liest den tatsächlichen Austausch, bevor irgendetwas geändert wird, wendet eine abgegrenzte Richtlinie an und hinterlässt einen Rückweg, der die vorherigen Parameter wiederherstellt.

Lesen Sie den Fehler, bevor Sie eine Gruppe ändern

Ein „Policy-Match-Fehler“ ist eine Zusammenfassung, keine Diagnose. Er bedeutet, dass kein beidseitig akzeptabler Vorschlag gefunden wurde, und sagt nichts darüber, welche Komponente abgelehnt wurde. Behandeln Sie ihn als Beginn der Untersuchung und nicht als Beleg für eine bestimmte Gruppe.

Die Antwort steht meist auf der Serverseite. Ein strongSwan-Log auf passender Stufe listet den vom Client empfangenen Vorschlag und den Vorschlag, den zu akzeptieren er konfiguriert ist, und die Differenz zwischen beiden Listen benennt die gescheiterte Komponente.

Nehmen Sie nicht an, der Client biete, was ein älterer Forumsbeitrag behauptet. Das aktive Profil und seine installierte Richtlinie bestimmen die angebotene Liste, und ein aktualisierter Windows-Build kann einen anderen Satz anbieten als den im Screenshot, von dem Sie abschreiben.

Schreiben Sie beide Listen auf. Vier Transform-Positionen und eine Gruppe sind eine kurze Liste, und sie Zeile für Zeile zu vergleichen dauert kürzer als jedes Experiment. Vier Positionen lassen sich leicht im Blick behalten. Eine Logdatei nicht.

Vergleichen Sie jeden Transform, nicht einen vertrauten Namen

Ein IKE-Vorschlag ist eine Menge von Entscheidungen, die alle passen müssen. Verschlüsselung schützt die Aushandlung, Integrität oder ein PRF authentifiziert sie, und eine Diffie-Hellman-Gruppe erzeugt frisches Schlüsselmaterial. Ein Vorschlag, der bei den ersten beiden passt und beim dritten abweicht, ist für beide Seiten weiterhin unannehmbar.

Die beiden Windows-Felder, die hier verwechselt werden, gehören zu verschiedenen Phasen. DHGroup gilt für den IKE-Schlüsselaustausch, während PfsGroup für die Kind-Assoziation gilt, die den Datenverkehr schützt. Das zweite zu ändern kann einen Fehler im ersten nicht reparieren.

Gruppennamen unterscheiden sich zwischen Implementierungen, und das ist eine eigene Quelle der Verwirrung. strongSwan schreibt modp2048 und ecp256, während Windows Aufzählungsnamen wie Group14 und ECP256 verwendet, also muss ein Vergleich erst übersetzen. Führen Sie eine zweispaltige Notiz mit beiden Namen. Die nächste Abweichung ist dann in Sekunden eingeordnet.

Wenden Sie eine vollständige, abgegrenzte Richtlinie an

Das unterstützte Werkzeug für ein natives IKEv2-Profil ist eine IPsec-Richtlinie pro Verbindung, gesetzt als ein Objekt statt Feld für Feld. Sehen Sie sie zuerst in der Vorschau an, wenden Sie sie dann an, und bewahren Sie die vorherigen Parameter im Änderungsnachweis auf.

Set-VpnConnectionIPsecConfiguration -ConnectionName "Northwind IKEv2" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup ECP256 -PfsGroup ECP256 -WhatIf

Der Schalter -WhatIf zeigt die lokale Änderung als Vorschau und wendet nichts an. Das ist nützlich und zugleich eine verbreitete Falle, denn eine Vorschau belegt nur, dass die Parameter für das lokale Cmdlet syntaktisch zulässig sind. Ob das Gateway den resultierenden Vorschlag annimmt, sagt sie nicht.

Gleichen Sie dabei auch den Geltungsbereich ab. Eine Verbindung im Alle-Benutzer-Speicher braucht den entsprechenden Alle-Benutzer-Parameter, und das Bearbeiten des Benutzerprofils mit demselben Anzeigenamen ändert ein anderes Objekt, das der Tunnel nicht nutzt.

Stellen Sie dann die strongSwan-Seite vor dem Test auf denselben Satz ein. Eine abgestimmte Änderung an beiden Enden ist die einzige Variante, die konvergiert; eine Seite zu ändern und wiederholt neu zu versuchen erzeugt ein Log voller gleicher Ablehnungen.

Prüfen Sie Austausch und Rekey getrennt

Eine erfolgreiche Verbindung ist eine Beobachtung, und der Rekey ist eine andere. Die anfängliche IKE-Aushandlung nutzt einen Parametersatz, und die Kind-Assoziation, die den Verkehr trägt, kann später mit eigener Richtlinie neu ausgehandelt werden. Ein Aufbau, der sich verbindet und nach einer Weile abfällt, ist meist der zweite Fall.

ipsec statusall | grep -A6 "Northwind"
Get-VpnConnection -Name "Northwind IKEv2" | Format-List *

Der erste Befehl zeigt die Sicht des Servers auf die aufgebauten Assoziationen, einschließlich der Kind-SA und ihrer Restlaufzeit. Der zweite zeigt, was das Clientprofil jetzt hält, und nur so lässt sich bestätigen, dass die gesetzte Richtlinie die wirksame ist.

Beobachten Sie einen vollständigen Rekey, bevor Sie Erfolg erklären. Das heißt, die Verbindung lange genug stehen zu lassen, damit die Kind-Assoziation ersetzt wird, und dann zu bestätigen, dass Verkehr weiterläuft. Die meisten Richtlinienabweichungen verstecken sich in diesem Schritt, weil die erste Aushandlung mit einem Satz gelingen kann, den der Rekey nicht akzeptiert.

Der Rückweg ist der vorherige Parametersatz, kein nachgiebiger Notfallwert. Hat der Client nur eine schwache Altgruppe angeboten, besteht die Antwort darin, die gemeinsame Richtlinie von Client und Server zu verbessern, nicht darin, diese Gruppe am Gateway zu ergänzen, wo jeder künftige Partner sich darauf herunterhandeln kann.

Notieren Sie die vier Parameter, die Gruppe, den Verbindungsbereich und das Rekey-Ergebnis. Das ist eine kurze Notiz, und sie ist der Unterschied zwischen einem Runbook und einer Geschichte darüber, wie der Tunnel damals hochkam.