Was gehört in einen IPsec-Vorschlag? IKE- und ESP-Felder

IKE startet, beide Gegenstellen bieten AES an, und der Tunnel scheitert trotzdem mit NO_PROPOSAL_CHOSEN. Das Protokoll nennt den Vorschlag, aber nicht das Feld, das nicht passte. Ein Vorschlag ist ein vollständiges Angebot, und ein einziges inkompatibles Feld macht die gesamte Kombination ungültig statt nur diese Zeile. Ihn als Beutel unabhängiger Algorithmusentscheidungen zu lesen, ist der übliche Grund, warum die Abweichung unsichtbar bleibt.

Zwei Verhandlungen mit getrennten Vorschlagslisten

IKEv2 baut zwei Sicherheitsassoziationen auf. Die erste ist die IKE SA, die den Kontrollaustausch selbst schützt, und die zweite ist die CHILD SA, die Ihren Datenverkehr über ESP trägt. Jede hat ihre eigene Vorschlagsliste, und eine Gegenstelle kann die eine annehmen und die andere ablehnen.

Diese Trennung erklärt eine häufige Verwirrung: Eine funktionierende IKE SA beweist nur, dass die Algorithmen des Kontrollkanals passten. Scheitert der CHILD-Vorschlag, überträgt der Tunnel kein einziges Paket, obwohl Phase eins abgeschlossen ist und die Protokolle oben gesund aussehen.

Auch die Reihenfolge innerhalb jeder Liste zählt. Die antwortende Seite wählt aus den geordneten Angeboten des Initiators, sodass ein breit kompatibler Eintrag über einem engen die installierte Suite ändert, ohne einen einzigen Algorithmusnamen zu ändern. Legen Sie diese Reihenfolge in der Konfiguration fest, statt sich auf Vorgaben zu verlassen. Eine stabile Reihenfolge macht auch den Protokollvergleich zwischen Standorten aussagekräftig.

Welche Felder zu welchem Vorschlag gehören

Der Feldsatz ist klein, aber in den beiden Verhandlungen nicht identisch. Lesen Sie die Tabelle Zeile für Zeile, denn ein Feld in der einen Spalte kann in der anderen fehlen. Die Syntax unterscheidet sich je nach Implementierung; die Vorschlagsdokumentation von strongSwan ist eine konkrete Referenz.

Das Verschlüsselungsfeld nennt die Chiffre und in den meisten Syntaxen ihre Schlüssellänge. Das Integritätsfeld nennt den Hash, mit dem der Chiffretext authentifiziert wird, und die PRF nennt die Funktion, die Schlüsselmaterial für die IKE SA ableitet. Die DH-Gruppe erzeugt frisches gemeinsames geheimes Material, weshalb sie auf beiden Seiten auftaucht, aber zu unterschiedlichen Zwecken.

Erweiterte Sequenznummern gehören nur zum Datenpfad. Sie erweitern den Sequenzraum und werden als Teil des CHILD-Vorschlags verhandelt, sodass eine Abweichung dort ein CHILD-Angebot ablehnt, während die IKE SA unberührt bleibt.

Wie ein vollständiges Angebot ausgewählt wird

Jeder Vorschlag ist ein Set, und die antwortende Seite sucht ein Set, in dem jedes erforderliche Feld akzeptabel ist. Zwei Listen können beide AES und SHA-256 enthalten und trotzdem keinen kompatiblen Eintrag haben, weil sich Schlüssellänge, PRF oder DH-Gruppe unterscheiden. Der Vergleich erfolgt pro Vorschlag, nicht pro Algorithmus.

Wenn nichts passt, sendet die antwortende Seite NO_PROPOSAL_CHOSEN mit dem SA-Typ, der gescheitert ist. Lesen Sie, auf welche Vorschlagsliste sich die Meldung bezieht, bevor Sie die Konfiguration ändern; die ESP-Algorithmen zu ändern, wenn der IKE-Vorschlag abgelehnt wurde, verschwendet einen Debugging-Zyklus.

Das Auswahlverhalten lohnt sich zu kennen, wenn Sie ein Profil abstimmen. Manche Implementierungen bevorzugen die Reihenfolge des Initiators, andere sortieren nach lokaler Richtlinie um, also kann eine Suite, die zwischen zwei Herstellern funktioniert, verschwinden wenn Sie umkehren, welche Seite die Verbindung startet.

AEAD entfernt ein Feld, statt eines hinzuzufügen

AES-GCM und ChaCha20-Poly1305 authentifizieren und verschlüsseln in einem Vorgang. Wird eine der beiden für ESP gewählt, wird der Integritätsalgorithmus nicht separat verhandelt, weil die AEAD-Konstruktion ihn bereits abdeckt. Ein Vorschlag, der AES-GCM mit SHA-256 kombiniert, ist daher bestenfalls überflüssig und schlimmstenfalls abgelehnt.

Die PRF bleibt auf der IKE-Seite getrennt, da sie Schlüssel für den Kontrollkanal ableitet, statt Nutzlasten zu schützen. Deshalb kann ein IKE-Vorschlag legitim eine AEAD-Chiffre mit einer PRF und einer DH-Gruppe kombinieren, während der passende ESP-Vorschlag nur die AEAD-Chiffre und die optionale PFS-Gruppe nennt.

Die Schlüssellänge ist Teil des Verschlüsselungs-Tokens, also sind AES-128-GCM und AES-256-GCM unterschiedliche Angebote. Ein aus einer Anleitung kopiertes Profil, das 256-bit-Schlüssel annahm, passt nicht zu einem Endpunkt, der für 128-bit konfiguriert ist, obwohl beide Zeilen AES-GCM sagen. Zwei Gegenstellen können sich auf die Chiffrefamilie einigen und sich trotzdem wegen der Zahl hinter dem Bindestrich ablehnen.

Lesen Sie die installierte SA, nicht die Konfiguration

Die konfigurierte Vorschlagsliste ist ein Angebot; die installierte SA ist das Ergebnis. Auf strongSwan und einem Linux-Kernel stehen beide Ansichten zur Verfügung:

sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policy

swanctl --list-sas gibt die ausgehandelten Algorithmen pro SA aus, einschließlich der Frage, ob die CHILD AEAD verwendet. ip xfrm state zeigt, was der Kernel tatsächlich installiert hat, und dort bestätigen Sie, dass eine Schlüsselerneuerung nicht auf eine andere Suite zurückgefallen ist als die dokumentierte.

Speichern Sie diese Ausgabe nach einer Korrektur neben der Konfiguration. Wenn ein Client-Update seine Vorgaben ändert, gibt Ihnen die festgehaltene Suite eine Basislinie zum Vergleich, und der Vergleich zeigt auf das Feld, das sich verschoben hat, statt die Untersuchung von vorn zu beginnen.