Linux sans magie #57 — Pourquoi Linux possède autant d’outils réseau ? Comprendre les différentes générations

Un administrateur habitué à ifconfig se connecte sur un nouveau serveur Ubuntu et ne trouve plus la commande. Son collègue lui conseille ip addr. Sur un poste de travail, une autre personne utilise nmcli ou nmtui. Sur une VM, la configuration se trouve dans un fichier Netplan, et sur un ancien serveur Debian, dans /etc/network/interfaces.

Qui a raison ? Potentiellement tout le monde, mais pas pour la même opération. La confusion vient d'une question qu'on pose trop rarement : cet outil consulte-t-il l'état réseau du noyau, pilote-t-il un gestionnaire ou définit-il une configuration qui survivra au redémarrage ?

Après le #56, qui reliait stockage local et dépendances réseau, voici notre première carte du réseau Linux. Avant d'aborder IP, les routes et DNS, nous allons apprendre à reconnaître les générations et les couches d'outils. Les exemples restent en lecture seule afin d'éviter de couper une session SSH.

Le problème : plusieurs outils, plusieurs responsabilités

Linux expose au noyau des interfaces, des adresses, des routes et des voisins réseau. Leur état courant n'est pas forcément identique à la configuration sauvegardée sur disque.

Une machine peut avoir une adresse IP aujourd'hui et la perdre après redémarrage si elle n'a été ajoutée qu'avec une commande ponctuelle. À l'inverse, un profil enregistré dans un gestionnaire peut réappliquer une adresse, des routes ou des paramètres DNS après un renouvellement de connexion.

Administrateur / automatisation
          |
          +-- Observer ou modifier l'état noyau
          |     ip (iproute2)       ifconfig (net-tools, historique)
          |
          +-- Interagir avec un gestionnaire
          |     nmcli / nmtui / GUI → NetworkManager
          |     networkctl         → systemd-networkd
          |
          +-- Décrire une configuration voulue
                Netplan YAML → renderer NetworkManager OU networkd
                ifupdown     → /etc/network/interfaces

                      ↓
        Interfaces, adresses, routes du noyau Linux

Ce schéma simplifie des interactions réelles : certains gestionnaires écrivent des fichiers, parlent au noyau et exposent des API ; certains environnements mélangent plusieurs mécanismes. L'outil présent sur la machine ne prouve pas qu'il gère l'interface qui pose problème.

Première génération : ifconfig, route et net-tools

Pendant longtemps, les administrateurs ont employé ifconfig pour afficher des interfaces, route pour examiner les routes et netstat pour certaines connexions. Ces outils appartiennent à l'ensemble net-tools.

ifconfig n'est ni une commande interdite ni une preuve de mauvaise administration : elle fonctionne encore dans des environnements qui l'installent. Mais ses possibilités et certaines interfaces techniques sont anciennes. Son propre manuel documente des limites d'affichage, par exemple pour certaines adresses matérielles, et renvoie vers ip link pour une information plus adaptée.

La famille iproute2 est devenue le choix courant pour interroger les fonctionnalités réseau modernes du noyau.

Besoin d'observation	Outil historique	Outil actuel
Lister les interfaces	`ifconfig -a`	`ip link show`
Voir les adresses IP	`ifconfig`	`ip address show`
Consulter les routes	`route -n`	`ip route show`
Voir la table des voisins IPv4	`arp -n`	`ip neigh show`

Il ne s'agit pas d'équivalences parfaites : les formats, les familles d'adresses couvertes et les informations exposées diffèrent. Le #58 les comparera en détail, avec des exemples de migration.

Si ifconfig est absent, ne l'installez pas automatiquement pour traiter un incident. Vérifiez d'abord ce que ip permet d'observer sur l'hôte.

Deuxième approche : ip agit sur l'état réseau du noyau

La commande ip d'iproute2 regroupe plusieurs sous-commandes spécialisées. Pour une première reconnaissance sans modification :

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

Ces commandes lisent les interfaces, les adresses et les routes dans l'espace de noms réseau courant. L'affichage de UP n'atteste pas à lui seul que l'application peut joindre un service distant : la liaison, l'adressage, les routes, les règles de filtrage et le service visé jouent chacun un rôle.

ip dispose aussi de commandes qui modifient adresses, routes et interfaces. Ce n'est pas l'objet de ce premier article. Ajouter une adresse avec ip agit sur l'état en cours, mais n'enregistre pas automatiquement un profil persistant dans NetworkManager, Netplan ou ifupdown. Un gestionnaire peut même réappliquer plus tard sa configuration et écraser une modification ponctuelle.

Cette distinction entre état observé et configuration souhaitée sera approfondie au #59.

NetworkManager : un gestionnaire, plusieurs interfaces

NetworkManager est un service de gestion réseau. Il gère des périphériques, des profils de connexion et des activations de connexion. L'utilisateur peut travailler avec ce même gestionnaire par plusieurs voies :

nmcli : une interface en ligne de commande, adaptée notamment aux scripts et à l'administration distante ;
nmtui : une interface texte interactive, utilisable sans bureau graphique lorsqu'elle est disponible ;
des interfaces graphiques : clients du même service dans certains environnements Desktop.

nmcli et nmtui ne constituent donc pas deux moteurs réseau concurrents. Leur interface change, tandis que les profils et l'état de NetworkManager restent le point commun.

Vous pouvez observer un hôte utilisant NetworkManager avec :

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

Les deux dernières commandes montrent une différence essentielle : un profil enregistré n'est pas nécessairement actif. Une interface peut également être marquée unmanaged, ce qui indique que NetworkManager ne prend pas sa gestion en charge selon sa configuration.

Ne confondez pas un nom de connexion avec un nom d'interface. Par exemple, un profil « Production » peut être activé sur une interface ens160. Les commandes d'administration précises viendront dans les #60 et #61.

nmtui : un autre visage du même NetworkManager

Sur une machine sans environnement graphique, nmtui affiche des menus dans le terminal. Cela peut sembler plus simple que de longues options nmcli, mais les deux interagissent avec NetworkManager.

Attention : les menus de nmtui permettent aussi d'éditer ou d'activer des connexions. Ouvrir l'interface n'est pas en soi une réparation et cliquer au hasard peut interrompre la connexion SSH. La présence de nmtui dépend des paquets installés.

Le #62 montrera quand cette interface est utile et dans quelles situations la CLI explicite se prête mieux à un changement reproductible.

systemd-networkd : un autre gestionnaire réseau

systemd-networkd est un service capable de configurer des liens réseau à partir de fichiers de configuration. networkctl fournit des informations et des actions de contrôle pour cet environnement.

Pour observer, lorsque les composants sont disponibles :

systemctl is-active systemd-networkd
networkctl list
networkctl status

Là encore, voir le service actif ne prouve pas que toutes les interfaces lui appartiennent. Certaines peuvent être non gérées par networkd ou suivies par un autre système. La configuration réseau peut aussi être générée par un outil en amont.

Sur des serveurs administrés sans interface graphique, networkd peut constituer un choix cohérent ; cela ne signifie pas que tous les serveurs Linux l'utilisent. Le #63 détaillera les fichiers de configuration et leur relation avec networkctl.

Netplan : un format de déclaration, pas un troisième moteur universel

Netplan est particulièrement rencontré dans des installations Ubuntu. Il permet de décrire la configuration réseau dans des fichiers YAML, puis de la transmettre à un renderer, généralement systemd-networkd ou NetworkManager.

# Exemple documentaire — ne pas appliquer tel quel
network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      dhcp4: true

Cette déclaration est illustrative, sans garantie que enp1s0 existe sur votre hôte. Elle ne doit pas être copiée dans une VM de production. Le renderer networkd correspond au backend systemd-networkd ; une autre machine peut employer renderer: NetworkManager.

Netplan ne remplace pas automatiquement ip pour observer l'état courant, ni le backend qu'il utilise. Il exprime ce qui doit être configuré, puis s'appuie sur des composants qui gèrent effectivement les interfaces.

La documentation Netplan cite souvent NetworkManager sur Ubuntu Desktop et networkd sur Ubuntu Server, mais ce sont des configurations habituelles, pas une règle permettant de diagnostiquer n'importe quelle machine. Une image cloud, une VM personnalisée ou une migration peut déroger à cette répartition.

ifupdown : la méthode historique des fichiers interfaces

Dans des environnements Debian utilisant ifupdown, le fichier /etc/network/interfaces décrit les interfaces à configurer par ifup et ifdown. Des installations peuvent aussi inclure des fichiers via /etc/network/interfaces.d/.

Il est possible d'examiner leur présence sans les modifier :

test -f /etc/network/interfaces && echo "Fichier interfaces présent"
ls -ld /etc/network/interfaces.d 2>/dev/null

Ces fichiers ne démontrent pas à eux seuls qu'ifupdown contrôle le réseau actuel : ils peuvent être hérités d'une ancienne configuration, partiellement utilisés ou coexister avec d'autres composants. Et ifdown n'est surtout pas une commande de test sur l'interface qui porte votre connexion distante.

Le #65 abordera ce modèle et ses différences avec la gestion des profils NetworkManager.

Serveur, Desktop, cloud : pourquoi la distribution ne suffit pas

La bonne question n'est pas « quelle commande utilise Ubuntu ? » ou « quelle commande utilise un serveur ? ». C'est : quel composant possède réellement la configuration de cette interface, sur cette installation précise ?

Environnement fréquent	Ce que l'on peut rencontrer	Ce qu'il faut vérifier
Ubuntu Desktop	Netplan et NetworkManager	Renderer et profil actif
Ubuntu Server	Netplan et networkd, selon image et personnalisation	Fichiers YAML et backend réel
RHEL ou distributions apparentées	NetworkManager, `nmcli`, `nmtui`	État des périphériques et profils
Debian serveur	ifupdown, NetworkManager ou networkd selon installation	Services, fichiers et interfaces gérées
Machine cloud / conteneur	Configuration générée par plateforme, namespace, agents	Propriétaire de la configuration et portée du diagnostic

Ces lignes sont des possibilités, pas un tableau de compatibilité garanti. Ne déduisez jamais le gestionnaire d'une interface de la seule distribution ou de la présence d'une commande dans le PATH.

Une méthode sûre pour identifier le bon outil

Voici un premier inventaire, sans changement de configuration :

cat /etc/os-release
ip -br link
ip -br address
ip route show
systemctl is-active NetworkManager
systemctl is-active systemd-networkd

Si les outils existent, complétez selon le contexte :

nmcli device status
nmcli connection show --active
networkctl list
ls -l /etc/netplan/
ls -l /etc/network/interfaces

Certaines lignes peuvent échouer parce que le paquet n'est pas installé, qu'un service n'existe pas, qu'une interface n'est pas gérée ou qu'un chemin n'est pas présent. C'est une information utile, pas un motif pour installer ou activer automatiquement un gestionnaire supplémentaire.

Comparez trois types de preuves : l'état noyau (ip), le gestionnaire actif pour le périphérique concerné (par exemple NetworkManager ou networkd), et la configuration persistante qui fait autorité (profil, fichier de service, YAML Netplan ou fichier interfaces).

Ce n'est qu'après cette corrélation que l'on peut choisir un outil de modification. Sur un serveur accessible uniquement par SSH, prévoyez au préalable un accès console indépendant ou un mécanisme de retour arrière testé.

Le piège classique : deux administrateurs, deux changements

Un administrateur ajoute une adresse provisoire avec ip. Un autre modifie un profil NetworkManager pour la même interface. Après un redémarrage ou une réactivation, l'adresse provisoire disparaît ; l'équipe conclut à tort que « Linux n'enregistre pas les modifications ».

Le problème est plutôt un désaccord entre l'état instantané et le système chargé de restaurer l'état souhaité. Inversement, modifier un fichier Netplan sans appliquer ou faire prendre en compte sa configuration ne garantit pas un changement immédiat du réseau courant.

Il faut donc distinguer :

Observer le réseau tel que le noyau le voit.
Identifier qui gère chaque interface.
Modifier le bon profil ou la bonne source de configuration selon une procédure approuvée.
Vérifier l'état, la persistance et la connectivité après l'opération.

Un poste Desktop et un serveur headless ne requièrent pas deux théories différentes du réseau : ils peuvent simplement utiliser des gestionnaires et interfaces d'administration différents.

Sécurité, limites et retour arrière

Les commandes d'observation de cet article ne changent pas volontairement les interfaces, adresses ni routes. Elles peuvent toutefois exposer des noms d'hôtes, adresses, profils ou topologies sensibles dans une capture ou un compte rendu : anonymisez ces informations avant publication.

N'exécutez pas à l'aveugle ip link set ... down, nmcli device disconnect, ifdown, netplan apply, networkctl reconfigure ou un redémarrage de gestionnaire sur une interface distante. Ces actions peuvent couper SSH ou affecter d'autres services. Aucune reconfiguration ni test de perte de connectivité n'a été effectué pour cet article.

Le retour arrière dépend du gestionnaire et du type de configuration. Il devra être défini avant chaque tutoriel qui modifie le réseau : copie contrôlée de configuration, accès console, fenêtre de maintenance et test de reconnexion.

Références officielles

Conclusion — Le bon outil est celui de la bonne couche

Les commandes réseau de Linux ne se remplacent pas toutes les unes les autres. ifconfig et ip racontent une évolution des outils d'accès à l'état du noyau ; nmcli et nmtui parlent à NetworkManager ; networkctl interagit avec l'environnement networkd ; Netplan déclare une configuration que d'autres composants appliqueront.

Avant tout changement, vérifiez l'état, le gestionnaire et la source persistante. Cette discipline évite de perdre l'accès à une machine et explique pourquoi une commande « correcte » sur un serveur peut ne pas être la bonne sur un autre.

Dans le #58, nous comparerons concrètement ifconfig et ip, leurs équivalents, leurs différences d'affichage et les pièges de migration d'un environnement à l'autre.