Windows und strongSwan: die richtige Schicht treffen

Beide Seiten sagen AES-128, und der Tunnel baut sich trotzdem nicht auf. CBC und GCM sind unterschiedliche Transformationen, die zufällig dieselbe Schlüssellänge teilen, und ein Client, der die eine anbietet, erfüllt kein Gateway, das nur die andere akzeptiert. Das Wort AES beschreibt eine Familie, keine Einigung.

Es gibt noch eine zweite Achse, und sie erzeugt die verwirrenden Fehler.

Zwei Schichten, zwei unabhängige Listen

IKE schützt die Aushandlung selbst, während die Child-SA den Verkehr schützt, der Sie wirklich interessiert. Windows stellt die erste als Verschlüsselungsmethode und Integritätsmethode bereit, die zweite als Chiffre- und Authentifizierungs-Transformationskonstanten. Diese Felder sind keine Aliasnamen füreinander, und ein in dem einen gültiger Wert kann in dem anderen bedeutungslos oder falsch sein. Liest man das Profil mit dieser Trennung im Kopf, verschwindet der größte Teil der Verwirrung.

Die praktische Folge ist, dass Sie eine völlig akzeptable Schlüsselaustauschrichtlinie und eine Datenkanalrichtlinie haben können, die die Gegenseite nicht akzeptiert. Die eine Liste verhandelt; die andere schützt Pakete. Eine Änderung an einem Wert in der ersten hat keine Wirkung auf die zweite, so ähnlich die beiden in einem Konfigurationsdialog auch aussehen.

Schreiben Sie beide Listen auf, bevor Sie sie mit dem Gateway vergleichen. Ein Vergleich aus dem Gedächtnis führt dazu, dass ein Feld zweimal bearbeitet wird und das andere nie. Halten Sie die Gateway-Konsole neben dem Profil geöffnet.

Lesen Sie den Fehler neben den Vorschlägen

Die fehlgeschlagene Phase sagt Ihnen, welche Liste Sie prüfen müssen. Eine Ablehnung während des anfänglichen Schlüsselaustauschs ist ein IKE-Vorschlagsproblem, und sie tritt auf, bevor irgendeine Child-SA existiert. Ein Fehler, während die Association für geschützten Verkehr ausgehandelt wird, ist ein ESP-Vorschlagsproblem, und der Schlüsselaustausch ist bereits gelungen. Eine allgemeine Richtlinienübereinstimmungsmeldung des Clients nennt keine der beiden Phasen, deshalb ist die Sicht des Gateways selbst die nützliche.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager

Vergleichen Sie den empfangenen Vorschlag, den konfigurierten Vorschlag und den ausgewählten für diesen einen Versuch. Drei verschiedene Listen sind hier wichtig, und nur die letzte beschreibt, was tatsächlich verwendet wurde. Zitieren Sie sie im Ticket wörtlich, statt sie zusammenzufassen.

Halten Sie CBC und GCM als getrennte Alternativen

Ein Gateway, dem bewusst erlaubt ist, beide Familien zu akzeptieren, braucht zwei Vorschläge, nicht einen. In strongSwan trennt ein Komma Alternativen, und ein Bindestrich verbindet die Komponenten eines einzelnen Sets. Beide Familien mit Bindestrichen zu kombinieren ergibt einen unmöglichen Vorschlag statt zwei akzeptabler.

proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256

Die erste Alternative trägt authentifizierte Verschlüsselung und nennt weiterhin eine Pseudozufallsfunktion, weil die Schlüsselableitung eine braucht, auch wenn die Integrität aus der Chiffre kommt. Die zweite Alternative ist klassische Verschlüsselung mit einem separaten Integritätsalgorithmus. Beide bleiben davon abhängig, was die geladene Krypto-Implementierung unterstützt.

Ein ESP-Vorschlag ist kein umbenannter IKE-Vorschlag

Das Chiffre-Token sieht in beiden Listen identisch aus, und fast nichts anderes wird übernommen. Ein ESP-Vorschlag hat keine Pseudozufallsfunktion für den Schlüsselaustausch, und seine Integritäts- und Forward-Secrecy-Anforderungen werden gegen die Windows-Richtlinie auf der anderen Seite begründet, statt aus der IKE-Zeile kopiert zu werden. Eine Liste mechanisch in die andere zu übersetzen erzeugt etwas, das validiert und nie verhandelt.

Wählen Sie eine Richtung und bleiben Sie dabei. Entweder behält das Gateway eine reine GCM-Richtlinie, und der Client setzt eine vollständig kompatible Richtlinie ein, oder das Gateway akzeptiert beide Familien, und der Client behält sein bestehendes Set. Einen Fallback zu aktivieren, den die Sicherheitsrichtlinie verbietet, ist keine Lösung, so schnell er den Fehler auch beseitigt.

Prüfen Sie beide Sets, dann eine Schlüsselerneuerung

Bestätigen Sie das ausgewählte Schlüsselaustausch-Set und das ausgewählte Verkehrs-Set getrennt, denn sie stammen aus verschiedenen Listen und können unabhängig erfolgreich sein. Lassen Sie dann eine Schlüsselerneuerung stattfinden und bestätigen Sie auch diese. Ein erster funktionierender Handshake und eine fehlschlagende Schlüsselerneuerung beschreiben ein Vorschlagsset, das nur teilweise akzeptabel ist.

Bewahren Sie diesen Nachweis zusammen mit der Änderung auf. Eine wiederkehrende Trennung braucht ihren eigenen Nachweis einer fehlgeschlagenen Aushandlung, bevor jemand einen Timer oder einen Plattformfehler beschuldigt.