L2TP/IPsec-PSK abgelehnt: erst der Dialog, dann die Dateien

Sie fügen den vorab geteilten Schlüssel aus der Nachricht des Administrators in den NetworkManager-Dialog ein, setzen das Häkchen zum Anzeigen, und er stimmt Zeichen für Zeichen überein. Die Verbindung endet trotzdem mit einem Authentifizierungsfehler, bevor der Tunnel steht. Als ich das zum ersten Mal sah, hielt ich den Schlüssel für falsch; er war es nicht. Zwei andere Dinge entscheiden, was der Daemon tatsächlich liest: die Secrets-Datei, die das Plugin für diese Verbindung schreibt, und ob der Wert den Dialog unverändert überstanden hat.

Der Weg unten folgt dem Schlüssel vom Feld bis in die Datei, und genau diese Reihenfolge sagt Ihnen, wo er verloren ging. Machen Sie das auf dem Rechner, der scheitert, nicht auf dem, der funktioniert, denn der Unterschied zwischen beiden ist meist die Dateilage und nicht der Schlüssel.

Beginnen Sie beim Dialog, aber trauen Sie dem Feld nicht

Öffnen Sie den IPsec-Reiter der Verbindung und tippen Sie den Schlüssel neu ein, statt ihn einzufügen. Ein Schlüssel, der aus einer Chatnachricht, einem PDF oder einem Passwortmanager kopiert wurde, kann mit einem abschließenden Zeilenumbruch ankommen, den das Feld nicht anzeigt, und die sichtbaren Zeichen sehen weiterhin richtig aus.

Klicken Sie auf die Anzeige des Passworts und schauen Sie auf das Ende der Zeichenkette, nicht in die Mitte. Bleibt der Cursor unter dem Text auf einer leeren Zeile, löschen Sie sie und tippen Sie das letzte Zeichen neu. Diese eine Korrektur behebt einen erstaunlichen Anteil solcher Meldungen und kostet weniger als das Lesen irgendeines Logs.

Kommt der Schlüssel aus einem Ticketsystem, das lange Zeilen umbricht, fordern Sie ihn über einen Kanal an, der nicht umbricht. Vergleichen Sie die Längen mit dem Administrator, statt zwei Zeichenketten nebeneinander zu mustern; ein verlorenes Zeichen an einer Umbruchstelle ist in einer proportionalen Schrift unsichtbar.

Folgen Sie dem Schlüssel nach /etc/ipsec.d

Das Plugin übergibt den PSK nie als Argument auf einer Kommandozeile an den IPsec-Daemon. Stattdessen speichert es den Wert in einer Secrets-Datei und sorgt dafür, dass der Daemon diese Datei einbindet, indem es eine include-Zeile in /etc/ipsec.secrets ergänzt, falls keine vorhanden ist. Was der Dialog hält, ist eine Eingabe für die erzeugte Datei, nicht der verwendete Wert.

Listen Sie auf, was vorhanden ist, bevor Sie etwas ändern:

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

Ältere Plugin-Versionen schrieben eine Datei pro Verbindung, benannt nach der UUID der Verbindung, zum Beispiel /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Das Löschen eines Profils im Applet löscht diese Datei nicht zuverlässig. Liegt eine alte Datei eines früheren Servers noch auf der Platte und wird sie noch eingebunden, kann der Daemon ein Geheimnis wählen, das zu einem Profil gehört, das Sie nicht mehr nutzen, und die Verbindung scheitert, obwohl das sichtbare Feld richtig ist.

Verstehen Sie, was die Änderung in 1.2.12 bei Upgrades bewirkte

Plugin-Version 1.2.12 ersetzte die Secrets-Dateien pro Verbindung durch eine einzige gemeinsame Datei, /etc/ipsec.d/ipsec.nm-l2tp.secrets. Ein Upgrade räumt die älteren Dateien pro UUID nicht auf, und eine bestehende Zeile include /etc/ipsec.d/*.secrets bindet sie weiterhin ein. Version 1.2.16 änderte die Behandlung der Standardvorschläge, nicht die Ablage der Geheimnisse.

Diese Geschichte erklärt, warum zwei Rechner mit scheinbar demselben Profil sich unterschiedlich verhalten. Der Schlüssel ist identisch; die Menge der Dateien, die der Daemon einbindet, ist es nicht. Wenn Sie eine verwaiste Datei entfernen, schieben Sie sie beiseite, statt sie zu löschen, bestätigen Sie die Verbindung und löschen Sie sie erst, wenn der funktionierende Zustand festgehalten ist. Umbenennen hält den alten Wert wiederherstellbar, falls der Fehler woanders liegt.

Trennen Sie die Zeichen, die das Speicherformat nicht fassen kann

Die strongSwan-Dokumentation zur Zeichenkette des geteilten Geheimnisses führt aus, dass der Wert weder einen Zeilenumbruch noch ein doppeltes Anführungszeichen enthalten darf. Ein aus einem Dokument eingefügter Schlüssel kann beides tragen, ohne dass sich in einem normalen Dialog optisch etwas zeigt.

Seit 1.2.12 ist der gespeicherte Wert kein reiner Text. Das Plugin kodiert den PSK base64, bevor er die Datei erreicht, und die Versionshinweise nennen diese Kodierung als Grund, warum ein doppeltes Anführungszeichen nun in einem Schlüssel zulässig ist. Ein im Feld getipptes Anführungszeichen ist damit darstellbar; dasselbe gilt nicht für jedes Steuerzeichen.

Die Länge ist eine andere Einschränkung. Über L2TP/IPsec-Software hinweg gilt kein allgemeiner Mindestwert: manche Clients akzeptieren Schlüssel unter zwanzig Zeichen, und manche Gateways erzwingen ein Minimum. Wird ein kurzer Schlüssel abgelehnt, gehört die Regel zur Serverrichtlinie oder zur Prüfung des jeweiligen Clients, und etwas lokal anzuheben ändert daran nichts.

Lesen Sie, welche Authentifizierungsschicht gescheitert ist

Führen Sie zuerst ipsec --version aus, denn strongSwan und Libreswan nutzen unterschiedliche Dateinamen und Syntax, und ein Rat für das eine kann das andere beschädigen. Lesen Sie dann die Fehlerstufe aus der Meldung des Clients oder dem Log des Daemons: eine Beschwerde über den vorab geteilten Schlüssel ist ein anderes Ereignis als ein abgelehnter Benutzername samt Passwort.

Der PSK authentifiziert die Endpunkte des Tunnels. Benutzername und Passwort authentifizieren die Person innerhalb von L2TP, und PPP kümmert sich darum, nachdem die IPsec-Assoziation steht. Ein korrekter PSK mit falschem Konto scheitert weiterhin, und ein Kontowechsel repariert keinen Schlüssel, den der Daemon nie richtig gelesen hat.

Wenn Sie das Ticket schließen, notieren Sie alle vier Punkte: Plugin-Version, die verwendete Secrets-Datei, ob der Schlüssel neu getippt oder eingefügt wurde und die im Fehler genannte Schicht. Wer diesen Weg später wiederholt, kann dann direkt zum Unterschied zwischen dem funktionierenden und dem scheiternden Rechner springen.