Linux sans magie #59 — Configuration réseau temporaire ou persistante : qui contrôle réellement les interfaces ?

Un administrateur ajoute une adresse IP avec ip addr. Tout fonctionne. Après un redémarrage, l'adresse disparaît. Sur une autre machine, elle disparaît même sans redémarrage, lors de la réactivation d'une connexion. Sur un troisième serveur, une modification dans un fichier YAML paraît correcte, mais le réseau n'a pas changé.

Ce ne sont pas trois bugs identiques. Il faut distinguer l'état courant du noyau, la configuration souhaitée et le composant chargé de l'appliquer. Après les articles #57 et #58 consacrés aux familles d'outils réseau, nous examinons leur relation dans une exploitation réelle.

L'objectif n'est pas de changer une adresse en production : nous allons identifier qui contrôle une interface, comparer les méthodes serveur et Desktop, puis construire un diagnostic sans interrompre SSH.

Une interface possède un état, pas nécessairement une configuration sauvegardée

Le noyau Linux connaît les interfaces, leurs adresses et leurs routes. La commande ip permet de les observer ou de les modifier directement. Mais cette information n'explique pas toujours comment elles sont arrivées là.

Fichiers / profils persistants
       |
       +-- NetworkManager (profils, nmcli, nmtui, GUI)
       +-- systemd-networkd (fichiers .network)
       +-- ifupdown (/etc/network/interfaces)
       +-- Netplan (YAML → NetworkManager ou networkd)
       +-- plateforme cloud / automatisation / autre service
                       |
                       v
             État réseau du noyau
          interfaces, adresses, routes
                       |
                       v
                  ip address
                  ip route

Netplan n'est pas simplement un quatrième gestionnaire indépendant : il prépare une configuration destinée à un moteur, appelé renderer. De même, nmcli et nmtui sont deux interfaces du même NetworkManager. La pile exacte dépend de la distribution, de l'installation et parfois de l'interface concernée.

Un administrateur peut modifier temporairement l'état noyau alors qu'un service continue à considérer une autre configuration comme référence.

Temporaire et persistant : des termes à préciser

Une modification directe par ip address add ou ip route add agit sur l'état en cours. Elle ne crée pas automatiquement un profil NetworkManager, un fichier .network, une déclaration Netplan ou une entrée ifupdown.

Elle peut cesser de s'appliquer après un redémarrage, une désactivation d'interface, une réactivation par le gestionnaire ou une autre opération qui reconstruit le réseau. Ce n'est donc pas une méthode générale pour établir une configuration persistante.

À l'inverse, modifier un fichier ou un profil peut modifier la configuration souhaitée sans changer immédiatement l'état visible avec ip. Une étape d'application, d'activation ou de rechargement peut être nécessaire, selon le système.

Action	État courant	Configuration destinée à persister
`ip address add`	Change si la commande réussit	Non, pas à elle seule
`nmcli connection modify`	Pas forcément immédiatement	Modifie un profil NetworkManager
`nmcli device modify`	Tente une modification temporaire du périphérique actif	Ne modifie pas le profil sauvegardé
Fichier `.network` networkd	Après prise en compte par le service	Oui, si ce fichier fait autorité
YAML Netplan	Après génération/application effective	Oui, si cette déclaration fait autorité
`/etc/network/interfaces`	Après traitement par ifupdown	Oui, dans un système qui l'utilise

Une configuration peut également être générée, remplacée ou gérée automatiquement par un autre système. La présence d'un fichier n'établit pas qu'il fait autorité.

Étape 1 — Observer ce qui fonctionne maintenant

Notre lab se déroule sur la machine à diagnostiquer, sans droits d'administration pour les premières commandes et sans aucune modification.

ip -br link
ip -br address
ip -4 route show
ip -6 route show

Ces quatre commandes montrent la vue réseau du noyau dans l'espace de noms courant. Sur un conteneur, ce peut être seulement la vue du conteneur ; sur une VM, elle ne décrit pas la configuration de l'hyperviseur.

Relevez le nom réel de l'interface qui porte la connexion d'administration : n'imaginez pas qu'elle s'appelle eth0 ou ens160. Une route par défaut peut fournir un indice, mais elle ne prouve ni quel service contrôle l'interface ni la disponibilité de l'accès SSH.

Voici un exemple inventé de résultat d'adressage :

ens160           UP             192.0.2.25/24
lo               UNKNOWN        127.0.0.1/8 ::1/128

192.0.2.0/24 est une plage réservée à la documentation. Ne copiez jamais cette adresse comme une configuration réelle de serveur.

Étape 2 — Identifier les services susceptibles d'agir

Les gestionnaires les plus courants peuvent être recherchés sans redémarrer de service :

systemctl is-active NetworkManager
systemctl is-active systemd-networkd
command -v nmcli
command -v networkctl
command -v netplan

Une ligne peut répondre inactive, unknown ou échouer parce que le composant n'est pas installé. Cette réponse n'autorise pas à l'activer pour voir si cela résout la panne.

Même si NetworkManager est actif, il peut laisser une interface unmanaged. Même si networkd est actif, il peut ignorer des interfaces sans fichier correspondant. Il faut donc comparer les services avec leur prise en charge effective de l'interface cible.

Si NetworkManager est présent, recherchez :

nmcli device status
nmcli connection show --active

device status renseigne notamment l'état géré ou non géré du périphérique. La seconde commande affiche les connexions actives. Un profil enregistré n'est pas nécessairement actif, et un profil actif possède un nom qui peut différer du nom de l'interface.

Si systemd-networkd est utilisé :

networkctl list
networkctl status

networkctl peut indiquer quel fichier réseau est associé à un lien sur les versions qui exposent cette information. La sortie varie selon les versions, les droits et l'environnement ; recoupez-la avec les fichiers chargés et la configuration du service.

Étape 3 — Retrouver la source persistante

Cette étape consiste à inspecter, non à éditer :

ls -l /etc/netplan/
ls -l /etc/systemd/network/
ls -l /etc/network/interfaces

Ces chemins peuvent ne pas exister. La configuration de networkd peut aussi venir de /run/systemd/network ou de /usr/lib/systemd/network. Les profils NetworkManager sont souvent des fichiers de configuration administrés par le service, mais leur emplacement et leur origine peuvent varier ; consultez en priorité l'interface officielle du gestionnaire plutôt que de modifier un fichier au hasard.

Pour Netplan, si la commande existe :

netplan get

Cette lecture peut montrer le renderer prévu : networkd ou NetworkManager. Mais elle ne démontre pas, isolément, que la configuration a bien été appliquée ou qu'elle gouverne chaque interface.

Important : sur certaines images cloud, cloud-init ou une autre automatisation peut générer les fichiers réseau au démarrage. Modifier directement le fichier généré peut être inutile ou remplacé plus tard. Recherchez le propriétaire du fichier et la procédure de la plateforme avant d'agir.

Étape 4 — Comprendre l'écart entre profil et état

Imaginons que l'interface ens160 possède actuellement 192.0.2.25/24. Un profil NetworkManager enregistré prévoit une autre adresse. Avec ip -br address, on voit l'état effectif ; avec les informations du profil NetworkManager, on examine l'intention enregistrée.

Pour un hôte NetworkManager, l'inventaire sûr est :

nmcli connection show
nmcli connection show --active
nmcli device status

Pour un hôte Netplan, le YAML exprime la configuration désirée, tandis que ip montre ce que le noyau utilise maintenant. Entre les deux, il existe une étape d'application et un backend : c'est précisément la raison pour laquelle les trois vues peuvent diverger temporairement.

Pour un hôte ifupdown, /etc/network/interfaces représente la configuration selon ce système. Mais ifupdown ne doit pas être supposé propriétaire de l'interface si un autre gestionnaire la contrôle.

Un exemple d'erreur de diagnostic serait : « ip affiche l'adresse, donc Netplan est correctement configuré ». C'est faux : ip atteste d'un état, pas de son origine ni de sa survie au redémarrage.

Pourquoi nmcli peut lui-même être temporaire ou persistant

Le nom d'une commande ne suffit pas. Dans NetworkManager, nmcli connection modify et nmcli device modify ne poursuivent pas le même objectif :

connection modify change les propriétés d'un profil de connexion. Cela ne signifie pas nécessairement que la modification a déjà été appliquée au périphérique actif.
device modify vise des paramètres actifs du périphérique et permet des modifications temporaires sans conserver ces changements dans le profil.

Les mécanismes de réapplication et d'activation diffèrent selon les propriétés. Nous examinerons précisément les commandes et les modes de validation au #61, dans un lab séparé. Ici, aucune modification de profil ni d'interface n'est nécessaire.

La documentation de NetworkManager distingue explicitement ces commandes, ce qui explique pourquoi deux administrateurs peuvent croire faire « la même chose » alors qu'ils interviennent à des niveaux différents.

Serveur ou Desktop : ce qui change vraiment

Le noyau et ip restent présents sous les interfaces d'administration, mais les sources et les mécanismes peuvent différer.

Environnement	Situation fréquente, non garantie	Question décisive
Ubuntu Desktop	Netplan avec renderer NetworkManager	Quel profil contrôle l'interface ?
Ubuntu Server	Netplan avec renderer networkd	Quel YAML et quel backend s'appliquent ?
RHEL / Rocky / AlmaLinux	NetworkManager	Le périphérique est-il géré et par quel profil ?
Debian personnalisé	ifupdown, NetworkManager ou networkd	Quelle pile est réellement activée ?
VM, cloud ou conteneur	Configuration générée, agent ou namespace	Qui recrée le réseau et à quelle couche ?

Ce tableau ne dispense jamais d'inspecter la machine réelle. Sur un serveur accessible uniquement par SSH, une mauvaise modification d'adresse ou de route peut rendre l'hôte inaccessible, même si le fichier final paraît syntaxiquement correct.

Petit défi sans risque : trouver le propriétaire de l'interface

Sur une machine autorisée, choisissez une interface actuellement utilisée et remplissez ce tableau à partir des commandes précédentes :

Question	Réponse à relever
Quel est son nom réel ?	Résultat de `ip -br link`
Quelle adresse utilise-t-elle ?	Résultat de `ip -br address`
Quel service gère le périphérique ?	Indices `nmcli`, `networkctl`, autres
Où se trouve la configuration destinée à persister ?	Profil ou fichier réellement pris en compte
Qu'est-ce qui peut la réécrire ?	Gestionnaire, agent cloud, automatisation

Si vous n'arrivez pas à prouver qu'un gestionnaire précis contrôle l'interface, écrivez « non déterminé » plutôt que de déduire la réponse de la distribution. C'est un résultat honnête et exploitable.

La vérification est réussie quand vous pouvez expliquer la différence entre l'adresse visible et la source de configuration qui doit la restaurer.

Sécurité, limites et retour arrière

Nous n'exécutons ici aucune commande modifiant le réseau. Aucun rollback n'est nécessaire pour ce lab en lecture seule. Les sorties peuvent toutefois contenir des adresses, profils et détails d'infrastructure sensibles : ne publiez pas de captures brutes.

Les commandes suivantes sont des exemples d'actions à ne pas improviser à distance, pas des étapes de ce tutoriel :

# NE PAS EXÉCUTER sur une interface d'administration sans procédure
ip address flush dev <interface>
nmcli device disconnect <interface>
ifdown <interface>
netplan apply

Une modification future doit avoir un plan de sauvegarde des paramètres, un accès console indépendant, un critère de vérification, et un mécanisme de retour arrière adapté au gestionnaire. Netplan fournit notamment netplan try, mais même son retour automatique doit être vérifié : les docs signalent des limites selon certaines configurations, notamment virtuelles.

Références officielles

Conclusion — Toujours comparer trois couches

État noyau, gestionnaire actif, configuration persistante. Ces trois couches doivent être identifiées avant de modifier une adresse IP, une route ou un serveur DNS. Une commande peut être correcte et produire un résultat qui disparaît parce que vous n'avez pas changé la source faisant autorité.

Dans le #60, nous examinerons le fonctionnement interne de NetworkManager, les périphériques, les profils et la différence entre connexion enregistrée et connexion activée. Le but restera le même : comprendre avant de toucher au réseau.