OpenVPN meldet active (exited)? Finden Sie die Instanz, die Sie gestartet haben

Sie prüfen den Tunnel, führen systemctl status openvpn aus und erhalten active (exited) ohne Main PID und mit leerer Prozessliste. Die naheliegende Lesart ist, dass der Dienst gestartet und gestorben ist, also öffnen Sie die Unit, finden /bin/true und schließen, dass das Paket kaputt ist. In der Debian-Paketierung ist dieser Zustand der Wrapper, der wie vorgesehen arbeitet, und der Tunnel lebt in einer der Instanz-Units, die er startet. Die Sammel-Unit wird Ihnen nie sagen, welche Instanz sie aufgebaut hat.

Was active (exited) bei dieser Unit tatsächlich bedeutet

Die paketierte Unit ist ein Oneshot: Ihr ExecStart ist /bin/true, und RemainAfterExit=yes hält eine beendete Unit als active (exited) gemeldet. Nimmt man diese Direktive weg, endet derselbe erfolgreiche /bin/true-Oneshot in inactive (dead), also genau in dem Zustand, den Leute erwarten und in die andere Richtung falsch lesen. Der Befehl ist ein Platzhalter, und die Unit berichtet über Arbeit, die andere Units leisten. An dieser Anordnung ist nichts kaputt, und /bin/true zu ersetzen ändert den Paketierungsvertrag statt den Tunnel.

Der Wrapper delegiert. Er startet die Instanz-Units, die die Paketkonfiguration oder ihr systemd-Generator liefert, weshalb eine leere Prozessliste nichts über den Tunnel beweist. Wenn keine Instanz ausgewählt ist, gelingt der Wrapper trotzdem und startet trotzdem nichts. Der Zustand beantwortet, ob der Wrapper lief, nicht ob ein Tunnel existiert.

Lesen Sie die drei Zeilen der Statusausgabe statt des Worts in Klammern. Loaded nennt die Unit-Datei, die systemd gelesen hat, Active trägt den Zeitstempel des letzten erfolgreichen Laufs, und die fehlende Main PID passt zu einem beendeten Oneshot. Diese drei Zeilen sind auch der Weg, diesen Wrapper von einem Dienst zu unterscheiden, der eine Sekunde nach dem Start abstürzte.

Listen Sie die Units auf, bevor Sie den Status erneut lesen

Fragen Sie systemd, was existiert, bevor Sie fragen, was läuft. Eine Vorlage kann installiert sein, während keine Instanz erzeugt ist, und nur eine erzeugte Unit trägt einen Tunnel. Beginnen Sie mit dem geladenen Satz:

systemctl list-units 'openvpn*'

Diese Liste ist das, was systemd in diesem Moment geladen hat, und das ist das Nächste zu einem Tunnel-Inventar. Installierte Unit-Dateien beantworten eine andere Frage, und diese Liste zeigt weiterhin eine Vorlage, wenn nichts erzeugt ist:

systemctl list-unit-files 'openvpn*'

Lesen Sie beide Listen zusammen, denn eine Vorlage in der zweiten und eine Instanz in der ersten sind verschiedene Antworten. Eine Vorlage, die existiert, und eine Instanz, die läuft, sind nicht derselbe Fakt, und nur das Zweite bedeutet einen Tunnel. Paketlayouts unterscheiden sich auch zwischen Distributionen und OpenVPN-Versionen. Eine ältere openvpn@-Vorlage, ein getrenntes client- und server-Paar und ein Distributions-Wrapper können alle in ihrer eigenen Paketierung legitim sein.

Richten Sie sich nach Ihrer Maschine statt nach dem Tutorial, das Sie gefunden haben. Der Instanzname in der Ausgabe von jemand anderem kann office sein, während Ihrer home oder work ist. Übertragen wird die Methode, nicht die Zeichenkette.

Folgen Sie dem Instanznamen zu der Datei, die sie liest

In der Upstream-Client-Vorlage ist das Arbeitsverzeichnis der Unit /etc/openvpn/client, und ihr Befehl nimmt %i.conf von dort, also liest openvpn-client@office /etc/openvpn/client/office.conf. Bestätigen Sie diese Zuordnung an der installierten Unit, statt dem Beispiel zu vertrauen, denn die Vorlage, die Sie haben, kann älter sein oder eine Distributions-Neuschreibung:

systemctl cat [email protected]

Lesen Sie die Drop-ins am Ende dieser Ausgabe, denn eine Datei unter .d/ kann ExecStart, das Arbeitsverzeichnis oder den Konfigurationspfad ändern. Ein Profil, das Sie als office.ovpn heruntergeladen haben, ist nicht die Datei, die die Instanz öffnet. Diese Lücke ist der übliche Grund, warum ein Fehler einen Pfad nennt, den Sie nie bearbeitet haben.

Relative Pfade im Profil sind die nächste Falle. Die Hauptdatei zu verschieben, während ca-, cert- und key-Verweise relativ bleiben, tauscht einen Fehler über eine fehlende Datei gegen einen anderen Fehler über eine fehlende Datei. Der zweite zeigt auf eine Datei, von der Sie sicher waren, dass sie existiert, weshalb das Profilverzeichnis wichtiger ist als der Dateiname.

Starten Sie sie, und lesen Sie dann das Journal dieser Instanz

Starten Sie die Instanz, die Sie gerade geprüft haben, denn das Log der Sammel-Unit enthält die Fehler des Tunnels nicht. Lesen Sie dann das Journal für diesen Boot und suchen Sie in dieser Reihenfolge nach einem Konfigurationsfehler, einem Dateizugriffsfehler und einem Verbindungsfehler, denn jeder scheitert in einer anderen Phase des Starts.

sudo systemctl start [email protected]
journalctl -u [email protected] -b

Starten und Aktivieren sind getrennte Entscheidungen: start führt die Unit jetzt aus, enable richtet den nächsten Boot ein, und enable --now tut beides in einem Schritt. daemon-reload liest Unit-Definitionen neu und startet weder einen laufenden Prozess neu noch wendet es ein bearbeitetes Profil an. Nachdem Sie das Profil geändert haben, starten Sie die Instanz neu, denn das ist es, was die Datei neu liest.

Setzen Sie keinen zweiten Manager auf denselben Tunnel

NetworkManager und die OpenVPN 3-Session-Manager besitzen ihren eigenen Verbindungszustand, und eine systemd-Instanz daneben setzt zwei Eigentümer auf denselben Tunnel. Das Symptom ist ein Tunnel, der hochkommt und Sekunden später ersetzt wird, oder einer, der sich weigert, gestoppt zu bleiben. Wählen Sie den Manager, den Ihre Distribution für den Desktop dokumentiert, und nutzen Sie systemd auf einem Server bewusst.

Prüfen Sie vor dem Start einer Instanz, ob es bereits einen Eigentümer gibt. Wenn ein Desktop-Applet die Verbindung zeigt, konkurriert die von Ihnen gestartete Instanz damit, statt sie zu vervollständigen. Deaktivieren Sie den Manager, den Sie nicht nutzen, statt beide laufen zu lassen und zu hoffen, dass die Reihenfolge hält. Dieser Konflikt erklärt auch Journale, in denen ein Tunnel aufgebaut und dann von einem Prozess abgebaut wird, den Sie nie gestartet haben.

Beantworten Sie die ursprüngliche Frage mit dem Instanznamen, der Datei, die sie gelesen hat, und der Journal-Zeile, die fehlgeschlagen ist. OpenVPNs Hinweise zur systemd-Integration beschreiben das Vorlagenlayout und die Dateizuordnung, über die der Instanzname aufgelöst wird.