OpenVPN startet nicht: Lesen Sie die erste Zeile, nicht die Konfiguration

Ein VPN, das in der ersten Sekunde stirbt, ist ein anderes Tier als eines, das sich verbindet und dann scheitert, und der übliche Fehler ist, beide gleich zu behandeln. Hier gibt es keinen Handshake, keinen Zertifikatstausch und keine Route zu prüfen. Eine Zeile im Journal entscheidet, welche von mehreren unzusammenhängenden Reparaturen zutrifft, und sie zu überspringen kostet einen Nachmittag beim Bearbeiten einer Konfiguration, die nie gelesen wurde. Lesen Sie diese Zeile zuerst.

Drei schreibgeschützte Befehle bringen Sie dorthin: zuerst journalctl -u openvpn@server -b --no-pager, dann systemctl status openvpn@server und ss -lunp für die UDP-Listener und ihre Eigentümer.

Die erste Zeile wählt den Zweig

Ein Portkonflikt und eine fehlende Binärdatei beenden den Start beide innerhalb einer Sekunde, und sie hinterlassen unterschiedliche erste Zeilen. Eine Meldung, dass die Adresse bereits verwendet wird, nennt den Port; eine fehlende ausführbare Datei nennt einen Pfad, der nicht mehr existiert; eine fehlgeschlagene Bedingung oder eine fehlende Konfigurationsdatei nennt die Datei. Diese drei führen zu unterschiedlichen Reparaturen, und keine von ihnen wird durch eine Neuinstallation des Clients besser. Kopieren Sie den ersten Fehler in Ihre Notizen, bevor Sie irgendetwas anderes ausführen.

Achten Sie auf die Wiederholungsschleife, die die ursprüngliche Zeile verbirgt. Eine Unit mit einer Neustartrichtlinie kann den ersten Fehler unter einem Dutzend identischer begraben, daher schlägt journalctl -b, nach der Unit gefiltert und von oben gelesen, das Ende.

Wer sonst hält Port 1194

Der Übeltäter ist normalerweise kein zweiter Server, den jemand absichtlich eingerichtet hat. Erwarten Sie einen von Hand gestarteten Client, der noch in einem anderen Terminal lebt, ein zweites Profil, das zufällig denselben Port gewählt hat, oder ein Anbieterpaket, dessen eigener Tunnel 1194 hält. Der Eigentümer des Sockets erscheint in ss -lunp; geben Sie diese PID an systemctl status, um zu erfahren, ob eine Unit verantwortlich ist. Nehmen Sie ihn über seinen eigenen Kontrollweg herunter statt mit einem Signal.

Ein Signal an einen von einer Unit verwalteten Prozess löst normalerweise einen Neustart aus, und derselbe Fehler erscheint Momente später als neues Problem. Verwenden Sie systemctl stop für eine Unit, den eigenen Dienstbefehl des Pakets für eine Anbieterinstallation und ein Signal nur für etwas, das Sie selbst in dieser Shell gestartet haben.

Zurückgebliebene Units nach einer Deinstallation

Eine Deinstallation löscht Binärdateien; von Hand geschriebene Unit-Dateien, typischerweise unter /etc/systemd/system, überleben sie. Systemd versucht dann erneut eine Unit, die auf einen Pfad zeigt, der nicht mehr existiert, und die Meldung betrifft diese fehlende Datei statt die gestrige Entfernung. systemctl status zeigt den Fragmentpfad der Unit oben an, prüfen Sie ihn also mit dpkg -S, bevor Sie etwas löschen. Sobald die Waise weg ist, räumen systemctl daemon-reload und systemctl reset-failed den Zustand auf; sonst erbt ihn jede spätere Statusprüfung.

Wenn which openvpn mit etwas unter /usr/local antwortet, stammt die betreffende Binärdatei von einem Anbieter-Installer und nicht von apt. Ein solcher Installer bringt normalerweise seinen eigenen Listener, seinen eigenen Boot-Eintrag und sein eigenes Konfigurationsverzeichnis mit, sodass das Entfernen des sichtbaren Befehls den Socket belegt lässt.

Deinstallieren Sie ihn so, wie der Anbieter es dokumentiert, bestätigen Sie mit ss -lunp, dass der Port frei ist, und fügen Sie den Distributionsclient nur hinzu, wenn Sie ihn brauchen.

Bringen Sie den Zustand vor dem erneuten Versuch in Ordnung

Räumen Sie den fehlgeschlagenen Zustand auf, bevor Sie Schlüsse daraus ziehen: systemctl reset-failed entfernt die Zähler, und systemctl status meldet dann den aktuellen Zustand der Unit statt ihrer Geschichte. Starten Sie sie einmal und lesen Sie das Journal genau dieses Laufs statt den Gesamtzustand der Maschine. Eine Unit, die aktiv meldet, während der Tunnel nichts überträgt, ist ein separates Problem und ein viel häufigeres. Beide werden in Fehlerberichten zusammengeworfen, weil beide damit enden, dass der Nutzer sagt, das VPN funktioniere nicht.

Notieren Sie den Zweig, den Sie gewählt haben: Portkonflikt, fehlende Binärdatei, fehlende Konfiguration. Beim nächsten Mal geht das Erkennen schneller.