Une tâche planifiée qui s'est exécutée sans le VPN semble correcte

Le statut de la tâche dit succès, le journal montre une exécution terminée, et les données sont obsolètes ou absentes. Cette combinaison signifie généralement que la tâche planifiée a démarré sans le chemin dont elle avait besoin, et que quelque chose en aval a avalé l'échec. Une planification qui se déclenche à l'heure ne dit rien sur la disponibilité du réseau. L'écart entre ces deux faits est l'endroit où vit cet échec.

L'admission appartient à l'exécution, pas à l'existence d'un fichier cron.

Une exécution verte n'est pas une tâche terminée

Un planificateur note qu'un processus a démarré puis s'est terminé ; il n'a aucune idée si ce processus a atteint la ressource pour laquelle il existe. Un script qui traite une connexion échouée comme un résultat vide, ou qui attrape une erreur et sort avec zéro, semblera sain pour toujours. Le symptôme n'est pas un statut rouge ; c'est un statut plausible attaché à un travail absent.

Nommez ce dont l'exécution a réellement besoin avant de décider comment la vérifier. Une sauvegarde peut avoir besoin d'un DNS privé et d'un point de terminaison authentifié, pas seulement d'un processus de tunnel.

Vérifiez la connexion, pas le nom de l'interface

Une interface nommée tun0 peut exister sans la session qui compte, et une autre connexion peut posséder ce nom. Vérifiez l'objet précis dont dépend la tâche : une identité de profil, une instance de service ou une petite opération approuvée contre la ressource. Gardez la vérification bornée dans le temps et gardez les identifiants hors des arguments de processus et des journaux de diagnostic.

Définissez aussi le résultat déconnecté. Un saut ordinaire, une nouvelle tentative dans une fenêtre courte et une échéance manquée visible par l'opérateur sont trois réponses différentes, et une planification récurrente ne choisit pas entre elles.

Les sauts et les échecs sont des résultats différents

[Service]
Type=oneshot
User=worker
ExecCondition=/usr/local/libexec/check-office-path
ExecStart=/usr/local/bin/private-task

Dans un déploiement systemd, ExecCondition= exécute ce vérificateur avant la charge de travail. Son comportement de sortie est spécifique : zéro continue, les codes de un à 254 sautent les commandes de démarrage restantes sans marquer l'unité comme échouée, et 255 ou une terminaison anormale la fait échouer. Cela donne trois signaux distincts, utiles seulement si le contrat du vérificateur y est délibérément associé. Les réglages qui redéfinissent le succès peuvent changer la donne, alors documentez l'association.

C'est la consignation des sauts qui rend la conception honnête. Une exécution sautée qui n'apparaît nulle part est indiscernable d'une exécution qui a réussi, et traiter chaque erreur du vérificateur comme un saut silencieux masque indéfiniment un déploiement cassé.

Protégez toute l'exécution, pas seulement le démarrage

Une vérification de disponibilité observe le monde avant le lancement ; elle ne surveille pas chaque socket ensuite. Quand un chemin direct n'est jamais acceptable pour cette tâche, attachez une politique de sortie approuvée appliquée en continu et couvrant DNS, IPv6 et le transport propre du tunnel. Basculer l'état IPv6 global de l'hôte ne remplace pas une politique limitée à la tâche.

Décidez si un nouvel événement peut chevaucher une tâche encore en cours, gardez cette règle chez le propriétaire de la charge de travail, et rendez la nouvelle tentative sûre pour l'opération de données. Arrêter une tâche à la déconnexion limite le travail sans rien garantir sur le trafic de repli.

Acceptez le flux de travail sur trois cas : chemin prêt, chemin indisponible et perte en cours d'exécution. Moins que cela teste la planification, pas la tâche.