Ignorer le VPN domestique avec un systemd ExecCondition

Le VPN de votre réseau domestique n'a rien à faire lorsque l'ordinateur portable est déjà sur ce réseau. Le raccourci tentant est une commande de préparation qui se termine par un code non nul ; cela fait échouer l'unité et donne à chaque tableau de bord l'air cassé. systemd dispose d'une directive pour exactement cette forme de décision, et elle sépare une omission délibérée d'une véritable panne. Bien faire les choses consiste surtout à écrire ce que signifie chaque code de sortie.

Pourquoi une précondition qui échoue est la mauvaise forme

ExecStartPre traite une sortie non nulle comme un échec de démarrage, ce qui est correct pour une commande qui prépare le service. L'utiliser comme condition rend une décision de politique indiscernable d'une dépendance cassée. ExecCondition existe pour qu'une unité puisse refuser de démarrer sans être marquée comme en échec.

Cette distinction compte à trois heures du matin, quand personne ne veut trier une unité rouge qui se comportait comme prévu. Une unité en échec masque aussi les vraies pannes parmi celles qui sont intentionnelles.

Écrivez d'abord le contrat des codes de sortie

Écrivez le contrat avant le script. Une sortie zéro signifie continuer, une sortie un signifie ignorer les commandes de démarrage restantes, et une sortie 255 signifie que la condition elle-même n'a pas pu s'exécuter. Les codes entre deux et 254 signifient normalement aussi ignorer, ce qu'on oublie facilement quand un assistant renvoie un code d'erreur aléatoire. Le fichier drop-in ci-dessous attache l'assistant au nom réel de l'unité.

[Service]
ExecCondition=/usr/local/libexec/should-start-home-vpn

Vérifiez l'unité effective pour des SuccessExitStatus ou des réglages stop-post hérités avant de supposer la sémantique par défaut. Testez ensuite délibérément chacun des trois résultats.

Un indice réseau ne prouve pas la localisation

Une adresse de routeur joignable ou une MAC connue peut suggérer le bon réseau, et ni l'une ni l'autre ne le prouve. Un autre réseau peut réutiliser la même adresse, les données ARP peuvent être périmées et les identifiants peuvent être imités. Traitez la sonde comme une optimisation cohérente avec la politique, pas comme un résultat d'authentification.

Décidez à l'avance ce que signifie l'incertitude. Démarrer le VPN en cas de doute est sûr pour un client qui échouerait simplement à se connecter ; l'ignorer en cas de doute ne l'est pas. Rendez la sonde bornée et lisez l'interface active plutôt que de supposer la première de la liste. Une sonde qui se bloque est pire qu'une qui répond non, parce que l'unité l'attend.

Consignez ces hypothèses à côté du fichier d'unité pour que la personne suivante sache ce que croit l'assistant. Un commentaire en tête du script est l'endroit le moins coûteux pour les conserver.

Gérer le déplacement entre réseaux

La condition s'exécute au démarrage du service et n'est pas réévaluée ensuite. Une unité ignorée reste ignorée après que l'ordinateur portable est passé dans un café, et un tunnel actif reste monté après que l'ordinateur est rentré à la maison. Reliez le cycle de vie du changement de réseau à la décision de démarrage et d'arrêt par un mécanisme séparé.

systemctl cat home-vpn.service

Testez quatre cas : démarrage à la maison, démarrage à l'extérieur, une sonde qui ne peut pas s'exécuter, et un déplacement entre réseaux pendant que l'unité est active. Gardez la raison de l'omission visible dans le journal pour qu'une décision intentionnelle ne ressemble jamais à un échec d'authentification. La référence du service documente la sémantique de sortie et la version minimale.