Contrôle grisé de NetworkManager ? Vérifiez la propriété avant les autorisations

Les commutateurs VPN grisés du menu du bureau signalent que quelque chose ne va pas, et rien sur quoi. C’est une observation, pas un diagnostic. Trois frontières différentes peuvent produire le même contrôle mort : NetworkManager ne possède peut-être pas l’appareil, la session n’a peut-être pas l’autorisation de le modifier, ou le greffon d’éditeur VPN n’est peut-être pas installé du tout. Changer la mauvaise frontière, c’est ainsi qu’une correction de cinq minutes devient une après-midi de réinstallation de paquets.

Trois commandes en lecture seule séparent les cas avant toute modification.

Posez les trois questions dans l’ordre

nmcli device status
nmcli general permissions
nmcli connection show

Ce sont des commandes d’inspection pour un système qui utilise réellement NetworkManager, et elles peuvent être exécutées sans risque par un utilisateur ordinaire. Gardez les détails privés de connexion hors des journaux publics si vous collez la sortie quelque part.

L’état de l’appareil répond si l’interface est gérée et utilisable. La vue des autorisations répond ce que la session appelante a le droit de faire. La liste des connexions montre quels profils existent ; elle ne prouve pas qu’un éditeur VPN ou un greffon d’importation correspondant soit installé.

Propriété et autorisation sont deux pannes différentes

Un appareil marqué comme non géré échappe au contrôle de NetworkManager, et aucune quantité d’autorisations ne produira un commutateur fonctionnel. Le greffon ifupdown est une cause fréquente : son réglage géré décide du traitement des entrées du fichier interfaces, et un bloc résiduel peut maintenir une interface sous l’ancien outillage. L’existence du fichier n’est pas une instruction de supprimer son contenu, et retirer des entrées que vous n’avez pas écrites est un bon moyen de perdre la connectivité.

L’autorisation est un axe distinct. NetworkManager autorise les appelants non root via PolicyKit, et la réponse rapportée peut être oui, auth ou non. Une session sans agent d’authentification rapporte auth puis échoue silencieusement sur le bureau, ce qui ressemble à un contrôle cassé plutôt qu’à un agent manquant.

Ne corrigez ni l’un ni l’autre en exécutant le bureau en root

Exécuter toute la session en root pour faire fonctionner un commutateur change le modèle de sécurité de chaque application de la machine. Cela masque aussi la mauvaise configuration sous-jacente au lieu de la documenter. Si une action exige une autorisation administrative, c’est la conception prévue, et la correction relève de la politique ou de la manière dont l’agent est démarré.

De même, ne lancez pas une seconde copie de NetworkManager ni un démon concurrent. Deux gestionnaires qui se disputent le même appareil produisent un état difficile à raisonner et plus difficile encore à prendre en charge. Si un second démon semble le seul moyen de récupérer un contrôle, c’est la configuration du premier gestionnaire qu’il faut corriger. Arrêtez le démon supplémentaire avant de changer autre chose, sinon le test suivant mesurera les deux à la fois.

La question du greffon concerne aussi l’éditeur

Créer ou importer une connexion VPN nécessite le greffon qui fournit ce type de connexion, et sur un bureau il faut généralement aussi une intégration avec l’éditeur. Le paquet côté service peut être présent alors que le formulaire de l’éditeur manque, ce qui explique qu’une entrée de menu puisse exister et échouer malgré tout. Vérifiez les deux moitiés d’après l’empaquetage de la distribution au lieu de supposer qu’un seul paquet installe tout.

Un binaire client autonome n’est pas une preuve non plus. Installer un binaire OpenVPN ne donne pas à lui seul à l’éditeur du bureau un formulaire pour créer un profil OpenVPN.

Corrigez la frontière responsable, puis vérifiez

Une fois que vous savez quelle frontière est fausse, ne changez que celle-là. Marquer un appareil comme géré, accorder une autorisation ou installer un paquet d’éditeur sont trois opérations différentes avec trois profils de risque différents, et les mélanger rend le résultat impossible à attribuer. Si la propriété doit changer, faites-le avec un accès console ou hors bande disponible, car une erreur à cet endroit peut supprimer le réseau que vous utilisez pour la corriger.

Vérifiez ensuite avec le vrai compte et le vrai profil : confirmez la route, la vue DNS et l’emplacement du secret. Les boutons activés sont un état de l’interface, pas la preuve qu’un tunnel fonctionne. Notez l’état de l’appareil, la réponse d’autorisation et la version du greffon dans le ticket, pour que la personne suivante sache quelle frontière a réellement changé.