Linux sans magie #60 — NetworkManager : comprendre son fonctionnement et ses profils de connexion

Sur une VM, ip address affiche une adresse sur ens160. Dans nmcli connection show, l'administrateur découvre pourtant trois lignes nommées « Production », « Maintenance » et « Ancien profil ». Pourquoi trois connexions pour une seule carte ? Laquelle est réellement utilisée ? Et pourquoi modifier « Production » ne change-t-il pas immédiatement l'adresse visible ?

Les articles #57 à #59 ont distingué les générations d'outils et la configuration temporaire de la configuration persistante. Nous allons maintenant comprendre le modèle de NetworkManager, sans encore modifier de paramètres réseau : démon, périphérique, profil enregistré et connexion active sont quatre notions distinctes.

À quoi sert NetworkManager ?

NetworkManager est un service qui gère des connexions réseau sur de nombreux systèmes Linux. Il coordonne notamment des périphériques, des profils, l'obtention d'adresses et l'activation de connexions. Il peut piloter Ethernet, Wi-Fi et des connexions plus spécialisées, selon les composants installés et la plateforme.

Son démon principal est habituellement exposé comme NetworkManager.service sur les distributions utilisant systemd. Les outils nmcli (ligne de commande), nmtui (interface texte) et certaines interfaces graphiques s'adressent au même gestionnaire : ils ne constituent pas trois moteurs qui configurent chacun une adresse différente.

Administrateur
   |-- nmcli (CLI)
   |-- nmtui (interface texte)
   '-- interface graphique
               |
               v
        NetworkManager (service)
          |         |
          |         '-- Profils de connexion enregistrés
          |
          '-- Activation sur un périphérique géré
                         |
                         v
              État courant du noyau
                  ip address / ip route

Il ne faut pas confondre cet ensemble avec ip : ip observe ou change directement l'état réseau courant, tandis que NetworkManager tente d'appliquer et de maintenir une configuration voulue pour les périphériques qu'il gère.

Quatre objets à ne jamais confondre

Notion	Signification	Exemple fictif
Périphérique (device)	Interface réseau observée ou suivie	`ens160`
Profil (connection profile)	Ensemble de réglages pouvant être sauvegardés	`Production`
Connexion active	Activation d'un profil dans un contexte donné	`Production` actif sur `ens160`
Service NetworkManager	Gestionnaire qui choisit et applique des profils	`NetworkManager.service`

Un profil possède un nom lisible (connection.id) et un UUID, utilisé pour l'identifier de façon unique. Le nom peut ressembler à celui de l'interface, mais aucune règle ne l'impose. Plusieurs profils peuvent convenir à une même interface, et la plupart peuvent rester inactifs.

Une connexion active n'est donc pas simplement « un fichier sur disque ». C'est un état d'activation : NetworkManager tente d'utiliser des réglages sur un périphérique, avec des informations résultant éventuellement de DHCP, du réseau et de l'environnement courant.

Préparer un laboratoire de lecture seule

Pré-requis : un système où NetworkManager est installé et accessible, avec la commande nmcli. Un compte non privilégié suffit souvent pour les consultations présentées ici. Ne lancez aucune commande d'activation, de modification ni de déconnexion sur un serveur accessible uniquement par SSH.

Commencez par vérifier la présence du programme et du service :

command -v nmcli
nmcli general status
systemctl is-active NetworkManager

Si nmcli est absent ou si NetworkManager n'est pas actif, arrêtez ce lab : cela ne prouve pas une panne et ne justifie pas de démarrer un second gestionnaire. Votre machine peut utiliser systemd-networkd, ifupdown ou une gestion spécifique au cloud. Sur un conteneur sans systemd, la commande systemctl peut elle-même ne pas être pertinente.

Le résultat attendu est de savoir si l'outil fonctionne sur cette installation, pas de rendre NetworkManager universel.

Étape 1 — Lire l'état des périphériques

nmcli device status
ip -br link
ip -br address

La première commande donne la vue NetworkManager ; les deux autres montrent l'état courant du noyau. L'affichage peut notamment présenter connected, disconnected ou unmanaged dans la colonne d'état de NetworkManager.

Exemple fictif :

DEVICE  TYPE      STATE         CONNECTION
ens160  ethernet  connected     Production
lo      loopback  connected     lo
ens192  ethernet  unmanaged     --

unmanaged signifie que NetworkManager n'administre pas ce périphérique selon sa configuration et son état. Ce n'est pas synonyme de carte défectueuse ou de lien coupé. De même, connected indique un état selon NetworkManager, pas que tous les services distants répondent.

Pour demander le détail d'un périphérique connu, utilisez nmcli device show avec son nom réel :

# Remplacer le nom par celui observé sur votre machine
nmcli device show <interface-verifiee>

Le résultat peut contenir des adresses, routes, informations DNS et autres paramètres de la connexion courante ; évitez de diffuser cette sortie brute.

Étape 2 — Distinguer les profils enregistrés des profils actifs

nmcli connection show
nmcli connection show --active

La première commande liste les profils connus de NetworkManager, notamment ceux présents en mémoire ou sur disque. La seconde limite la liste aux connexions actives. C'est la différence fondamentale de ce chapitre.

NAME             UUID                                  TYPE      DEVICE
Production       11111111-1111-4111-8111-111111111111  ethernet  ens160
Maintenance      22222222-2222-4222-8222-222222222222  ethernet  --
Ancien profil    33333333-3333-4333-8333-333333333333  ethernet  --

Les UUID sont inventés pour ce lab. L'indication -- dans la colonne DEVICE ne signifie pas nécessairement un profil invalide : il peut simplement être inactif.

Le couple UUID + profil est plus fiable qu'un nom seul dans les environnements qui réutilisent des intitulés. Pour lire les propriétés précises, une sélection explicite par UUID évite les ambiguïtés entre profils homonymes. Le #61 reviendra sur cette pratique.

Étape 3 — Lire un profil sans l'activer

La commande suivante illustre comment sélectionner un profil : remplacez l'UUID fictif par un UUID réellement relevé. Il s'agit d'une commande de lecture seule.

nmcli connection show uuid <uuid-releve>

On peut rechercher notamment connection.id, connection.uuid, connection.type, connection.interface-name, connection.autoconnect, ipv4.method et ipv6.method.

Il faut distinguer les réglages statiques du profil des informations effectivement acquises lors de la connexion. Un profil utilisant DHCP peut conserver ipv4.method=auto sans enregistrer durablement l'adresse louée : l'adresse visible avec ip peut changer au prochain bail.

Attention aux secrets : certains profils comprennent des paramètres sensibles. N'employez pas l'option --show-secrets pour un inventaire général et anonymisez les captures.

Étape 4 — Comprendre l'activation et autoconnect

connection.autoconnect indique si NetworkManager peut activer automatiquement un profil lorsque les conditions sont réunies. Ce n'est pas une garantie qu'il sera toujours actif : le périphérique doit être géré, disponible et compatible, et des règles de priorité ou d'autres connexions peuvent intervenir.

Plusieurs profils peuvent être candidats à l'activation. NetworkManager dispose notamment de réglages de priorité d'autoconnexion ; il ne faut donc pas conclure que le profil affiché en premier dans nmcli connection show sera forcément choisi au démarrage.

Trois situations très différentes peuvent apparaître :

Profil présent et actif : le gestionnaire l'a activé sur une ressource.
Profil présent mais inactif : il existe, sans être actuellement appliqué.
Périphérique unmanaged : NetworkManager ne pilote pas ce périphérique, même si la pile réseau de la machine fonctionne autrement.

L'activation réelle peut entraîner des changements d'adresse, de route, de DNS et de connectivité. Nous ne testons aucune activation dans ce laboratoire.

Serveur, Desktop et cloud : ne pas déduire le gestionnaire du contexte

NetworkManager se rencontre fréquemment sur RHEL et d'autres distributions apparentées ainsi que sur divers environnements Desktop. Ubuntu peut associer Netplan à NetworkManager comme moteur d'application ; certaines installations serveur emploient plutôt systemd-networkd.

Mais la distribution et le type de machine ne suffisent pas. Un administrateur peut personnaliser une image serveur ; une VM peut recevoir sa configuration d'un mécanisme de provisionnement ; un conteneur peut exposer seulement une partie des périphériques du système hôte.

Question décisive : NetworkManager gère-t-il le périphérique qui nous intéresse ? Croisez nmcli device status, nmcli connection show --active et ip -br address, au lieu de déduire la réponse du nom de la distribution.

Où les profils sont-ils conservés ?

La persistance des profils dépend des plugins de paramètres et de la configuration de NetworkManager. Le plugin keyfile utilise couramment /etc/NetworkManager/system-connections/, mais il existe aussi des profils générés, temporaires ou conservés ailleurs selon la distribution et les mécanismes utilisés.

Ne modifiez pas directement les fichiers au hasard. Un profil peut aussi avoir été généré par Netplan ou par un composant de provisionnement. Il vaut mieux examiner d'abord les informations exposées par NetworkManager et retrouver la source faisant autorité.

La présence d'un fichier n'affirme pas qu'il est actif ; réciproquement, un profil actif peut ne pas être enregistré sous la forme d'un fichier persistant classique.

Petit défi : reconstituer la relation profil–interface

Sur une VM ou un poste autorisé où NetworkManager est effectivement utilisé, exécutez :

nmcli device status
nmcli connection show
nmcli connection show --active
ip -br address

Répondez ensuite à quatre questions : quelle interface porte votre adresse actuelle, quel profil est actif sur cette interface, quels profils sont enregistrés mais inactifs, et quelles interfaces ne sont pas gérées par NetworkManager ?

Le test est réussi lorsque vous pouvez expliquer, par des observations, pourquoi le nombre de profils n'est pas nécessairement égal au nombre d'interfaces physiques. Si les informations ne suffisent pas à désigner le responsable de l'interface, indiquez « non déterminé » et vérifiez les autres gestionnaires possibles.

Aucun nettoyage n'est nécessaire : vous n'avez modifié ni profil, ni service, ni route.

Risques, limites et préparation du retour arrière

Les commandes exécutables de cet article sont en lecture seule. En revanche, les commandes nmcli connection up, nmcli connection down, nmcli device disconnect ou la modification d'un profil actif peuvent interrompre une session SSH. Ne les essayez pas sur la carte d'administration pour comprendre un message d'état.

Lors d'une future modification, identifiez le profil par son UUID, sauvegardez les paramètres nécessaires, prévoyez une console indépendante et validez une stratégie de retour arrière avant l'intervention. La portée réelle du changement doit être contrôlée après activation.

Les états NetworkManager ne constituent pas à eux seuls un test de connectivité TCP/IP ni une preuve de bon fonctionnement applicatif. Ils décrivent la gestion des périphériques et des profils ; le dépannage complet nécessitera plus tard des tests de routes, DNS et services.

Références officielles

Conclusion — Un profil n'est pas une interface

L'interface est un périphérique ; le profil contient une configuration ; la connexion active correspond à une activation ; NetworkManager est le service qui orchestre l'ensemble. Une même interface peut avoir plusieurs profils, dont un seul est actuellement utilisé dans un cas courant, et un profil sauvegardé peut ne pas être activé.

Cette distinction élimine une grande partie des malentendus rencontrés entre serveurs, Desktop et distributions. Dans le #61, nous verrons comment employer nmcli pour inspecter précisément les propriétés d'un profil et préparer des changements avec une procédure de validation et de retour arrière, plutôt que de modifier une connexion SSH à l'aveugle.