L’application ne doit pas tourner quand le VPN est actif : ce qui l’impose

Les kill switches et les règles de non-chevauchement pointent dans des directions opposées, ce qui explique pourquoi les réglages VPN ordinaires n’expriment jamais la seconde. Le kill switch réagit à un tunnel tombé, tandis que cette exigence réagit à un tunnel actif et maintient une application hors de l’image. Une décision de conception règle l’essentiel : l’application est-elle arrêtée, empêchée de démarrer ou simplement privée d’accès réseau. Choisissez cette couche avant de saisir une règle de pare-feu ou une boucle qui tue des processus, car une règle appliquée par observation fuit une fenêtre à chaque lancement.

Le mythe : un kill switch empêche les programmes de démarrer

Les kill switches sont des contrôles de trafic, et ils l’assument : ils autorisent ou refusent les paquets selon l’état du tunnel. Aucun d’eux ne refuse de démarrer un programme, et aucun n’inspecte quel exécutable a ouvert une socket. Un raccourci de bureau, une tâche planifiée et un assistant en arrière-plan atteignent tous le réseau sans passer par quoi que ce soit qui connaisse le nom de l’application. La distance entre ces deux mécanismes est l’endroit où vit la majeure partie de la confusion.

La disposition qui décide réellement si un programme peut démarrer est le contrôle des applications. Sous Windows, cela signifie AppLocker ou WDAC, et sur macOS géré, une liste d’autorisation imposée par le profil de l’appareil. Les deux sont indépendants du tunnel, et c’est pourquoi les deux exigences fusionnent dans le même ticket puis ne sont satisfaites par aucune.

Nommez le mode avant de nommer l’outil

Écrivez la règle comme une machine à états à trois états : usage ordinaire, session de travail VPN et sortie. Le chevauchement interdit appartient à l’état intermédiaire, pas au logiciel client.

Celui qui change l’état possède trois actions dans l’ordre : terminer le travail de l’application, demander son arrêt normal et confirmer que l’instance a disparu avant que le tunnel monte. L’ordre compte aussi à l’autre bout, car un VPN qui se connecte d’abord et arrête le programme ensuite a déjà autorisé le chevauchement. Si l’exigence couvre l’établissement de la connexion, attendre un indicateur de connexion arrive trop tard.

Ce que fait vraiment un conflit bidirectionnel

Pour deux services réellement gérés par systemd, Conflicts= est symétrique : démarrer l’un arrête l’autre. La référence des unités documente ce comportement et exige séparément un ordre explicite lorsqu’un doit finir de s’arrêter avant que l’autre démarre. Sans ces entrées d’ordre, l’arrêt et le démarrage font la course, et le résultat dépend du moment.

Ce n’est pas une liste de refus. Câblez la dépendance à l’envers et le démarrage de l’application arrêtera le VPN à la place, ce qui est la panne à soupçonner quand un tunnel se déconnecte tout seul à un moment prévisible. Une application de bureau n’est pas une unité systemd, et une connexion NetworkManager n’en est pas une non plus, donc ce schéma ne fonctionne que pour les services que vous encapsulez vous-même.

Vérifiez les transitions, pas seulement le premier lancement

Quatre transitions décident si l’exigence tient : entrer dans la session avec l’application en marche, la relancer en pleine session, un démarrage VPN raté et une déconnexion délibérée. Testez chacune et gardez le résultat à côté des fichiers d’unité. Les commandes ci-dessous lisent la relation actuelle puis exercent la transition qui compte le plus.

systemctl show work-vpn.service -p Conflicts -p After
systemctl start work-vpn.service
systemctl is-active office-sync.service
nmcli connection show --active

La troisième commande devrait laisser l’application inactive, et la quatrième ne devrait lister que la connexion du tunnel pendant qu’une session tourne. Un résultat différent signifie que la transition n’est pas appliquée du tout.

Le relancement pendant la session est le cas qui expose une conception fondée sur un emballage, car un raccourci lancé depuis le bureau ne consulte jamais un script de lancement. Si ce contournement compte, l’application relève du contrôle des applications et non du client VPN. Documentez aussi la fin de la session, et préférez une reprise délibérée à la réouverture de chaque processus arrêté à l’entrée. Consignez le résultat de chaque transition dans la même note que celle qui contient les fichiers d’unité.