Un seul drop-in OpenVPN a modifié tous les tunnels : instance contre modèle

Une politique de redémarrage ajoutée pour un tunnel commence à s’appliquer à tous les tunnels de la machine. Ce n’est pas un bogue de systemd ; c’est la différence entre un drop-in d’instance et un drop-in de modèle. Le chemin sous lequel vous écrivez le fichier décide combien de services l’héritent.

Choisissez la portée avant le réglage. Les deux répertoires se ressemblent presque, et un seul d’entre eux est limité à l’instance que vous visiez.

Le symptôme : une modification, tous les tunnels

Un drop-in propre à une instance vit sous un répertoire nommé d’après l’instance complète, par exemple [email protected]. Un drop-in de modèle vit sous [email protected], avec l’arobase et aucun nom d’instance entre les deux. Le premier ne s’applique qu’à office. Le second s’applique à chaque service instancié à partir de ce modèle.

La forme modèle n’atteint pas un modèle [email protected] distinct, et elle n’atteint pas les services sans rapport qui ont openvpn dans leur nom.

Choisissez le répertoire qui correspond à la portée

Les deux répertoires se trouvent sous /etc/systemd/system/. Omettre le dernier composant system crée un chemin que systemd ne lit pas comme une substitution système, ce qui est une façon discrète de faire qu’un fichier d’apparence correcte ne fasse rien. Écrivez le chemin complet une fois et réutilisez-le.

Un drop-in a aussi besoin du bon en-tête de section. Les réglages de service vont sous [Service]. Un fichier avec des réglages mais sans section est ignoré ou rejeté, et l’unité continue de se comporter comme avant pendant que le fichier reste là, l’air autoritaire.

Gardez le but dans le nom du fichier si vous ajoutez plus d’un drop-in. L’ordre lexicographique décide de la fusion, et un nom qui dit ce que fait le fichier rend cet ordre lisible.

Lisez l’unité fusionnée avant d’écrire

Lisez l’unité fusionnée avant d’écrire quoi que ce soit. systemctl cat [email protected] affiche l’unité principale et chaque drop-in applicable, dans l’ordre de fusion. Comparez-la à une seconde instance quand vous envisagez un changement de modèle. Cette comparaison montre exactement quels services hériteraient de la modification.

Un fichier d’instance n’efface pas les réglages du modèle. Les deux sont fusionnés, donc une valeur du modèle que vous avez oubliée peut encore être en vigueur.

D’autres drop-ins nommés, des réglages d’exécution et la configuration fournie par les paquets participent aussi. Ne présumez pas que le fichier que vous avez modifié en dernier constitue toute l’unité. La sortie fusionnée est l’unité.

Gardez la politique de l’unité hors du profil

Gardez la politique de l’unité et la configuration VPN séparées. Une directive de profil ne devient pas une syntaxe systemd valide parce qu’elle se trouve sous [Service]. Un réglage de redémarrage n’a pas sa place dans un fichier .ovpn non plus.

Cette séparation est aussi pourquoi une politique de redémarrage n’est pas la même chose que la récupération de pairs que OpenVPN assure lui-même. Décidez du comportement voulu avant de choisir une portée.

Appliquez-le et vérifiez l’instance

Après le changement, rechargez les définitions du gestionnaire avec systemctl daemon-reload. Cette recharge ne redémarre pas le tunnel ; elle relit seulement les fichiers d’unité. Appliquez ensuite l’action de cycle de vie voulue à l’instance exacte.

Vérifiez en relisant l’unité chargée et en observant le comportement que vous avez modifié. Un redémarrage qui porte du travail actif mérite une interruption planifiée, pas un test rapide sur un tunnel de production. Notez le but et la portée de la substitution à côté du déploiement pour que la personne suivante sache si le fichier était destiné à être partagé.

Si la politique est vraiment partagée, déplacez-la délibérément vers le modèle et vérifiez une seconde instance avant de la déclarer terminée. La référence des unités systemd documente la priorité des drop-ins et l’ordre de fusion.