Le script up d’OpenVPN s’est-il exécuté trop tôt, ou n’a-t-il jamais été prêt ?

Le script up s’exécute, se termine avec zéro, et la tâche qu’il contient ne parvient pas à joindre un service privé qui, deux secondes plus tard, fonctionne parfaitement depuis un terminal. L’instinct est le minutage, et la réparation habituelle est une attente, qui masque la course sans la comprendre. La lecture plus utile est que « up » nomme un crochet, pas une garantie de disponibilité. Il se déclenche lorsque le périphérique tunnel est configuré, ce qui précède les routes, le DNS et, à coup sûr, toute application derrière le tunnel.

Le test dans le shell a réussi parce qu’il s’est exécuté après que tout s’est stabilisé. Le crochet s’est exécuté à un moment précis.

Où se situe up dans l’ordre de démarrage

OpenVPN configure le périphérique tunnel puis exécute le crochet up. L’installation des routes est une étape ultérieure et possède son propre crochet, ce qui explique pourquoi une tâche dépendante des routes placée dans up peut voir un périphérique sans chemin utile. Placez le travail des routes dans route-up et le problème de minutage disparaît généralement.

Le manuel documente cet ordre et l’environnement que reçoit chaque crochet. Cet ordre est toute l’explication du classique « ça marche depuis mon shell », et c’est aussi pourquoi le même script peut réussir sur une machine et échouer sur une autre avec une étape de routes plus lente. Aucun des deux résultats ne dit quoi que ce soit de la qualité du script.

La disponibilité du DNS et des applications vient encore plus tard. Même les routes installées ne prouvent pas que l’extrémité distante écoute, qu’un nom se résout ou qu’une session de bureau existe pour une tâche liée à un utilisateur.

Ce que le crochet hérite réellement

Un crochet s’exécute sous le compte et l’environnement du processus OpenVPN, ce qui n’est pas la même chose que votre shell interactif. Il peut lui manquer un bus de session utilisateur, un environnement de bureau ou un identifiant qui ne se déverrouille qu’à la connexion. Notez lesquels de ces éléments la tâche nécessite réellement.

Cela compte pour les tâches qui ressemblent à du réseau mais dépendent d’un contexte utilisateur : monter un partage avec un identifiant utilisateur, configurer un proxy par utilisateur ou configurer une imprimante. Un crochet tunnel privilégié est le mauvais endroit pour elles, et aucune quantité d’attente ne répare une session absente.

Lorsqu’une tâche échoue dans un crochet, notez le compte, l’environnement et la première opération qui a échoué. Cela sépare un minutage prématuré d’un problème de permissions ou de contexte, et les deux ont des réparations complètement différentes. Deviner entre les deux, c’est ainsi qu’une réparation de cinq minutes devient tout un après-midi.

Pourquoi ajouter une attente n’est pas un contrôle de disponibilité

Une attente retarde le script et décale la fenêtre de la course. Un jour rapide, la tâche réussit ; un jour lent, elle échoue de nouveau, et l’échec devient plus difficile à reproduire parce que le délai semble fonctionner. Un délai qui ne fonctionne que sous une charge légère est une coïncidence, pas une réparation.

Si la dépendance est une route, utilisez le crochet qui correspond à l’installation des routes. Si la dépendance est un service derrière le tunnel, utilisez un contrôle borné qui attend cette condition précise et échoue clairement lorsqu’elle n’arrive jamais.

Gardez l’échec explicite. Un crochet qui se termine avec zéro alors que son travail réel a échoué est pire qu’un crochet qui échoue, car le gestionnaire de services enregistre un succès et plus personne ne regarde. Une ligne de journal issue du script lui-même est le moyen le moins coûteux de rester honnête.

Le nettoyage et la reconnexion méritent le même soin

Un script qui modifie un état partagé a besoin d’un chemin d’annulation correspondant. Les routes, les entrées du résolveur et les marques de pare-feu ajoutées par un crochet doivent être idempotentes et réversibles, sinon une reconnexion empilera une seconde copie sur la première.

Les reconnexions peuvent aussi exécuter des crochets plus souvent qu’un démarrage complet du service. Une interface persistante qui rétablit une session peut déclencher à nouveau le cycle up et route-up, si bien qu’un script qui suppose une exécution par démarrage finira par mal se comporter. Comptez les exécutions dans le journal sur une journée d’oscillations pour voir à quelle fréquence il s’exécute réellement. Rendez ensuite le script sûr pour autant d’exécutions.

Testez le cycle de vie qui a échoué, pas une commande ultérieure. Reproduisez le démarrage ou la reconnexion, observez le crochet s’exécuter et confirmez que la tâche a réussi au moment où il s’exécute réellement. Un succès depuis un shell interactif ensuite est une preuve sur la dépendance, pas la preuve que le chemin de démarrage fonctionne.

Nommez l’événement dont chaque tâche dépend, puis rattachez-la à cet événement. Tout le reste est un délai qui prétend être un contrôle.