Linux sans magie #63 — systemd-networkd et networkctl : comprendre la gestion réseau côté serveur

Deux serveurs Linux affichent la même adresse avec ip -br address. Sur le premier, nmcli montre un profil « Production ». Sur le second, nmcli n'existe pas, mais networkctl status signale un fichier .network. Est-ce que le réseau du second est mal configuré ? Non : ce sont deux façons différentes d'administrer les mêmes objets du noyau.

Les articles #60 à #62 ont présenté NetworkManager et ses clients. Cette fois, nous découvrons systemd-networkd, un autre gestionnaire, souvent retenu sur des serveurs, VM ou images dépourvus de bureau graphique. Le but est de comprendre sa logique et d'inspecter un système sans interrompre SSH.

Un service réseau et son outil d'observation

systemd-networkd est un service systemd qui configure les liens réseau qu'il prend en charge : adresses, routes et certains périphériques virtuels. Il ne configure pas nécessairement toutes les interfaces visibles sur une machine. Il gère notamment les liens correspondant à un fichier .network applicable.

networkctl est le client qui permet de consulter et, pour certaines sous-commandes, de contrôler ce gestionnaire. À l'image de nmcli pour NetworkManager, il offre une vue propre au service.

Fichiers de configuration           Administrateur
  .network / .netdev / .link           |
               |                  networkctl
               v                       |
        systemd-networkd <-------------+
               |
       Interfaces prises en charge
               |
        État courant du noyau
         ip link / ip address
               |
          Applications / SSH

Le schéma est volontairement simplifié. Les fichiers .link relèvent de la configuration des liens par udev, notamment certains noms ou paramètres bas niveau ; ils ne sont pas l'équivalent direct d'un profil .network. Et networkctl n'est pas une seconde pile réseau indépendante.

Les trois types de fichiers à distinguer

Extension	Rôle	Exemple de question
`.network`	Réglages réseau d'un lien correspondant à une section `[Match]`	Quelle adresse ou quel DHCP ?
`.netdev`	Création/configuration de périphériques virtuels	Quel bridge ou VLAN faut-il créer ?
`.link`	Paramètres de lien traités notamment par `systemd-udevd`	Quel nom ou quelle politique de lien ?

La règle importante : networkd recherche un fichier .network qui correspond à un lien. S'il n'y a aucun fichier applicable, le service peut laisser cette interface hors de sa gestion. Le simple fait que systemd-networkd.service soit actif ne prouve donc pas qu'il possède toutes les cartes.

Les fichiers peuvent venir du système, de l'administrateur ou d'un générateur. Les emplacements courants incluent /usr/lib/systemd/network/, /run/systemd/network/ et /etc/systemd/network/. Certaines installations utilisent aussi /usr/local/lib/systemd/network/.

Comment un fichier .network est choisi

Les fichiers sont traités selon des règles de nommage, de correspondance et de priorité. La section [Match] peut sélectionner une interface ; la section [Network] décrit, entre autres, l'adressage et DHCP.

Dans les cas ordinaires, le premier fichier .network correspondant dans l'ordre lexical retenu est utilisé pour un lien. Une exception importante : les fichiers de même nom dans des répertoires différents ne s'additionnent pas comme des profils indépendants ; les règles de priorité des répertoires et les drop-ins peuvent remplacer ou compléter des réglages.

Cela explique pourquoi voir 10-lan.network et 80-default.network sur le disque ne signifie pas que les deux configurent entièrement la même carte. Pour comprendre le résultat, il faut identifier le fichier effectivement associé au lien, et ne pas simplement lire le fichier au nom le plus explicite.

Exemple purement illustratif, à ne pas déposer sur un serveur :

# EXEMPLE DOCUMENTAIRE — NE PAS APPLIQUER
[Match]
Name=ens160

[Network]
DHCP=ipv4

Le nom ens160 est fictif dans votre contexte. Cette déclaration signifie qu'un lien correspondant au nom indiqué peut recevoir une configuration IPv4 via DHCP, sous réserve que ce fichier soit effectivement sélectionné et que les autres paramètres le permettent.

Lab 1 — Vérifier la présence et l'état du service

Ce laboratoire ne change aucune adresse, route ou connexion. Exécutez uniquement sur une machine que vous êtes autorisé à diagnostiquer :

command -v networkctl
systemctl is-active systemd-networkd
networkctl list
ip -br link
ip -br address

Si networkctl manque, si le service est inactif ou si systemctl n'est pas disponible dans votre environnement, n'activez pas networkd pour les besoins du laboratoire. Un autre service peut gérer le réseau ; démarrer simultanément deux gestionnaires sur la même interface est risqué.

networkctl list montre les liens connus avec, selon la version, leur type et leur état de configuration. ip -br address donne la vue des adresses au niveau du noyau. Les deux sorties ne répondent pas à la même question.

Lab 2 — Identifier la configuration d'une interface

networkctl status

Sur un système utilisant networkd, la sortie détaillée peut mentionner les liens, leurs états et le Network File retenu. La présentation et les champs dépendent de la version de systemd et des droits disponibles.

Pour viser une interface, remplacez son nom par celui relevé dans networkctl list :

# COMMANDE DE CONSULTATION : utiliser le vrai nom de l'interface
networkctl status <interface-verifiee>

Trois observations permettent d'avancer : l'interface est-elle visible, apparaît-elle comme configurée ou non gérée, et un fichier réseau lui est-il effectivement associé ?

Attention : un état routable ou configured dans networkctl ne constitue pas à lui seul un test de disponibilité applicative. Une session SSH peut dépendre de routes, pare-feu et services que cet état ne valide pas.

Lab 3 — Retrouver les fichiers sans les modifier

ls -l /etc/systemd/network/
ls -l /run/systemd/network/
ls -l /usr/lib/systemd/network/

Un dossier absent ne signifie pas automatiquement que le réseau est en panne. Des fichiers peuvent être livrés ailleurs ou générés au démarrage. Netplan, par exemple, peut générer des fichiers destinés à systemd-networkd : dans ce cas, le YAML d'origine reste souvent le point d'administration, plutôt que le fichier produit dans /run.

C'est une différence essentielle entre le fichier chargé par le service et la source persistante faisant autorité. Un fichier .network généré ne devrait pas être modifié à la main si son générateur le remplacera ensuite.

Un serveur peut également recevoir ses paramètres de cloud-init ou d'une automatisation. Si vous ne parvenez pas à expliquer qui écrit le fichier, indiquez « source non déterminée » et poursuivez l'inventaire.

Lire les états sans leur donner trop de sens

networkctl peut afficher plusieurs dimensions d'état qui se complètent : état opérationnel du lien, état de configuration du gestionnaire, et autres informations suivant les versions.

Observation	Interprétation prudente
Interface visible par `ip`	Le noyau connaît le lien dans ce namespace
Service `systemd-networkd` actif	Le service fonctionne, sans prouver la gestion de toutes les interfaces
Fichier `.network` associé	Une configuration de networkd correspond au lien
État `unmanaged`	networkd ne gère pas cette interface selon sa configuration actuelle
État `routable`	Indice d'une configuration réseau de niveau lien/IP, pas preuve d'accès à toutes les destinations

Ainsi, la commande ip route show reste utile pour connaître les routes effectivement installées, tandis que networkctl aide à comprendre ce que networkd pense administrer. Pour un diagnostic fiable, comparez les deux.

Quelle différence avec NetworkManager ?

Ces deux services peuvent gérer des adresses et des routes, mais ils n'utilisent pas le même modèle d'administration.

Question	NetworkManager	systemd-networkd
Client courant	`nmcli`, `nmtui`, parfois GUI	`networkctl`
Configuration habituelle	Profils de connexion	Fichiers `.network` et `.netdev`
Sélection	Profils disponibles et activations	Correspondance des fichiers au lien
Desktop interactif	Souvent adapté	Possible, mais ce n'est pas une interface de bureau
Serveur automatisé	Courant sur plusieurs distributions	Courant dans de nombreux déploiements sobres

Il n'existe pas de règle universelle « NetworkManager = Desktop, networkd = serveur ». Des serveurs RHEL utilisent NetworkManager ; des systèmes Debian ou Ubuntu peuvent employer l'un ou l'autre selon l'image et la configuration. Le choix se vérifie sur la machine, pas dans une présentation commerciale de la distribution.

De même, Netplan est une couche déclarative en amont quand il est utilisé : il peut choisir networkd comme renderer. Le #64 expliquera précisément cette relation.

Pourquoi on ne redémarre pas networkd pour « tester »

Le service peut préserver une partie de l'état réseau lors de son arrêt, mais son démarrage et l'application de fichiers peuvent modifier des adresses et des routes existantes sur les liens pris en charge. Un redémarrage n'est donc ni une opération d'inspection ni un moyen de déterminer sans risque quel fichier gagnera.

Les commandes suivantes sont volontairement isolées comme exemples d'opérations à ne pas exécuter dans ce tutoriel :

# NE PAS EXÉCUTER sans fenêtre de maintenance et accès console
systemctl restart systemd-networkd
networkctl reconfigure <interface>
networkctl reload

Même une modification apparemment mineure d'un .network peut supprimer une route indispensable au serveur. Sur une interface utilisée par SSH, prévoyez une console indépendante, une copie des fichiers d'origine, une méthode de restauration et des vérifications de connectivité.

Petit défi — Trouver le fichier qui compte

Sur une VM de laboratoire ou un serveur autorisé, exécutez :

systemctl is-active systemd-networkd
networkctl list
networkctl status
ip -br address
ip route show

Sans rien modifier, répondez à ces questions :

Quel est le nom de l'interface qui porte l'accès d'administration ?
Est-elle prise en charge par networkd ou non gérée ?
Un fichier .network actif est-il identifié ?
Ce fichier vient-il de /etc, /run, /usr/lib ou d'un autre chemin ?
Quelle source, éventuellement génératrice, lui donne son contenu ?

Critère de réussite : expliquer séparément ce que voit le noyau, ce que gère networkd et d'où viennent les paramètres persistants. Une provenance inconnue est une conclusion acceptable tant qu'elle est notée et vérifiée avant toute modification.

Aucun nettoyage ni rollback n'est nécessaire après ce laboratoire en lecture seule.

Limites et bonnes pratiques d'exploitation

Un environnement conteneurisé peut exposer seulement un espace de noms réseau ; networkctl n'y décrira pas forcément les interfaces du système hôte. Les configurations réseau virtuelles impliquent parfois des fichiers .netdev et .network distincts. Les informations de sortie peuvent révéler IP, topologie et détails d'infrastructure : anonymisez-les avant publication.

Enfin, le DNS et systemd-resolved constituent un autre sujet : ne présumez pas que networkd assure seul la résolution DNS. Le chapitre dédié au DNS reviendra sur la chaîne de résolution, les fichiers et les services concernés.

Références officielles

Conclusion — Savoir qui contrôle le lien

systemd-networkd est un service qui applique une configuration ; networkctl permet d'observer son état ; les fichiers .network et .netdev décrivent les comportements et les périphériques concernés. Tout commence par l'identification du fichier réellement sélectionné et de sa source.

Dans le #64, nous remonterons d'un niveau avec Netplan : pourquoi des déclarations YAML peuvent piloter networkd ou NetworkManager, et pourquoi modifier directement les fichiers générés est souvent une erreur.