Ein einziger OpenVPN-Drop-in änderte jeden Tunnel: Instanz gegen Vorlage

Eine Neustartrichtlinie, die für einen Tunnel hinzugefügt wurde, gilt plötzlich für jeden Tunnel auf dem Rechner. Das ist kein systemd-Fehler; es ist der Unterschied zwischen einem Instanz-Drop-in und einem Vorlagen-Drop-in. Der Pfad, unter dem du die Datei ablegst, entscheidet, wie viele Dienste sie erben.

Wähle den Geltungsbereich vor der Einstellung. Die beiden Verzeichnisse sehen fast identisch aus, und nur eines davon ist auf die gemeinte Instanz beschränkt.

Das Symptom: eine Änderung, jeder Tunnel

Ein instanzspezifischer Drop-in liegt unter einem Verzeichnis, das nach der vollständigen Instanz benannt ist, etwa [email protected]. Ein Vorlagen-Drop-in liegt unter [email protected], mit dem At-Zeichen und ohne Instanznamen dazwischen. Das erste gilt nur für office. Das zweite gilt für jeden Dienst, der aus dieser Vorlage instanziiert wird.

Die Vorlagenform erreicht keine separate [email protected]-Vorlage und keine unabhängigen Dienste mit openvpn im Namen.

Wähle das Verzeichnis, das zum Geltungsbereich passt

Beide Verzeichnisse liegen unter /etc/systemd/system/. Lässt du die letzte system-Komponente weg, entsteht ein Pfad, den systemd nicht als System-Überschreibung liest, und das ist ein stiller Weg, eine korrekt aussehende Datei wirkungslos zu machen. Schreibe den vollständigen Pfad einmal und verwende ihn wieder.

Ein Drop-in braucht außerdem die richtige Abschnittsüberschrift. Diensteinstellungen gehören unter [Service]. Eine Datei mit Einstellungen, aber ohne Abschnitt, wird ignoriert oder abgelehnt, und die Unit verhält sich weiter wie zuvor, während die Datei dort liegt und maßgeblich aussieht.

Behalte den Zweck im Dateinamen, wenn du mehr als einen Drop-in hinzufügst. Die lexikografische Reihenfolge entscheidet über die Zusammenführung, und ein Name, der sagt, was die Datei tut, macht diese Reihenfolge lesbar.

Lies die zusammengeführte Unit, bevor du schreibst

Lies die zusammengeführte Unit, bevor du irgendetwas schreibst. systemctl cat [email protected] gibt die Haupt-Unit und jeden geltenden Drop-in in Zusammenführungsreihenfolge aus. Vergleiche sie mit einer zweiten Instanz, wenn du eine Vorlagenänderung erwägst. Dieser Vergleich zeigt genau, welche Dienste die Änderung erben würden.

Eine Instanzdatei löscht keine Vorlageneinstellungen. Beide werden zusammengeführt, daher kann ein Vorlagenwert, den du vergessen hast, weiterhin gelten.

Auch andere benannte Drop-ins, Laufzeiteinstellungen und paketseitige Konfiguration wirken mit. Geh nicht davon aus, dass die zuletzt bearbeitete Datei die ganze Unit ist. Die zusammengeführte Ausgabe ist die Unit.

Halte die Unit-Richtlinie aus dem Profil

Halte Unit-Richtlinie und VPN-Konfiguration getrennt. Eine Profilanweisung wird nicht dadurch gültige systemd-Syntax, dass sie unter [Service] steht. Eine Neustarteinstellung gehört auch nicht in eine .ovpn-Datei.

Diese Trennung ist auch der Grund, warum eine Neustartrichtlinie nicht dasselbe ist wie die Peer-Wiederherstellung, die OpenVPN selbst bietet. Entscheide, welches Verhalten du willst, bevor du einen Geltungsbereich wählst.

Wende es an und überprüfe die Instanz

Lade nach der Änderung die Definitionen des Managers mit systemctl daemon-reload neu. Dieses Neuladen startet den Tunnel nicht neu; es liest nur Unit-Dateien erneut. Wende dann die beabsichtigte Lebenszyklusaktion auf die genaue Instanz an.

Überprüfe, indem du die geladene Unit erneut liest und das geänderte Verhalten beobachtest. Ein Neustart, der aktive Arbeit trägt, verdient eine geplante Unterbrechung, keinen Schnelltest an einem Produktionstunnel. Notiere Zweck und Umfang der Überschreibung neben dem Deployment, damit die nächste Person weiß, ob die Datei zum Teilen gedacht war.

Wenn die Richtlinie wirklich geteilt werden soll, verschiebe sie bewusst in die Vorlage und prüfe eine zweite Instanz, bevor du sie als erledigt betrachtest. Die systemd-Unit-Referenz dokumentiert Drop-in-Vorrang und Zusammenführungsreihenfolge.