OpenVPN: lokales Binden scheitert beim Start — warten oder wiederholen

Für einen OpenVPN-Server, der beim Booten nicht startet, werden zwei Lösungen angeboten: auf die Adresse warten oder den Dienst so lange wiederholen lassen, bis das Binden gelingt. Beide behandeln dasselbe Symptom mit unterschiedlichem Fehlerverhalten. Warten kodiert eine konkrete Voraussetzung und scheitert laut, wenn sie fehlt; Wiederholen verbirgt die Voraussetzung und versucht es weiter. Welche in Ihre Unit gehört, hängt davon ab, ob diese Adresse eine entworfene Abhängigkeit oder ein Zufall des Timings ist.

Beide sind besser als ein festes Schlafen, das weder auf etwas wartet noch meldet, worauf es gewartet hat.

Was die Option local tatsächlich verlangt

local benennt die Adresse, an die der Daemon seinen Socket bindet, und das Binden an eine Adresse, die noch nicht existiert, scheitert sofort mit einem Fehler über die angeforderte Adresse. Fehlt die Option, lauscht der Daemon auf allen Adressen, weshalb dasselbe Profil auf einer Maschine funktioniert, deren Schnittstelle noch nicht oben ist: Er lauscht überall statt auf der einen Adresse, die Sie genannt haben. Dieser Unterschied ist der ganze Fehler, und er bleibt bis zu einem Neustart unsichtbar.

Die Anforderung ist nicht, dass die Schnittstelle in irgendeinem allgemeinen Sinn oben ist. Die Adresse muss im Moment des Bindens der richtigen Schnittstelle zugewiesen sein, und es muss die Underlay-Schnittstelle sein, nicht ein Tunnel, den derselbe Daemon später anlegen würde. Eine Prüfung Minuten nach dem Login beweist nichts über den Bootvorgang.

Auf die Adresse warten oder das Binden wiederholen

Warten bedeutet ein ExecStartPre, das abfragt, bis die Adresse erscheint, mit einer begrenzten Zahl von Versuchen und einem Exit ungleich null, wenn die Zeit abläuft. Wiederholen bedeutet, den Hauptprozess scheitern zu lassen und den Dienstmanager zu bitten, ihn erneut zu starten, zum Beispiel Restart=on-failure mit RestartSec=5. Ersteres meldet eine fehlende Voraussetzung als fehlgeschlagene Unit, Letzteres als eine Reihe von Neustarts, die irgendwann endet, was im Journal lauter ist, aber eine Adresse übersteht, die aus Gründen zu spät kommt, die Sie nicht vorhersagen können.

Bevorzugen Sie Warten, wenn die Adresse eine entworfene Abhängigkeit ist, und Wiederholen, wenn die Adresse normalerweise erscheint, ihr Timing aber schwankt. Beides zu kombinieren ist vernünftig: Ein begrenztes Warten deckt den Normalfall ab, eine Neustartrichtlinie den Ausreißer. Keines von beiden sollte ewig laufen, denn eine Unit, die endlos wiederholt, verbirgt eine Fehlkonfiguration, statt sie zu melden.

Warum network-online.target nicht ausreicht

network-online.target verspricht, was die aktive Netzwerkimplementierung unter online versteht, und nichts darüber hinaus. Mit systemd-networkd entscheidet systemd-networkd-wait-online, wann dieses Ziel erreicht ist, und seine Standardvorstellung von online kann erfüllt sein, bevor Ihre konkrete Adresse existiert. Unter NetworkManager wendet der wait-online-Dienst seine eigenen Regeln an. Das Einordnen nach dem Ziel ist eine solide Grundlage, keine Garantie, dass eine Adresse, eine DNS-Antwort oder ein entfernter Peer bereit ist.

Dieselbe Überlegung schließt die üblichen Alternativen aus. Ein Desktop-Autostart-Eintrag wartet auf eine Benutzersitzung, die auf einem Server vielleicht nie geöffnet wird, und ein verzögerter cron-Befehl fügt verstrichene Zeit hinzu, ohne die Ressource zu benennen, deren Erscheinen er erhoffte. Beide können monatelang erfolgreich aussehen und dann bei dem einen Start scheitern, der zählt.

Prüfen Sie die Bindung nach einem Kaltstart

Prüfen Sie mit einem echten Kaltstart statt mit einem Dienstneustart, denn ein Neustart erbt eine Adresse, die der Bootvorgang erst anlegen musste. Nach dem Start zeigt ss -lntp oder ss -lunp die lokale Adresse, an die jeder Listener tatsächlich gebunden hat, und journalctl -b -u openvpn-server@server zeigt, ob der erste Versuch fehlschlug. Vergleichen Sie die gebundene Adresse mit der im Profil und wiederholen Sie dann den Vergleich nach einem erneuten Netzwerkverbinden.

Wenn das Profil nie eine feste Adresse brauchte, ist das Entfernen von local eine legitime Vereinfachung, aber machen Sie daraus eine Sicherheitsentscheidung statt einer Fehlersuche-Gewohnheit.

Das Erweitern des Listeners ändert, wer ihn erreichen kann, also kombinieren Sie diese Änderung mit der Firewallrichtlinie, die ihn hätte einschränken sollen. Ein Dienst, der auf jeder Schnittstelle zuverlässig startet, hat das ursprüngliche Problem nicht gelöst; er hat es an den Netzwerkrand verlagert.