L’ordinateur portable rejoint le Wi-Fi avant que vous ne vous asseyiez, et le VPN attend toujours un clic. Régler la connexion automatique sur le profil VPN ne change rien, car cet interrupteur régit l’activation du profil lui-même et NetworkManager traite le VPN comme un compagnon d’une connexion de base. Le mécanisme documenté est la liste secondaire de la connexion de base, et c’est une autre propriété à un autre endroit.

La connexion automatique n’est pas l’interrupteur du VPN

Un profil Wi-Fi ou Ethernet peut s’activer seul parce qu’il possède un appareil. Un profil de greffon VPN ne possède pas d’appareil au même sens ; il démarre aux côtés d’une connexion qui en possède un. C’est pourquoi l’indicateur de connexion automatique du VPN semble correct, s’enregistre bien et ne produit aucun tunnel. L’indicateur répond à une question sur le profil, pas sur le réseau dont il a besoin.

Lire le modèle ainsi explique aussi le mode de défaillance. La base se connecte, rien ne demande au VPN de démarrer, et le bureau affiche un VPN déconnecté à côté d’un réseau connecté. Rien n’est cassé ; l’association n’a jamais été faite.

Identifier les deux profils par UUID

nmcli -f NAME,UUID,TYPE connection show

Choisissez le profil Wi-Fi ou Ethernet qui doit déclencher le tunnel, puis le profil VPN voulu. Utilisez des UUID plutôt que des noms, car un nom est une étiquette qui peut être dupliquée ou modifiée, et l’UUID est ce que le chemin d’activation résout réellement.

Ne confondez pas un nom de profil avec un nom d’interface ou une adresse que la machine possède à cet instant. Ce sont trois identifiants différents qui se ressemblent par hasard dans un terminal, et les mélanger produit une modification qui ne vise rien.

Ajouter le VPN à la connexion de base

nmcli connection modify uuid "PRIMARY_UUID" +connection.secondaries "VPN_UUID"

La forme avec un plus ajoute à la liste existante ; l’omettre remplace la liste, ce qui supprime silencieusement toute autre connexion secondaire déjà configurée. Inspectez d’abord la valeur actuelle et notez-la avant de changer quoi que ce soit.

Les paramètres de connexion de NetworkManager décrivent les secondaires comme des connexions VPN démarrées avec la connexion de base. Qu’un profil WireGuard natif soit le même type d’objet dépend de la façon dont NetworkManager le gère, donc la même commande peut être le mauvais outil pour un tunnel qui apparaît comme une interface plutôt que comme un greffon VPN.

Il s’agit d’un changement de politique de connexion, pas d’un commutateur d’exécution. Appliquez-le via le processus de reconnexion que le déploiement approuve, et attendez-vous à ce que la première activation après le changement se comporte différemment de la session dans laquelle vous êtes.

Les secrets ne font pas partie de l’association

Une entrée secondaire dit « démarre ceci avec cela ». Rien n’y remet un mot de passe, ne déverrouille un trousseau ni ne répond à une invite. Un profil qui s’authentifie sans problème après une connexion au bureau peut encore échouer lorsqu’il est activé dans un contexte où l’agent de secrets n’est pas disponible.

Utilisez la disposition système ou l’agent de secrets pris en charge pour le déploiement réel. Stocker le mot de passe de tout le monde dans un script pour que le tunnel démarre sans surveillance transforme une conception d’authentification en fichier qui survit à l’emploi de son propriétaire.

Lisez les deux événements, puis vérifiez la ressource

Observez la connexion de base et l’activation du VPN pendant une tentative. Un événement VPN absent signifie que le déclencheur n’a jamais été configuré ou que l’UUID est faux. Un événement VPN suivi d’un échec d’authentification signifie que le déclencheur a fonctionné et que le problème restant est l’identifiant, ce qui est une autre correction.

Après l’activation, demandez la ressource qui a motivé l’installation au lieu de faire confiance à l’icône. Déconnectez ensuite délibérément et observez la suite, car une association de démarrage automatique n’est pas un commutateur d’urgence et ne promet pas des tentatives sans fin. Si l’exigence est « aucun trafic sans le tunnel », c’est une politique distincte qui exige sa propre configuration et son propre test. Confondre les deux, c’est ainsi qu’une machine finit par se reconnecter en boucle tandis que l’utilisateur croit être protégé.

Articles similaires