Donnez à chaque compte VPN son propre lanceur NetworkManager

Deux comptes VPN, une passerelle et une icône de bureau qui se connecte avec le dernier utilisateur. La cause habituelle est un lanceur qui réécrit le nom d’utilisateur d’un profil partagé juste avant la connexion, ou un lanceur qui recherche un nom d’affichage que les deux profils partagent par hasard. NetworkManager distingue déjà les profils par UUID, donc l’icône peut nommer exactement l’un d’eux et laisser l’identité tranquille. Ce qu’elle ne doit pas transporter, c’est le mot de passe.

Un lanceur est un pointeur, pas un coffre d’identifiants.

Trouvez l’UUID et confirmez l’identité

Listez les connexions enregistrées et lisez l’UUID, l’identifiant de connexion et le nom d’utilisateur que chaque profil stocke. Confirmez quel profil appartient à quel compte avant de créer quoi que ce soit, car un nom d’affichage est une étiquette et non une clé. Si les deux comptes ont besoin de passerelles différentes ou de profils différents, c’est une tâche de configuration à part.

Utilisez l’UUID dans le lanceur. La recherche par nom d’affichage fonctionne jusqu’à ce que quelqu’un renomme un profil, et l’icône se connecte alors avec le mauvais compte ou avec rien du tout.

Écrivez l’entrée de bureau

Une entrée de bureau a besoin d’un type, d’un nom et d’une ligne exécutable. La commande doit lever cet UUID et laisser NetworkManager demander le secret, ce à quoi sert nmcli --ask connection up uuid .... Gardez Terminal=true pour que l’invite soit visible lorsqu’un secret est nécessaire. Remplacez l’espace réservé par l’UUID que vous avez réellement observé, et n’ajoutez pas d’enveloppe shell juste pour masquer l’invite.

La spécification Desktop Entry définit Exec comme le programme et ses arguments. Ce n’est pas un script shell, et il n’en a pas besoin.

Laissez l’agent garder le secret

Les secrets appartiennent à l’agent par utilisateur, au trousseau de clés ou à une invite interactive. Un mot de passe dans Exec est visible dans la liste des processus, dans le fichier de bureau et sur toute capture de la boîte de dialogue des propriétés. Si le profil a besoin d’un secret, laissez l’invite prise en charge le recueillir et l’agent le mémoriser pour cet utilisateur.

--ask est interactif par conception. Ce n’est pas une recette pour l’automatisation sans surveillance, et cela ne garantit pas que chaque défi d’authentification ou greffon puisse être scripté.

Ne vous précipitez pas sur sudo

L’autorisation de modifier ou d’activer une connexion est une permission de NetworkManager accordée par sa politique, et non un privilège Unix. Lancer le lanceur avec sudo ne donne pas au processus le trousseau d’un autre utilisateur et ne corrige pas un rejet de la passerelle. Sur une machine partagée, vérifiez quels comptes locaux voient quels profils et à qui appartient chaque secret ; des icônes séparées ne créent pas d’isolation à elles seules.

Deux profils actifs pour la même passerelle peuvent aussi se disputer les routes ou enfreindre une règle de concurrence. C’est une question de politique, pas un défaut du lanceur.

Vérifiez toute l’action

Activez le lanceur une fois et confirmez trois choses : l’UUID qui est monté, l’identité que la passerelle a vue, et si une invite de secret est apparue là où vous l’attendiez. Si la connexion échoue, conservez le premier message d’erreur. Ajouter le mot de passe à la ligne de commande pour que le raccourci paraisse autonome masque cette erreur et crée un problème pire.

Écrivez l’UUID et la correspondance des comptes dans les notes de l’équipe. La personne suivante qui modifiera un profil doit savoir quelle icône en dépend, et c’est cette note qui empêche un renommage de devenir une panne.