L2TP-Debug-Log leer? Der Fehler steckt vermutlich im Journal

Sie starten den L2TP-Helper mit Debugging, beobachten das Terminal, und er bricht ab, ohne dass etwas Brauchbares auf dem Bildschirm steht. Das ist kein defektes Debug-Flag. Eine NetworkManager-L2TP-Verbindung besteht aus vier zusammenarbeitenden Prozessen, und nur einige davon schreiben in das Terminal, das Sie beobachten. Der Rest der Beweise liegt im Journal, einen Filter entfernt.

Vier Prozesse, zwei Log-Ziele

Die Verbindung beginnt mit IPsec, je nach Installation entweder libreswan oder strongSwan. Dann betreibt der L2TP-Daemon, traditionell xl2tpd und in manchen Builds kl2tpd, den Tunnel. Schließlich übernimmt pppd darin die Authentifizierung und Adressierung.

Der Helper-Dienst koordiniert diese Teile und gibt seinen eigenen Fortschritt aus. Der IPsec-Daemon und pppd melden sich normalerweise über das System-Journal, weshalb das Terminal eine scheiternde Verbindung zeigt, während der Grund in einer Datei steht, die Sie nicht geöffnet haben.

Diese Trennung erklärt auch, warum ein PSK-Fehler und ein Passwortfehler vom Desktop aus gleich aussehen: Beide erzeugen eine allgemeine Trennung, und die fehlgeschlagene Stufe ist nur in der Ausgabe des jeweiligen Prozesses sichtbar. Genau deshalb ist das Journal hier wichtig. Eine allgemeine Meldung auf dem Desktop, vier mögliche Verursacher dahinter.

Sammeln Sie einen Versuch, dann lesen Sie die Reihenfolge

Reproduzieren Sie einmal, mit einem bekannten Profil und einer bekannten Uhrzeit, und lesen Sie dann ein enges Fenster statt des ganzen Boots. Wiederholte Versuche bei geänderten Einstellungen machen aus dem Log eine Mischung, die sich nicht deuten lässt.

Diese Befehle wählen die beteiligten Prozesse für den aktuellen Boot aus, und den Plugin-Pfad sollten Sie in Ihrer Distribution bestätigen:

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

Wiederholte Felder in einem Aufruf wählen die Vereinigung dieser Prozesse, was die Reihenfolge in zeitlicher Ordnung hält. Auf einem Debian-basierten System ist die entsprechende Abfrage dpkg -L; der Punkt ist, herauszufinden, wo der Helper tatsächlich liegt, bevor Sie ihn von Hand starten.

Drei Bedingungen entscheiden den nächsten Schritt

Lesen Sie die erste fehlgeschlagene Stufe und wählen Sie entsprechend. Wenn IPsec einen Vorschlags- oder Peer-Authentifizierungsfehler meldet, kam der Tunnel nie zustande, und ein anderes PPP-Passwort hilft nicht.

Wenn der Tunnel zustande kam und pppd die Anmeldung abgelehnt hat, war das gemeinsame Geheimnis bereits in Ordnung, und das Anmeldedatenproblem liegt eine Ebene höher. Wenn pppd eine Adresse ausgehandelt hat und der Fehler erst später auftritt, funktionieren beide, und das verbleibende Problem ist Routing, DNS oder die eigene Richtlinie des Servers.

Diese drei Zweige decken fast jede allgemeine Trennung ab, und sie werden davon entschieden, welcher Prozess den letzten Fehler protokolliert hat, nicht davon, welche Fehlermeldung am alarmierendsten aussieht.

Es lohnt sich auch zu bestätigen, welches IPsec-Backend installiert ist, bevor Sie eine Debug-Einstellung anfassen. Eine für strongSwan geschriebene Log-Option bewirkt nichts, wenn libreswan läuft, und die Verbindung scheitert weiter an derselben Stelle, während Sie eine Datei bearbeiten, die niemand liest.

Der Debug-Modus hinterlässt Dateien

Der ursprüngliche Debug-Workflow startet den Dienst manuell mit einem Debug-Flag, und dieser Modus kann beim Ende der Verbindung generierte Laufzeit-Konfigurationsdateien zurücklassen.

Diese Dateien enthalten Authentifizierungsmaterial: den vorab geteilten Schlüssel, Anmeldedaten oder beides. Eine generierte Konfiguration, die in ein Chatfenster kopiert wird, ist eine Offenlegung von Anmeldedaten, kein Log-Auszug. Entfernen Sie die geheimen Zeilen, bevor Sie etwas teilen, und löschen Sie das Verzeichnis, wenn die Untersuchung endet. Behandeln Sie sie wie Geheimnisse, extrahieren Sie die konkreten Zeilen, die Sie für einen Bericht brauchen, und löschen Sie sie anschließend, statt ein Verzeichnis in ein Ticket zu kleben.

Die manuelle Instanz muss auch mit der normalen abgestimmt werden. Eine Debug-Kopie zu starten, während der Dienst das Plugin bereits besitzt, erzeugt zwei Eigentümer und ein Log, das beide vermischt, was schlimmer ist als gar keine Debug-Ausgabe.

Stellen Sie danach den normalen Helper wieder her

Wenn die Untersuchung endet, stoppen Sie die manuelle Instanz, entfernen Sie die zurückbehaltenen Laufzeitdateien und verbinden Sie sich wieder über den normalen Weg, damit die nächste Person eine Konfiguration sieht, die der Realität entspricht.

Prüfen Sie das Ergebnis dann auf der Ebene, die fehlgeschlagen ist, nicht am Desktop-Symbol:

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

Eine Sitzung, die sich authentifiziert, eine Adresse erhält und zum vorgesehenen Ziel routet, ist das Ergebnis, das Sie debuggt haben. Ein stilles Terminal während eines fehlgeschlagenen Versuchs sagt Ihnen nur wo die Ausgabe nicht geschrieben wurde.