PiVPN schreibt eine Serverkonfiguration und ein Clientprofil und beendet sich dann; es wird nie der Prozess, der deinen Datenverkehr trägt. Ein gescheiterter Handshake, ein Client, der den falschen Endpunkt anwählt, oder ein Dienst, der nach einem Neustart falsch zurückkommt, lassen sich also nicht aus den Menüs des Installers erklären. Diese Symptome gehören zu dem OpenVPN-Daemon, der gerade läuft, zu der Konfiguration, die dieser Daemon tatsächlich geladen hat, und zu dem Log, auf das er zeigt. Vier reine Lesebefehle klären das meistens, und keiner davon ändert deine Zertifikate oder Schlüssel.

Helfer und Daemon sind verschiedene Objekte

Die Verwirrung ist leicht zu erklären: Ein Verzeichnis enthält die Datei, die der Helfer erzeugt hat, die Datei, die der Daemon liest, und manchmal eine veraltete Kopie von beidem. Ein Helfer ist ein Provisioning-Skript. Er installiert Pakete, schreibt Unit-Dateien und gibt ein Clientprofil aus, dann endet seine Aufgabe. Was bleibt, ist ein Eintrag im Dienstmanager und eine Kommandozeile.

Beginne auf einem systemd-Host bei der aktiven Unit statt bei der Verzeichnisliste. Der Name hängt von der Paketierung ab: Debian- und Raspberry-Pi-OS-Images stellen üblicherweise eine Template-Instanz wie openvpn-server@server bereit, während ältere Installationen openvpn@server verwenden. Frag den Manager, welche läuft, statt es aus einem Dateinamen zu raten.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

Lies ExecStart= in dieser Ausgabe. Sie nennt die ausführbare Datei und die Optionen, die der Manager tatsächlich startet, einschließlich eines etwaigen --config-Pfads; eine Konfigurationsdatei daneben, auf die kein Befehl verweist, gehört nicht zum laufenden Tunnel.

Folge der Konfigurationskette, die der Daemon aufgelöst hat

OpenVPN durchsucht kein Verzeichnis nach Einstellungen. Es liest die mit --config übergebene Datei, folgt allen config-Direktiven darin und wendet dann die Kommandozeilenoptionen an. Das Handbuch zu 2.6 beschreibt diese Reihenfolge, und sie zählt, wenn zwei Dateien sich bei Port, Gerät oder Verschlüsselung widersprechen.

Gib zuerst den effektiven Aufruf aus und sieh dir dann die Direktiven an, die Identität und Erreichbarkeit bestimmen. Beide Befehle sind reine Lesevorgänge und auf einem laufenden Server sicher, allerdings druckt der zweite Pfade, die du vielleicht nicht in einem öffentlichen Ticket willst.

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

Eine .ovpn-Datei in einem Home-Verzeichnis ist ein Client-Artefakt. Der Server-Daemon liest sie nie, also bewirkt das Bearbeiten dieser Datei zur Behebung eines serverseitigen Handshake-Fehlers nichts.

Includes sind die andere Falle. Eine config-Zeile zieht eine zweite Datei herein, deren Optionen an dieser Stelle verarbeitet werden, sodass eine spätere Einzelwert-Direktive überschreiben kann, was die Hauptdatei scheinbar sagt. Wenn die sichtbare Datei korrekt aussieht und der Daemon sich trotzdem anders verhält, lies die eingebundene Datei, bevor du etwas änderst.

Ordne das Log dem Prozess zu, nicht dem Fehler, den du erinnerst

Zwei Log-Ziele sind üblich, und nur eines davon ist das Journal. Mit log-append schreibt der Daemon in diese Datei, und das Journal behält kaum mehr als Startzeilen. Ohne das ist journalctl die Ereignisquelle.

journalctl -u openvpn-server@server -n 80 --no-pager

Ordne einen Verbindungsversuch einem Zeitfenster zu. Notiere den Endpunkt des Clients und lies dann Serverereignisse aus denselben Sekunden. Ein TLS-Handshake, der nie zum Zertifikatstausch kommt, deutet auf Erreichbarkeit oder Protokollabweichung hin, während eine Authentifizierungsablehnung erst eintrifft, nachdem die Tunnelparameter bereits vereinbart sind.

Ein alter Log-Eintrag beweist nichts über ein Profil, das du vor fünf Minuten heruntergeladen hast. Erzeuge die Clientdatei neu, verbinde dich einmal und lies nur die Zeilen, die während dieses Versuchs erschienen sind.

Halte den ersten konkreten Fehler fest, nicht den letzten allgemeinen. Ein Bind-Fehler, ein unbeantworteter äußerer Austausch, eine Zertifikatsablehnung und eine Kontenablehnung schicken dich jeweils auf eine andere Ebene, und ein Timeout am Ende verbirgt oft das nützliche Ereignis darüber.

Den Tunnel neu zu bauen ist kein Diagnoseschritt

Die verlockende Abkürzung ist ein zweiter, einfacherer Tunnel: statischer Schlüssel, keine Zertifikate, keine zusätzliche Authentifizierung. Er wird oft verbinden, und er beweist nur, dass zwei Hosts UDP oder TCP dazwischen durchlassen können. Er sagt nichts darüber, warum die zertifikatsbasierte Bereitstellung scheitert, und er ersetzt still das Sicherheitsmodell, das du behalten solltest.

Dasselbe gilt für das Abschalten von tls-auth oder tls-crypt, das Aufweichen von verify-x509-name, oder das Weglassen eines zweiten Faktors für einen grünen Status. Ein Tunnel, der verbindet, weil die Prüfung entfernt wurde, ist ein anderes System, kein repariertes.

Mach eine einzige begrenzte Änderung auf der Ebene, die das Log genannt hat, starte dieselbe Unit neu und wiederhole den einzelnen Verbindungsversuch. Das hält den Vergleich ehrlich und hinterlässt eine Änderung, die du zurücknehmen kannst.

Was du der nächsten Person übergibst

Schreib vier Fakten auf, solange du sie noch hast: die OpenVPN-Version aus openvpn --version, die aktive Unit, die Konfigurationskette mit ihren Includes und das Log-Fenster, das einen Versuch abdeckt. Diese vier machen aus einer vagen Beschwerde einen reproduzierbaren Fall.

Schwärze, bevor du teilst. Private Schlüssel, auth-user-pass-Dateien, statisches Schlüsselmaterial und komplette Client-Bundles gehören nicht in ein Ticket; Optionsnamen und die Form der Kette reichen für ein zweites Paar Augen meist aus.

Wenn die Kette intakt ist und das Log weiter auf das Netzwerk zeigt, ist der nächste Schritt der Weg zwischen Client und Server statt einer weiteren Installation. Das ist der eine Teil der Geschichte, den der Helfer nie besessen hat.

Ähnliche Artikel