L’avertissement d’OpenVPN sur plusieurs scripts --up : un seul s’exécute

L’avertissement sur plusieurs scripts ressemble à une plainte de planification, donc le correctif évident consiste à réordonner les lignes jusqu’à ce qu’il disparaisse. Ce n’est pas une plainte de planification. Une définition --up ultérieure remplace la commande déjà enregistrée pour cette étape, et l’analyseur le dit, ce qui signifie que sur vos deux scripts, exactement un s’est jamais exécuté. L’autre n’est pas en file derrière ; il a disparu.

C’est pourquoi l’avertissement mérite attention même s’il n’est pas fatal : ce qu’il prédit, c’est une mise à jour DNS ou un changement de route qui a discrètement cessé de se produire.

L’avertissement ne porte pas sur l’ordre

OpenVPN ne conserve qu’une seule commande de script utilisateur pour l’étape up. Quand l’analyseur rencontre une autre définition, venue du profil, d’un fichier inclus ou de la ligne de commande, il remplace ce qu’il détenait déjà et émet l’avertissement. Rien n’est concaténé, rien ne s’exécute deux fois et aucune question d’ordre n’existe. La commande qui survit est celle que l’analyseur a vue en dernier, c’est pourquoi déplacer une ligne peut changer le gagnant tout en laissant l’autre script mort.

Le même schéma vaut pour les autres étapes de script : une commande chacune. Si deux travaux doivent tous deux avoir lieu, il leur faut un point d’entrée unique, pas deux directives qui ressemblent à une liste.

Trouvez les deux définitions dans le lancement réel

Partez de ce que le démon a réellement reçu, et non du profil que vous avez modifié. ps -ef et la ExecStart de l’unité montrent la ligne de commande, qui peut ajouter --up depuis un point d’entrée de conteneur ou un wrapper ; un fichier init de distribution peut faire de même. systemctl cat openvpn-server@server révèle ce que le service apporte lui-même, et un grep récursif dans le répertoire de configuration trouve les définitions au niveau des fichiers. Les doublons viennent généralement de couches différentes, et c’est précisément pourquoi modifier un seul fichier ne change rien.

Copier un script dans un autre répertoire ou le renommer ne supprime pas non plus une directive. L’analyseur compte les définitions, pas les fichiers.

Qu’un seul hook prenne le travail en charge

La solution durable est un seul répartiteur qui exécute les deux actions dans un ordre réfléchi. Un court script shell avec set -eu qui appelle l’intégration requise puis l’action locale, en transmettant "$@" pour que les frontières des arguments survivent, garde le comportement en un seul endroit auditable. Transmettre les arguments ne fait que les préserver ; cela n’établit pas que les deux assistants attendent la même interface, alors lisez le contrat de chacun. Décidez ce qu’un échec doit faire et si des changements partiels doivent être annulés.

Si le lanceur offre un hook d’extension pris en charge, préférez-le à un chaînage fait main. Une image de conteneur ou un paquet fournisseur a souvent un emplacement documenté pour du travail supplémentaire, et l’utiliser empêche une mise à niveau d’écraser votre répartiteur.

Le nettoyage appartient à l’étape down correspondante. Une action up qui réécrit le DNS ou ajoute des routes a besoin d’une annulation documentée, et un répartiteur qui ne gère que le démarrage est un demi-design.

Confirmez l’intégration, pas seulement le silence

Supprimer l’avertissement de doublon est la partie facile ; l’intégration doit quand même fonctionner. Vérifiez l’état du résolveur après connexion avec resolvectl status ou en lisant /etc/resolv.conf, et confirmez les routes avec ip route. Puis déconnectez et reconnectez, car un hook chaîné à la hâte laisse souvent quelque chose de la session précédente. journalctl -u openvpn-server@server -b indique si votre répartiteur s’est exécuté et ce qu’il a affiché.

Gardez les privilèges du hook là où ils doivent être. Élever script-security ou exécuter le démon avec plus de droits n’est pas une solution pour un hook remplacé ; cela élargit ce que chaque futur script peut faire, y compris celui qu’un attaquant pourra nommer.

Le signe que le correctif est réel n’est pas le silence dans le journal. C’est la réponse DNS, l’entrée de route et le nettoyage qui fonctionnent tous après deux reconnexions.