Cours accéléré NetworkManager : nmcli et keyfiles pour serveurs RHEL

Ce qu'est NetworkManager, et si vous l'utilisez

NetworkManager est le daemon qui décide de ce que font vos interfaces réseau : quelles adresses elles portent, par quelle passerelle elles routent, quels serveurs DNS elles interrogent. Sur la famille RHEL (RHEL et ses recompilations communautaires AlmaLinux et Rocky), c'est la pile par défaut, et depuis l'abandon du paquet network-scripts, c'est la seule pile réseau que Red Hat prend en charge. Si vous êtes sur RHEL 8, 9 ou 10 ou l'une de leurs recompilations, NetworkManager tourne déjà et détient déjà votre configuration, que vous y ayez touché ou non.

Ce cours accéléré vise une seule configuration : un serveur dédié avec une adresse IPv4 publique statique, éventuellement un bloc IPv6 routé, sans Wi-Fi, accessible uniquement par SSH. Ce n'est pas le cas du portable que supposent la plupart des tutoriels NetworkManager, donc nous commençons par l'adressage statique et l'outil en ligne de commande, nmcli, et reléguons les éléments graphiques au rang de note. À la fin, vous aurez un profil statique IPv4 et IPv6 à copier et adapter, une idée claire de l'endroit où vit la configuration, et assez du modèle pour déboguer un changement qui ne prend pas. Les commandes nmcli présentées ici sont stables d'une version à l'autre, donc la version exacte compte rarement pour la suite ; au moment de la rédaction, la branche stable actuelle est NetworkManager 1.56 (février 2026). Consultez les notes de version pour savoir ce que livre votre distribution.

Un fil conducteur traverse tout le reste : sur une machine distante, une erreur réseau vous enferme dehors. La conception de NetworkManager vous laisse une marge de sécurité, et l'accès console hors bande (IPMI, iKVM ou la console série d'un hébergeur) sert de filet quand cette marge ne suffit pas. Les deux reviennent aux endroits où ils comptent.

Hypothèses pour les exemples :

• Une seule interface Ethernet, enp1s0. La vôtre peut s'appeler eno1, ens3 ou quelque chose d'approchant ; nmcli device status affiche le vrai nom.
• Un accès root par SSH, ou un utilisateur avec sudo.
• Des adresses tirées des plages de documentation des RFC 5737 et RFC 3849, donc rien ici n'est routé. Remplacez-les partout par vos propres valeurs.

Périphériques, profils et les deux états

L'essentiel de la confusion autour de nmcli vient de deux distinctions manquées. Une fois qu'elles sont acquises, les commandes cessent de paraître arbitraires.

La première oppose le périphérique au profil de connexion. Un périphérique, c'est le matériel : enp1s0, la carte réseau physique. Un profil de connexion est un ensemble de paramètres enregistré qu'on peut appliquer à un périphérique : une adresse, une passerelle, des DNS et une longue liste d'autres propriétés. La relation va de un à plusieurs. Un même périphérique peut avoir plusieurs profils enregistrés (un statique, un en DHCP, un pour un VLAN de maintenance), et un seul est actif à la fois. Quand vous lancez nmcli con up, vous choisissez quel profil enregistré le périphérique doit porter à cet instant. « Configurer le réseau » se fait donc en deux étapes dans NetworkManager : modifier un profil, puis l'activer.

La seconde oppose l'état enregistré à l'état en cours. Modifier un profil avec nmcli con mod écrit sur le disque. L'interface active n'est pas touchée. Elle garde ce qu'elle a reçu lors de la dernière activation de son profil actuel, jusqu'à la prochaine activation. Cet écart n'est pas une bizarrerie à contourner ; c'est le mécanisme de sécurité. Vous pouvez réécrire l'adresse, la passerelle ou une route du profil qui porte votre session SSH, relire exactement ce que vous avez changé, et seulement ensuite valider en réactivant. Rien de ce que vous avez tapé n'atteint le réseau avant ce moment.

Avec ces deux idées en tête, le déroulement devient lisible. Choisissez ou créez un profil. Modifiez ses propriétés : c'est enregistré mais sans effet. Activez-le : c'est en production. Tout le reste n'est qu'une question de propriétés et d'options.

Où vit la configuration, et l'historique ifcfg

Les profils enregistrés sont des keyfiles : de petits fichiers au format INI sous /etc/NetworkManager/system-connections/, un par profil, chacun nommé <profile>.nmconnection. Ils peuvent contenir des secrets comme une PSK Wi-Fi ou des identifiants 802.1X, c'est pourquoi NetworkManager refuse de lire tout fichier qui n'appartient pas à root avec la permission 0600. Un profil créé avec nmcli reçoit ces permissions d'office ; un fichier déposé à la main a besoin de chown root:root et chmod 600, sinon le daemon l'ignore.

Si vous administrez RHEL depuis quelques années, vous avez en mémoire un autre emplacement : /etc/sysconfig/network-scripts/ifcfg-*. L'abandon de ces fichiers s'est fait par étapes, et l'étape où se trouve votre serveur change ce que vous y trouverez.

• RHEL 8 a déclaré obsolète l'ancien service network-scripts. NetworkManager est devenu la pile par défaut et ifup/ifdown ont été recâblés pour l'appeler, mais le format par défaut sur disque restait l'ancien : les nouveaux profils étaient écrits en fichiers ifcfg-*.
• RHEL 9 a inversé ce choix par défaut. Les nouveaux profils sont écrits en keyfiles sous system-connections/. Les fichiers ifcfg-* existants sont encore lus via un plugin de compatibilité, donc une machine mise à niveau continue de fonctionner, mais le format a été officiellement déclaré obsolète et nmcli connection migrate a été ajouté pour convertir les profils.
• RHEL 10, sorti en mai 2025, a achevé le travail. Le plugin ifcfg a disparu, NetworkManager ignore tout ce qui se trouve dans /etc/sysconfig/network-scripts/, et il ne reste aucune conversion sur place sur la machine. Les keyfiles sont le seul format qu'il lit.

En pratique : à partir de RHEL 9, considérez system-connections/*.nmconnection comme la référence. Un piège quand vous éditez ces fichiers directement : NetworkManager ne surveille pas le répertoire. Après une édition à la main, lancez nmcli con reload pour relire tous les profils, ou nmcli con load <path> pour un seul fichier, puis activez. Sans ce rechargement, le daemon travaille toujours sur la copie qu'il a lue en dernier.

Une configuration statique complète

Voici un profil statique complet pour enp1s0 : une adresse IPv4 et sa passerelle, deux serveurs DNS, une adresse IPv6 statique et sa passerelle, et l'autoconnect activé pour que le profil revienne après un redémarrage. Changez les valeurs et lancez le tout en une seule commande :

nmcli con add type ethernet con-name static-enp1s0 ifname enp1s0 \
  ipv4.method manual \
  ipv4.addresses 203.0.113.10/24 \
  ipv4.gateway 203.0.113.1 \
  ipv4.dns "1.1.1.1,9.9.9.9" \
  ipv6.method manual \
  ipv6.addresses 2001:db8:2:a::10/64 \
  ipv6.gateway 2001:db8:2:a::1 \
  ipv6.dns "2606:4700:4700::1111" \
  connection.autoconnect yes

C'est ipv4.method manual qui rend le profil statique ; l'équivalent DHCP est auto. Les adresses s'écrivent en notation CIDR. ipv4.dns accepte une liste séparée par des virgules. La moitié IPv6 reprend la moitié IPv4 propriété par propriété, donc un serveur double pile tient en une commande au lieu de deux profils. connection.autoconnect yes est déjà la valeur par défaut, mais l'écrire ne coûte rien et vous protège d'un profil qui fonctionne jusqu'au premier redémarrage, puis plus du tout.

con add crée et enregistre le profil. Sur la plupart des serveurs livrés, l'interface a déjà un profil actif (souvent un profil DHCP issu de l'installation), donc rien ne change encore sur le réseau. Relisez-le avant de valider :

root@server01:~# nmcli -f ipv4.addresses,ipv4.gateway,ipv6.addresses con show static-enp1s0
ipv4.addresses:                         203.0.113.10/24
ipv4.gateway:                           203.0.113.1
ipv6.addresses:                         2001:db8:2:a::10/64

Quand la relecture correspond à ce que vous vouliez, activez-le :

root@server01:~# nmcli con up static-enp1s0

C'est la ligne dangereuse, et le seul endroit où ralentir. Activer ce profil désactive celui qui portait votre session. Si la passerelle est fausse ou si l'adresse entre en conflit, SSH tombe et ne revient pas, parce que le lien par lequel vous corrigeriez le problème est justement celui que vous venez de casser. Deux habitudes évitent l'accident : vérifier les valeurs en les relisant d'abord, et garder la console IPMI ou série du serveur ouverte dans une autre fenêtre avant d'appuyer sur Entrée. NetworkManager n'annulera pas pour vous un nmcli con up lancé seul ; la console est votre retour arrière.

Pour changer une propriété plus tard, modifiez puis réactivez :

root@server01:~# nmcli con mod static-enp1s0 ipv4.dns "9.9.9.9"
root@server01:~# nmcli con up static-enp1s0

La ligne con mod enregistre sans rien appliquer. C'est la ligne con up qui met le changement sur le réseau.

Lire ce que sait NetworkManager

Quatre commandes répondent à presque toutes les questions du type « que se passe-t-il ».

nmcli device status est la première chose à lancer sur n'importe quel serveur. Une ligne par interface : son type, si NetworkManager la gère, et quel profil est actif.

root@server01:~# nmcli device status
DEVICE   TYPE      STATE                   CONNECTION
enp1s0   ethernet  connected               static-enp1s0
lo       loopback  connected (externally)  --

nmcli con show liste les profils enregistrés, actifs ou non. Ajoutez un nom pour afficher toutes les propriétés d'un profil, ce qui permet de voir ce qu'il fera avant de l'activer :

root@server01:~# nmcli con show
NAME            UUID                                  TYPE      DEVICE
static-enp1s0   6d2c8f5a-1e3b-4a7d-9c11-2f0a7b3e5d84  ethernet  enp1s0

L'option -f sélectionne des champs pour vous éviter de faire défiler deux cents lignes, et -g (get) affiche une seule valeur sans en-tête, ce qu'il vous faut dans un script :

root@server01:~# nmcli -g ipv4.addresses con show static-enp1s0
203.0.113.10/24

La sortie ci-dessus est donnée à titre d'illustration ; les UUID et l'espacement exact des colonnes varient selon la version et la machine.

nmtui, un formulaire au lieu d'options

Si vous préférez remplir un formulaire plutôt que retenir des noms de propriétés, nmtui est l'interface curses du même moteur. Lancez-le par SSH ou sur la console et vous avez trois choix : modifier une connexion, activer une connexion, définir le nom d'hôte du système. L'éditeur de connexion expose l'adressage IPv4 et IPv6, les DNS et les champs pour les bonds, les bridges et les VLAN, donc une configuration statique se fait sans toucher à nmcli. Entrez directement avec nmtui edit enp1s0 ou nmtui connect.

Il a ses limites. nmtui ne se scripte pas et n'expose pas toutes les propriétés : les règles de routage, les scripts dispatcher et les réglages plus obscurs demandent encore nmcli ou une édition du keyfile. Mais quand vous avez perdu le réseau et que vous êtes devant une console, il vous guide pour le rétablir, et c'est là qu'il sert.

Aide-mémoire nmcli

Les commandes que vous utiliserez le plus, avec static-enp1s0 à la place du nom de votre profil :

Qui utilise NetworkManager par défaut

La pile que vous obtenez découle surtout de la distribution installée, une décision distincte de celle-ci (traitée dans notre guide pour choisir une distribution Linux). La répartition en 2026 :

La ligne Debian serveur piège souvent. Installez network-manager sur un serveur Debian qui utilise déjà ifupdown et il ne reprend pas les interfaces existantes ; tout ce qui est déclaré dans /etc/network/interfaces reste avec son ancien moteur et apparaît comme unmanaged dans nmcli. C'est voulu, et c'est le comportement par défaut le plus sûr.

VLAN, bonds et bridges

Trois schémas courants sur serveur vont au-delà d'une simple adresse à plat. Chacun correspond à un type de profil, et la syntaxe ressemble à celle de l'exemple statique.

Un VLAN place le trafic étiqueté sur une interface virtuelle posée sur une interface physique. Ceci ajoute le VLAN 40 sur enp1s0 avec sa propre adresse :

nmcli con add type vlan con-name vlan40 ifname enp1s0.40 dev enp1s0 id 40 \
  ipv4.method manual ipv4.addresses 198.51.100.10/24

L'interface parente enp1s0 continue de transporter le trafic non étiqueté. Le port du switch doit être un trunk qui laisse passer le VLAN 40, sinon les trames étiquetées ne vont nulle part.

Un bond agrège deux cartes réseau en un seul lien logique. LACP (mode 802.3ad) est le choix habituel sur serveur, pour le débit et la bascule en cas de panne d'un lien :

nmcli con add type bond con-name bond0 ifname bond0 \
  bond.options "mode=802.3ad,miimon=100,lacp_rate=fast,xmit_hash_policy=layer3+4"
nmcli con add type ethernet con-name bond0-p1 ifname eno1 master bond0 slave-type bond
nmcli con add type ethernet con-name bond0-p2 ifname eno2 master bond0 slave-type bond

LACP se négocie entre les deux côtés. Le switch doit avoir un groupe d'agrégation correspondant sur ces deux ports, sinon le bond reste inactif. Mettez l'adressage sur bond0, jamais sur les ports membres.

Un bridge transforme l'hôte en switch virtuel, ce dont un hyperviseur KVM a besoin pour que ses invités accèdent directement au réseau. L'IP de l'hôte passe sur le bridge, et la carte physique devient un port sans adresse propre :

nmcli con add type bridge con-name br0 ifname br0 \
  ipv4.method manual ipv4.addresses 203.0.113.10/24 ipv4.gateway 203.0.113.1 ipv4.dns 1.1.1.1
nmcli con add type ethernet con-name br0-port ifname enp1s0 master br0 slave-type bridge

Déplacer l'adresse de l'hôte sur un bridge par SSH comporte le même risque de blocage que toute réactivation, en plus aigu, puisque vous restructurez l'interface qui porte la session. Montez-le depuis la console, ou via une deuxième carte réseau par laquelle vous n'êtes pas connecté. C'est le même bridge que Proxmox crée sous le nom vmbr0 ; ici, vous le construisez à la main.

Dépannage

• Un périphérique apparaît unmanaged. NetworkManager a reçu l'instruction de l'ignorer. Cherchez dans /etc/NetworkManager/NetworkManager.conf et /etc/NetworkManager/conf.d/*.conf une ligne managed=false ou une section [device-*] avec managed=0. Sur Debian, les interfaces définies dans /etc/network/interfaces apparaissent non gérées par conception. Pour rendre un périphérique à NetworkManager le temps de la session, nmcli device set enp1s0 managed yes ; pour que ce soit durable, supprimez la configuration qui l'excluait.
• Une modification ne s'est pas appliquée. C'est presque toujours l'une de deux choses : vous avez lancé con mod sans jamais lancer con up, donc la modification est enregistrée et sans effet, ou vous avez édité un keyfile à la main sans lancer nmcli con reload, donc le daemon utilise encore l'ancienne copie. Aucune des deux n'échoue bruyamment. Les deux disparaissent dès que vous activez.
• L'enregistré et l'actif divergent. ip addr et ip route montrent ce que fait le noyau à cette seconde ; nmcli -f all con show <name> montre ce que fera le profil à sa prochaine activation. Quand l'adresse sur le réseau ne correspond pas au profil, c'est une activation en attente, pas un bug.
• Rien de tout cela ne l'explique. Lisez le journal du daemon : journalctl -u NetworkManager -b pour ce démarrage, ou -f pour le suivre en direct dans une fenêtre pendant que vous lancez con up dans une autre. NetworkManager détaille volontiers pourquoi une activation a échoué, et la raison se trouve en général dans les dernières lignes.

nmstate, la couche déclarative

Pour les parcs de machines, et pour qui préfère décrire l'état final plutôt qu'enchaîner des étapes, Red Hat fournit nmstate et sa commande nmstatectl. Vous décrivez en YAML le réseau voulu, lancez nmstatectl apply, et nmstate pilote NetworkManager (son seul backend) pour y parvenir. Ce qui le rend intéressant sur un serveur distant, c'est le retour arrière : appliquez un état qui coupe la connectivité et nmstate revient seul à l'état précédent, ce que ne fait pas un nmcli con up lancé seul. Il est disponible sur RHEL 8, 9 et 10, et c'est lui qu'utilise en dessous le rôle système RHEL dédié au réseau. Pour une machine isolée, nmcli suffit. Quand la même configuration doit arriver à l'identique et sans risque sur cinquante serveurs, nmstate est la couche conçue pour cela.

Ubuntu Server utilise Netplan, pas NetworkManager

Si vous gérez aussi des serveurs Ubuntu, rien de ce qui précède sur nmcli ne s'y applique par défaut. Ubuntu Server fournit Netplan, qui écrit pour systemd-networkd et se configure dans /etc/netplan/*.yaml, sans NetworkManager dans le circuit. Ubuntu Desktop utilise aussi Netplan, mais avec NetworkManager comme moteur de rendu, donc nmcli y fonctionne. Les concepts se transposent (configuration déclarée, étape d'activation, séparation entre enregistré et actif), mais l'outil et les fichiers diffèrent. Le cours accéléré Netplan est le pendant de ce guide pour cette partie du parc.

Déployer sur Serverside.com

Un profil NetworkManager ne vaut que par le réseau vers lequel il pointe. Serverside.com exploite son propre réseau (AS55285), donc un serveur RHEL, AlmaLinux ou Rocky est livré en moins d'une minute, et les IPv4 et IPv6 publiques que vous configurez sont protégées par une mitigation DDoS permanente dès le premier démarrage. La gamme dédiée RHEL livre la famille RHEL prête pour la méthode nmcli décrite ici, et l'ensemble de la gamme de serveurs dédiés couvre le reste.

À lire aussi : la comparaison des abonnements AlmaLinux et RHEL si vous hésitez entre une licence et une recompilation gratuite, et la checklist de durcissement d'un serveur Linux à dérouler une fois l'interface active et joignable.

FAQ

Pourquoi mon changement d'IP n'a-t-il pas survécu à un redémarrage ?

Trois causes habituelles. L'autoconnect du profil est désactivé, donc rien ne l'active au démarrage : définissez connection.autoconnect yes. Vous avez modifié le profil avec nmcli con mod sans jamais lancer nmcli con up, donc la modification a été enregistrée mais jamais appliquée. Ou vous avez édité le keyfile à la main sans lancer nmcli con reload, et NetworkManager a continué d'utiliser la copie lue au démarrage. Activer le profil après la modification règle les trois cas.

Faut-il éditer les fichiers .nmconnection à la main ou passer par nmcli ?

Les deux fonctionnent, et le keyfile fait foi dans les deux cas. nmcli vérifie les valeurs que vous lui donnez et recharge le profil pour vous, c'est donc le choix le plus sûr par défaut. Si vous éditez le fichier directement, laissez-le appartenir à root avec la permission 600, puis lancez nmcli con reload pour que le daemon prenne la modification en compte. NetworkManager ne surveille pas le répertoire de lui-même.

Comment empêcher NetworkManager de gérer une interface ?

Pour la session en cours, lancez nmcli device set enp1s0 managed no. Pour que cela persiste après un redémarrage, ajoutez une section [device-*] avec managed=0 dans un fichier sous /etc/NetworkManager/conf.d/. C'est courant quand un autre outil gère une carte réseau précise, ou sur Debian, où les interfaces définies dans /etc/network/interfaces restent non gérées à dessein.

Ai-je encore des fichiers ifcfg sur RHEL ?

Cela dépend de la version. RHEL 8 écrivait encore des fichiers ifcfg par défaut. RHEL 9 lit ceux qui existent mais écrit les nouveaux profils en keyfiles et déclare le format ifcfg obsolète. RHEL 10, sorti en mai 2025, a entièrement supprimé le plugin ifcfg et ignore ces fichiers. Sur RHEL 9 et 10, ce sont les keyfiles sous /etc/NetworkManager/system-connections qui comptent.

NetworkManager ou systemd-networkd pour un serveur ?

Sur la famille RHEL, la décision est déjà prise : NetworkManager est la pile par défaut et la seule prise en charge, et il gère sans difficulté l'adressage statique d'un serveur. Ubuntu Server fait l'inverse et utilise systemd-networkd via Netplan. Les deux tiennent la production. Utilisez celle que fournit votre distribution au lieu de la remplacer.