OpenVPN startet nicht und zeigt keinen Fehler? Sehen Sie ins Journal

Der Befehl kehrt zurück, der Dienst erscheint als fehlgeschlagen, und nichts, was nach einer Erklärung aussieht, erreicht das Terminal. Dieses Schweigen ist das Symptom, das Menschen als „OpenVPN startet nicht“ beschreiben, und es bedeutet fast nie, dass das Programm gestorben ist, ohne etwas zu sagen. Es bedeutet, dass die Meldung in einen Kanal ging, den Sie nicht gelesen haben, oder dass das, was Sie gestartet haben, nicht das war, was Sie konfiguriert haben. Beide Fälle lassen sich in weniger als einer Minute diagnostizieren, sobald Sie aufhören, das Profil als Verdächtigen zu behandeln.

Vier Stellen absorbieren die Ausgabe: das Journal der Unit, das Plugin, dem die Verbindung gehört, das andere Ende des Tunnels und eine andere Binärdatei als die, von der Sie glauben, dass sie läuft. Jede hat ihre eigene Prüfung.

Schweigen bedeutet, dass Sie nicht den richtigen Kanal beobachtet haben

Ein Aufruf im Vordergrund schreibt in Ihr Terminal. Eine Unit schreibt ins Journal, und eine fehlgeschlagene Unit kann beenden, bevor sie überhaupt etwas schreibt, wenn der Fehler darin liegt, wie sie gestartet wurde, und nicht darin, was ihr gesagt wurde. Der Unterschied ist wichtig: Kein Journal-Eintrag bedeutet, dass der Prozess nie wirklich lief, während ein Eintrag, gefolgt von einem Beenden, bedeutet, dass er lief und etwas abgelehnt hat.

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

Fügen Sie systemctl show -p Result -p ExecMainStatus openvpn-client@office hinzu, um einen sauberen Abschluss von einem Signal zu unterscheiden. Ein Status von 1 mit einem Result=exit-code ist eine Entscheidung des Programms; Result=signal oder ein Timeout deuten stattdessen auf die Umgebung hin, und keine noch so große Profilbearbeitung ändert das. Notieren Sie beide Werte, bevor Sie irgendetwas neu starten, denn ein Neustart löscht den vorübergehenden Zustand, der sie erzeugt hat.

Der Instanzname ist Teil des Pfads

Die paketierte Template-Unit nimmt keinen Dateipfad. Sie nimmt einen Instanznamen, und dieser Name wird an ein Verzeichnis angehängt, um das Profil zu finden: office löst sich zu /etc/openvpn/client/office.conf in der Debian- und Ubuntu-Paketierung auf. Eine Datei namens office-v2.conf gestartet als @office wird nie gelesen, und die Unit beendet sich still, weil aus ihrer Sicht nichts zu tun war. Das Suchverzeichnis unterscheidet sich zwischen Client- und Servermodus, sodass derselbe Fehler ganz woandershin zeigt, wenn Sie das Template wechseln.

Diese Diskrepanz ist die häufigste Ursache des stillen Fehlschlags, und sie ist im Profil unsichtbar, weil das Profil in Ordnung ist. Listen Sie auf, was tatsächlich existiert, und vergleichen Sie die beiden Namen Zeichen für Zeichen, einschließlich jeder Erweiterung, die die Paketierung erwartet.

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

Wenn die Unit aktiviert ist, aber keine Instanz aufgeführt wird, kann die Aktivierung selbst auf einen Namen verweisen, der später umbenannt wurde. Die richtige Instanz erneut zu aktivieren reicht normalerweise, und die alte zurückgelassene Unit-Datei ist es wert, gelöscht zu werden, damit sie nicht die nächste Person verwirrt. Eine zurückgelassene Unit-Datei ist eine Kleinigkeit, die jemanden später eine Stunde kostet.

Wenn das Plugin den Tunnel besitzt, sieht das Terminal nichts

Eine vom Desktop-Applet gestartete Verbindung gehört NetworkManager, und ihre OpenVPN-Ausgabe geht ins Journal dieses Dienstes statt in eine Shell, die Sie offen haben. Den Client von Hand zu starten und nichts zu sehen, ist in dieser Anordnung zu erwarten, denn der von Hand gestartete Prozess ist nicht derjenige, der die Verbindung trägt.

Suchen Sie im Journal nach dem Dienst, dem er gehört, und reproduzieren Sie dann das Parsen mit einer Ausführlichkeit, die Sie lesen können. Die beiden Befehle unten betrachten verschiedene Eigentümer desselben Fehlers.

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

Der eigenständige Lauf dient zum Lesen von Meldungen, nicht zum Ersetzen der verwalteten Verbindung, und danach unterscheiden sich die beiden: DNS-Integration, Routen und Lebensdauer gehören dem Plugin. Einen Parse-Fehler im eigenständigen Lauf zu beheben, behebt nicht automatisch die Namensauflösung, sobald das Applet übernimmt, also halten Sie die beiden Beobachtungen getrennt.

Zwei Binärdateien, eine PATH

Ein manuell installiertes Programm unter /usr/local gewinnt bei einem Shell-Aufruf, weil /usr/local/sbin vor /usr/sbin auf dem Standard-Ubuntu-PATH steht. Eine Unit benutzt nicht Ihren PATH; sie führt den absoluten Pfad aus, der in ExecStart steht. Die Version, die in Ihrem Terminal funktioniert, und die Version, die als Dienst scheitert, können also wirklich verschiedene Programme sein.

Vergleichen Sie die beiden, bevor Sie irgendetwas neu bauen. Der dritte Befehl ist derjenige, der die Entscheidung trifft.

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

Ein weiterer Umgebungsunterschied versteckt sich am selben Ort. Eine paketierte Unit ist auf ein Laufzeitverzeichnis unter /run angewiesen, das systemd für sie anlegt; eine von Hand geschriebene Ersatz-Unit, die diese Einstellung auslässt, kann scheitern, bevor sie eine einzige Datei öffnet, und der Fehler sieht wie eine allgemeine Ablehnung ohne jede OpenVPN-Meldung aus.

Fehler, die der Client nicht melden kann

Manche Ergebnisse werden am fernen Ende entschieden. Ein Gateway, das mit einem HTTP-Status antwortet und die Verbindung schließt, hat Ihnen seinen eigenen Zustand mitgeteilt, und der nützliche nächste Schritt ist sein Log oder das Konto hinter den Anmeldedaten statt Ihrer lokalen Dateien. In diesem Szenario ist lokal nichts kaputt, und das Profil zur Kompensation zu bearbeiten macht die nächste Diagnose schwieriger. Lesen Sie dieses Log, bevor Sie die Client-Konfiguration anfassen.

Ein weiterer stiller Fall ist ein Client, der korrekt funktioniert. Ein Tunnel im Clientmodus lauscht nie auf einem Port, sodass eine Prüfung, die einen offenen Listener erwartet, nichts meldet und wie ein Fehler aussieht. Bestätigen Sie, welchen Modus Sie gestartet haben, bevor Sie aus einer leeren Portliste einen Schluss ziehen.

Arbeiten Sie die Schichten der Reihe nach ab: Existiert die Unit, und ist der Instanzname richtig, gelangte etwas ins Journal oder in die Datei --log, welche Binärdatei und welches Profil liefen tatsächlich, und ist der Fehler lokal oder entfernt. Jede Antwort entfernt eine Schicht. Beim Profil anzufangen bedeutet, eine Datei neu zu schreiben, die vielleicht nie geöffnet wurde.