IKEv2 NO_PROPOSAL_CHOSEN: Welche Stufe hat die Suite abgelehnt?

NO_PROPOSAL_CHOSEN in einem Protokoll schickt Leute zum vorab geteilten Schlüssel, und der Fehler überlebt die Änderung. Es war nie ein Problem der Anmeldedaten: Der Peer hat jeden für diesen Austausch angebotenen Vorschlag abgelehnt, was eine Aussage über Algorithmen und nicht über Identität ist. Die erste nützliche Frage ist nicht, welcher Algorithmus zu bearbeiten ist, sondern welcher Austausch abgelehnt wurde. Beantworten Sie das, bevor Sie irgendetwas vergleichen. Vergleichen Sie dann die vollständige angebotene Suite mit der vollständigen Suite, die der Peer erlaubt.

Zuerst: Welcher Austausch abgelehnt wurde

IKEv2 handelt zwei Arten von Assoziation aus. Die IKE SA schützt die Aushandlung selbst, und die CHILD SA schützt den Datenverkehr. Jede hat ihren eigenen Vorschlagssatz, und jede kann mit derselben Benachrichtigung scheitern. Eine Ablehnung während der anfänglichen IKE-Aushandlung und eine Ablehnung während der CHILD-Aushandlung erfordern unterschiedliche Korrekturen, und das Protokoll nennt den Austausch normalerweise ein oder zwei Zeilen über der Benachrichtigung. Lesen Sie diese beiden Zeilen zusammen, sonst bearbeiten Sie die falsche Vorschlagsliste.

Die Benachrichtigung allein identifiziert den Austausch nicht. Die Zeile darüber nennt die ausgehandelte SA, und dieser Name zeigt auf die zu prüfende Vorschlagsliste.

Vergleichen Sie vollständige Suiten, nicht einzelne Schlüsselwörter

Ein Vorschlag ist eine Kombination: Verschlüsselungsalgorithmus, Integrität oder AEAD, Schlüsselaustauschgruppe und eine beliebige Pseudozufallsfunktion. Nur den Verschlüsselungsnamen zu vergleichen ist der übliche Fehler, denn zwei Peers können sich auf AES-256 einigen und sich trotzdem bei SHA-1 gegenüber SHA-256 uneinig sein. Schreiben Sie die angebotene und die erlaubte Suite in der fehlgeschlagenen Stufe nebeneinander und suchen Sie dann die leere Schnittmenge.

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

Prüfen Sie außerdem, dass beide Implementierungen das unterstützen, was Sie konfiguriert haben. Ein von einer anderen Plattform kopierter Name kann syntaktisch vertraut aussehen während das Plugin oder die Implementierung völlig fehlt.

IKE-Suite und ESP-Suite sind verschiedene Objekte

Das Bearbeiten des IKE-Vorschlags repariert keinen abgelehnten CHILD-Vorschlag, und umgekehrt gilt dasselbe. In strongSwan sind dies getrennte Einstellungen, etwa proposals = aes256-sha256-modp2048 für die IKE SA und eine separate ESP-Liste für die CHILD SA. Ändern Sie die Liste, die zum fehlgeschlagenen Austausch passt, und lesen Sie dann das Protokoll erneut, statt anzunehmen, die Korrektur habe funktioniert.

Für die CHILD SA ist die relevante Einstellung die ESP-Vorschlagsliste, nicht die IKE-Liste. Das Kopieren der IKE-Zeile hinein erzeugt eine Konfiguration, die zwar parst, aber das falsche Objekt aushandelt.

Ein funktionierender Tunnel, der beim Rekey scheitert

Wenn der Tunnel eine Stunde lief und dann scheiterte, ist die anfängliche Aushandlung nicht das Problem. Ein Rekey kann andere Bedingungen beanspruchen: eine andere Schlüsselaustauschgruppe nach dem ersten Austausch, eine Lifetime-Abweichung zwischen den Peers oder eine geänderte Responder-Richtlinie. Behalten Sie den Erneuerungszeitstempel und die Assoziationskennungen beider Seiten. Dieses Muster erfordert einen Vorschlagsvergleich bei der Erneuerung, nicht ein längeres Timeout. Eine Timeout-Änderung verbirgt das Symptom und lässt die Abweichung bestehen.

ipsec statusall zeigt jede Assoziation und die tatsächlich ausgehandelten Algorithmen. Diese Ausgabe ist der schnellste Weg zu bestätigen, welche Liste verwendet wurde, und sie trennt einen Konfigurationsfehler von einem veralteten Tunnel, der nie neu ausgehandelt wurde.

ipsec statusall | grep -E "IKE:|ESP:"

Wählen Sie eine Schnittmenge und bestätigen Sie dann beide Phasen

Lassen Sie den Administrator eine dokumentierte moderne Schnittmenge wählen, die beide Peers unterstützen, und schreiben Sie sie auf. Lösen Sie den Fehler nicht, indem Sie jeden Altalgorithmus aktivieren oder die Identitätsprüfung deaktivieren, denn beides folgt nicht aus einer Ablehnung. Stellen Sie nach der Änderung eine neue Verbindung her und erzwingen Sie dann einen Rekey. Die erste Verbindung allein beweist nicht, dass der Erneuerungspfad funktioniert.

Behalten Sie die akzeptierte Kombination zusammen mit den Firmware-Versionen. Betrifft der nächste Fehler Traffic Selectors, behandeln Sie ihn getrennt, denn Einigkeit über Kryptografie sagt nichts darüber aus, welche Subnetze der Tunnel schützt. strongSwans Vorschlagsdokumentation deckt die Syntax für beide Listen ab.