L2TP NO_PROPOSAL_CHOSEN: Welche Phase ist wirklich fehlgeschlagen?

NO_PROPOSAL_CHOSEN kommt, bevor irgendein PPP-Benutzername geprüft wird, was ein nützlicher Umstand und zugleich der Grund ist, warum die Meldung irreführt. Sie berichtet, dass eine Seite einen Vorschlag abgelehnt hat; sie berichtet nicht, welcher Parameter nicht passte, und sie sagt nichts darüber, ob die Ablehnung beim Aufbau der IKE-Assoziation oder erst später bei der Aushandlung des Verkehrsschutzes geschah. Hinter diesen beiden Möglichkeiten stehen zwei verschiedene Korrekturen, und nur eine davon betrifft das PFS-Kontrollkästchen, zu dem viele zuerst greifen.

Eine Meldung, zwei Vorschlagsgruppen

Die IKEv1-L2TP/IPsec-Anordnung hat zwei Aushandlungen nacheinander. Phase 1 baut die IKE-Sicherheitsassoziation aus einem Verschlüsselungsalgorithmus, einem Integritätsalgorithmus und einer Diffie-Hellman-Gruppe auf. Phase 2 handelt dann aus, wie der Verkehr geschützt wird, und die PFS-Anforderung gehört zu diesem zweiten Gespräch.

Weil die Phasen aufeinander folgen, sagt Ihnen die Fehlerstelle, welche Liste zu vergleichen ist. Darin liegt der gesamte diagnostische Wert der Meldung, und es lohnt sich, ihn zu entnehmen, bevor Sie eine Einstellung anfassen.

Warum ein PFS-Kontrollkästchen Phase 1 nicht reparieren kann

Das Abschalten von PFS ändert eine Eigenschaft von Phase 2. Haben sich die Gegenstellen nie auf Phase 1 geeinigt, findet das ESP-Gespräch gar nicht statt, also hat das Kontrollkästchen überhaupt keinen Einfluss auf die Ablehnung, und deshalb erzeugt sein Umschalten denselben Fehler mit einem anderen Zeitstempel.

Der umgekehrte Fehler ist genauso verbreitet. Eine erfolgreiche IKE-Assoziation beweist nicht, dass der ESP-Vorschlag annehmbar ist, und sie beweist erst recht nicht, dass die Gruppe in Phase 2 übereinstimmt. Behandeln Sie einen aufgebauten Management-Tunnel als Beleg allein für Phase 1. Viele lesen die grüne Zeile als „der Tunnel steht“ und verbringen dann eine Stunde mit der falschen Phase, weil ihnen niemand gesagt hat, dass die zweite Aushandlung noch nicht begonnen hatte.

Lesen Sie das Log, bevor Sie Algorithmen wählen

Sammeln Sie die Meldungen unmittelbar vor der Ablehnung aus dem Backend, das die Verbindung tatsächlich bedient, und ordnen Sie sie demselben Versuch zu. Ohne diese Zuordnung lesen Sie die Geschichte einer anderen Verbindung und ziehen daraus Schlüsse.

journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall          # strongSwan
ipsec whack --status     # Libreswan

Beantworten Sie aus diesen Zeilen zwei Fragen: Kam eine Assoziation in Phase 1 zustande, und welcher Austausch ist fehlgeschlagen. Diese beiden Antworten verengen die Suche auf eine Attributliste. Eine nackte Meldung ohne Kontext kann das nicht leisten, so verlockend es auch ist, einen Vorschlag aus einem Forenbeitrag auszuprobieren. Das Kopieren einer funktionierenden Zeichenfolge von einem Rechner mit anderem Backend ersetzt meist eine Ablehnung durch eine andere, etwas später.

Backend-Syntax reist nicht mit

Notieren Sie die Version von NetworkManager-l2tp und die Version des IPsec-Backends, bevor Sie irgendetwas vergleichen. Libreswan und strongSwan teilen weder die Vorschlagssyntax noch identische Algorithmensätze, sodass eine Zeichenfolge, die im einen funktioniert, im anderen ein Syntaxfehler ist. Das installierte Backend kann IKEv1 zudem per Richtlinie ablehnen, und dann wird kein Vorschlag jemals akzeptiert.

Die README des Projekts dokumentiert diese Backend-Unterschiede und hält die Felder für Phase 1 und Phase 2 getrennt. Lesen Sie sie als Dokumentation der Struktur, nicht als Einladung, jede historische Chiffre und eine schwache Gruppe zu aktivieren, denn eine Verbindung, die nur so zustande kommt, ist nicht die Verbindung, die Sie bauen sollten.

Einigen Sie sich auf die Suite und prüfen Sie dann die Stufen

Fragen Sie den Gateway-Betreiber, welche IKE- und ESP-Suiten unterstützt und freigegeben sind, und vergleichen Sie diese Antwort dann mit den effektiven Vorschlägen des Clients statt mit seiner Konfigurationsdatei. Geht der Unterschied speziell um PFS in Phase 2, einigen Sie sich auf eine unterstützte Gruppe oder auf eine ausdrücklich freigegebene Richtlinie ohne PFS. Leiten Sie die Richtlinie nicht aus dem Fehlernamen ab.

Wenn die einzige Überschneidung Kryptografie verlangt, die die Organisation nicht mehr akzeptiert, gehört die Entscheidung zum Gateway oder zu einer Protokollmigration. Die Client-Zeichenfolge so lange zu erweitern, bis irgendetwas aushandelt, ist ein Weg, eine bekannte Schwäche mit einem grünen Häkchen daneben auszuliefern.

Nachdem Sie die tatsächliche Abweichung korrigiert haben, bestätigen Sie den IPsec-Aufbau, bevor Sie L2TP und PPP untersuchen, und behandeln Sie jede spätere Authentifizierungsablehnung als zur nächsten Stufe gehörig. Prüfen Sie dann die Erneuerung im freigegebenen Testverfahren, denn der Aufbau der ersten Assoziation sagt nichts über den Rest ihrer Lebensdauer.