OpenVPN gestartet, aber nichts ausgegeben: Prüfen Sie zuerst log-append

Sie starten OpenVPN aus einer Shell mit einer Konfigurationsdatei, und das Terminal bleibt ohne jede Ausgabe. Kein Banner, kein Fehler, keine Eingabeaufforderung. Der Instinkt sagt, der Start sei fehlgeschlagen, also starten Sie eine weitere Kopie, dann noch eine, und die Maschine endet mit mehreren halb konfigurierten Instanzen. Prüfen Sie vor all dem das Profil auf eine Direktive, die das Protokoll bereits woandershin umgeleitet hat. Stille ist eine Eigenschaft der Konsole, nicht des Prozesses.

Stille hat zwei sehr verschiedene Erklärungen

Die erste ist, dass der Prozess einwandfrei läuft und in eine Datei schreibt, die Sie nicht beobachten. Die zweite ist, dass er sofort mit einem in derselben Datei vermerkten Fehler beendet wurde.

Beide hinterlassen ein leeres Terminal, und eine Frage trennt sie: Gibt es jetzt einen Prozess, und was steht in der Datei, in die er schreiben sollte. Beantworten Sie das, bevor Sie die Konfiguration erneut anfassen. Ein Neustart, nur um Ausgabe zu bekommen, führt dazu, dass zwei Instanzen um ein Tunnelgerät und denselben Port streiten, was Fehler erzeugt, die nichts mit dem ursprünglichen Problem zu tun haben.

Finden Sie die Direktive, dann finden Sie den Prozess.

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

Finden Sie das Ziel, das der laufende Prozess verwendet

Lesen Sie das Profil, mit dem der Prozess tatsächlich gestartet wurde, nicht das, das Sie bearbeitet haben. Eine dienstverwaltete Instanz lädt normalerweise einen anderen Pfad und läuft mit einem anderen Arbeitsverzeichnis, sodass ein relativer Dateiname an einer Stelle aufgelöst wird, die Sie nicht erwartet haben.

Eine explizite cd-Direktive schärft diesen Unterschied, weil der relative Pfad mit dem Verzeichniswechsel wandert. Wenn Sie diese Konfiguration geerbt haben, liegt die Datei möglicherweise an einem Ort, an dem heute niemand danach suchen würde.

Vergleichen Sie die Änderungszeit der Datei mit dem Moment, in dem Sie gestartet haben. Ein Protokoll von letzter Woche ist ein Beweis über letzte Woche. Lesen Sie dann die letzten Zeilen der Datei, die sich geändert hat, und behandeln Sie das, was dort steht, als die Startmeldung, die Ihnen gefehlt hat.

log versus log-append: Beweis und Löschung

log-append hängt an, was bereits in der Datei steht. log öffnet die Datei zum Schreiben und kürzt sie, sodass ein Wechsel zwischen beiden den Lauf löschen kann, den Sie gerade lesen wollten.

Wenn jemand die Direktive während der Fehlersuche geändert hat, ist der frühere Beweis bereits fort, und die Dateigröße wird verdächtig klein aussehen. Das ist gut zu wissen, bevor Sie zwei Läufe vergleichen und schließen, dass sich etwas geändert hat. Löschen Sie ein Protokoll absichtlich oder behalten Sie es, aber wissen Sie, was Sie getan haben. Beweise, die Sie bewusst entfernt haben, sind leichter zu deuten als Beweise, die Sie versehentlich verloren haben.

Keine der beiden Optionen legt fehlende übergeordnete Verzeichnisse an, und keine gewährt Zugriff über Dateisystemberechtigungen oder eine Dienst-Sandbox. Ein in der Konfiguration korrekt aussehender Pfad kann für das Konto, unter dem der Daemon läuft, dennoch nicht beschreibbar sein, und dann kann der Daemon scheitern, bevor er etwas melden kann. Prüfen Sie, ob das Verzeichnis existiert und wem es gehört, bevor Sie annehmen, der Dateiname sei das Problem.

Wenn ein Dienst-Wrapper die Ausgabe abfängt

Unter systemd gehen Standardausgabe und -fehler ins Journal, sofern keine explizite Dateidirektive Vorrang hat, und ein Anbieter-Wrapper kann sie ganz woanders abfangen.

Deshalb verhält sich dasselbe Profil aus einer Shell anders als aus einer Unit. Die Umgebung der Unit, ihr Arbeitsverzeichnis und ihre Standardströme unterscheiden sich alle von Ihrer interaktiven Shell. Ein relativer Pfad kann in einem Kontext aufgelöst werden und im anderen nirgends landen. Lesen Sie die Unit-Definition, wenn beide nicht übereinstimmen, nicht das Profil.

Vergleichen Sie die beiden Startanordnungen, statt zu schließen, dass eine davon defekt ist. Lesen Sie die Kommandozeile der Unit und ihre Umgebung und dann das Journal für dasselbe Zeitfenster. Leitet der Wrapper die Ausgabe in seine eigene Datei um, ist diese Datei jetzt Ihr Protokoll, und die OpenVPN-Direktiven sind dafür irrelevant, wohin die Meldungen gingen.

Erhöhen Sie die Ausführlichkeit erst, wenn Sie sie lesen können

Die Ausführlichkeit zu erhöhen, bevor Sie das Ziel gefunden haben, erzeugt nur mehr Text an einem Ort, den Sie nicht betrachten.

Sobald Sie wissen, wo die Ausgabe landet, zeigt ein moderates Niveau, dass das Profil geparst und die Verbindung versucht wird. Zwei oder drei genügen für ein Startproblem. Höhere Stufen verdienen ihren Platz, wenn der Fehler ein Verhandlungsdetail ist, und lassen die Datei außerdem schnell wachsen.

Lesen Sie dann den tatsächlichen Fehler. Ein stilles Terminal beweist nichts darüber, ob der Tunnel hochkam, und der in der Datei vermerkte Fehler ist der, dessen Behebung sich lohnt.