Config réseau sur les distros Linux en 2026

La config réseau sur les distros Linux en 2026, c'est jongler avec quatre ou cinq piles différentes dans la tête à la fois. Il y a netplan (le front-end déclaratif d'Ubuntu), ifupdown (le vieux /etc/network/interfaces de Debian), NetworkManager (ce que livre la famille RHEL) et systemd-networkd (le léger). openSUSE Leap en ajoute une cinquième, wicked. Chacune fait le même boulot rasoir : monter une interface avec la bonne IP, la bonne passerelle et le bon DNS, et chacune attrape une abstraction complètement différente pour y arriver. Du coup j'ai comparé tout ça sur sept distros. Tu as la recette IP statique pour chacune, les migrations que j'ai réellement faites, plus un arbre de décision pour partir de zéro.

Je fais tourner Linux sur une demi-douzaine de distros. Ce qui veut dire que j'ai en permanence quatre piles réseau différentes dans la tête, et franchement ça en fait deux de trop. Il y a netplan (le front-end déclaratif d'Ubuntu), ifupdown (le vieux /etc/network/interfaces de Debian), NetworkManager (ce que livre la famille RHEL, plus pas mal de portables Arch) et systemd-networkd (le léger, celui sur lequel Arch retombe quand tu n'as rien installé d'autre). openSUSE Leap en ajoute une cinquième, wicked, histoire de me garder humble. Chacune fait exactement le même boulot rasoir : monter une interface avec la bonne IP, la bonne passerelle et le bon DNS. Et chacune attrape une abstraction complètement différente pour y arriver. Du coup je me suis posé et j'ai comparé tout ça sur les sept distros de notre Distro Reference. Tu as la recette IP statique pour chacune, plus les migrations que j'ai réellement faites, plus un arbre de décision pour quand tu pars de zéro.

Les quatre (cinq) piles, un paragraphe chacune

netplan, c'est le front-end YAML qu'Ubuntu a greffé dès la 18.04 LTS. Tu écris du YAML déclaratif dans /etc/netplan/*.yaml, et netplan le compile vers la config du backend qui fait réellement le travail, systemd-networkd ou NetworkManager. J'aime bien. La config se lit proprement et se glisse direct dans Git. D'une version d'Ubuntu à l'autre, elle bouge à peine. Ce que je n'aime pas, c'est la couche d'indirection. Quand ça casse, tu ne peux pas juste lire l'erreur. Il faut d'abord traduire ton YAML dans la vision du monde du backend, dans ta tête, avant que le moindre débogage ait du sens. C'est le défaut d'Ubuntu Server depuis la 18.04 et d'Ubuntu Desktop depuis la 22.04.

ifupdown, c'est la vieille méthode Debian, et franchement j'ai un petit faible pour elle. Tu édites /etc/network/interfaces avec des stanzas (auto eth0 / iface eth0 inet static), puis tu lances ifup eth0 ou tu relances le service networking. Conservateur. Documenté à mort. Ça ne te surprendra pas à 3 h du matin, ce qui, après assez de surprises à 3 h du matin, compte pour beaucoup. Toujours le défaut côté serveur sur Debian en 2026. Bien sûr, ça ne sait pas exprimer ce que le YAML ou les keyfiles savent faire. Mais pour une petite machine qui reste là et qui fonctionne, c'est un peu tout l'intérêt.

NetworkManager, c'est le gros démon à état issu du monde GNOME. Il garde les connexions sous forme de keyfiles dans /etc/NetworkManager/system-connections/*.nmconnection, et tu le pilotes avec nmcli en ligne de commande, nmtui si tu veux une TUI curses, ou une interface graphique. Là où il est vraiment bon, c'est sur tout le bazar entre-deux que personne d'autre ne gère bien. Le Wi-Fi qui tombe et se reconnecte. Ton VPN qui monte. Ce portail captif à l'aéroport qui prend toute ta connexion en otage tant que tu n'as pas cliqué sur « J'accepte ». C'est le défaut sur toute la famille RHEL 9 (Rocky et Alma compris), sur Fedora, et sur une pile croissante de distros qui veulent ce côté « on te tient la main » des environnements de bureau.

systemd-networkd, c'est la version épurée de l'équipe systemd. La config vit dans /etc/systemd/network/*.network, il n'y a quasiment aucun état de démon à surveiller, et le DNS est délégué à systemd-resolved. Léger. Prévisible. On le retrouve partout sur les machines Arch et les hôtes de conteneurs. Oui, il en fait moins que NetworkManager. Mais il fait ce « moins » avec beaucoup moins de choses qui peuvent mal tourner, et sur un serveur je prends ce compromis à chaque fois.

wicked, c'est le truc bien à openSUSE. La syntaxe est plus ou moins compatible avec les anciens /etc/sysconfig/network-scripts de Red Hat, mais ça fait tourner son propre démon en coulisses. Toujours le défaut d'openSUSE Leap en 2026. Tumbleweed, la sœur en rolling release, a déjà sauté du navire pour NetworkManager, et ça te dit exactement dans quelle direction tout ça va.

Les défauts par distro en 2026

Voici ce qui est réellement livré d'origine sur chaque distro de la Distro Reference, histoire de savoir dans quoi tu mets les pieds avant même de te connecter en SSH.

Deux lignes là-dedans coincent les gens, alors laisse-moi les pointer du doigt. Ubuntu Server vs Desktop : les deux te mettent netplan devant, mais ce qui est dessous diffère. Sur Server, netplan génère de la config systemd-networkd. Sur Desktop, il génère de la config NetworkManager pour que l'interface graphique continue de marcher. Le même YAML dans les deux cas. Netplan choisit juste discrètement le bon backend à l'installation et n'en parle jamais. Arch en installation minimale : l'image de base ne te donne rien pour le routage. Point final. Tu en choisis un toi-même. systemd-networkd arrive avec le paquet systemd, déjà là mais désactivé, donc c'est le chemin de moindre résistance. Ou bien networkmanager, ou dhcpcd, ou connman. Sur un serveur je prends systemd-networkd. Sur un portable je prends NetworkManager sans réfléchir une seconde.

La recette IP statique par pile

Voici exactement la même corvée, fixer eth0 à 192.168.1.10/24, passerelle 192.168.1.1, DNS 1.1.1.1, écrite de cinq façons différentes. Le même objectif. Des quantités de cérémonie radicalement différentes pour y arriver.

netplan

# /etc/netplan/01-static.yaml
network:
  version: 2
  ethernets:
    eth0:
      addresses: [192.168.1.10/24]
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]

# Apply (use 'try' first on a remote box - it rolls back in 120s if SSH dies)
sudo netplan try
sudo netplan apply

ifupdown (Debian / Alpine)

# /etc/network/interfaces
auto eth0
iface eth0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    dns-nameservers 1.1.1.1 8.8.8.8

# Apply
sudo systemctl restart networking
# (Alpine: sudo rc-service networking restart)

NetworkManager (nmcli)

sudo nmcli con add type ethernet con-name eth0-static ifname eth0 \
  ip4 192.168.1.10/24 gw4 192.168.1.1
sudo nmcli con mod eth0-static ipv4.dns "1.1.1.1 8.8.8.8"
sudo nmcli con mod eth0-static ipv4.method manual
sudo nmcli con up eth0-static

# Or interactive TUI
sudo nmtui

systemd-networkd

# /etc/systemd/network/10-eth0.network
[Match]
Name=eth0

[Network]
Address=192.168.1.10/24
Gateway=192.168.1.1
DNS=1.1.1.1
DNS=8.8.8.8

# Enable
sudo systemctl enable --now systemd-networkd
sudo systemctl restart systemd-networkd

wicked (openSUSE Leap)

# /etc/sysconfig/network/ifcfg-eth0
BOOTPROTO='static'
IPADDR='192.168.1.10/24'
STARTMODE='auto'

# /etc/sysconfig/network/routes
default 192.168.1.1 - -

# /etc/sysconfig/network/config (DNS)
NETCONFIG_DNS_STATIC_SERVERS="1.1.1.1 8.8.8.8"

# Apply
sudo wicked ifreload eth0
sudo netconfig update -f

Résolveur DNS : resolvconf, systemd-resolved, la voie manuelle

Le DNS, c'est là où tout ce truc cross-distro s'effondre, et là où j'ai cramé le plus d'heures de très loin. Trois approches cohabitent, et elles ne s'entendent pas toujours bien :

• /etc/resolv.conf manuel : juste une liste plate de serveurs de noms, un par ligne. Tout simple, rien de malin là-dedans. Le piège qui attrape tout le monde, par contre : plein de piles écrasent ce fichier à chaque redémarrage réseau, donc ta belle édition disparaît.
• systemd-resolved : un résolveur stub posé sur 127.0.0.53 qui transmet à tes vrais serveurs amont et met les réponses en cache. /etc/resolv.conf devient un lien symbolique vers /run/systemd/resolve/stub-resolv.conf. C'est le défaut sur Ubuntu, et sur Arch quand tu fais tourner networkd, et ça continue de se répandre.
• Géré par NetworkManager : NM écrit lui-même /etc/resolv.conf, directement à partir du ipv4.dns de la connexion. Et quand NM et systemd-resolved sont tous les deux dans la partie, c'est NM qui dit à resolved quels serveurs utiliser, le genre de détail que tu n'apprends qu'une fois qu'il t'a mordu.

Quand j'atterris sur une machine que je ne connais pas, ces trois lignes me disent à laquelle de ces approches j'ai vraiment affaire :

resolvectl status 2>/dev/null   # systemd-resolved is active if this returns
ls -la /etc/resolv.conf         # symlink target tells you the manager
cat /etc/resolv.conf            # what is actually being used

Piège DNS classique : éditer /etc/resolv.conf à la main pendant que systemd-resolved tourne. Je l'ai fait. J'aurais juré que le changement était sauvegardé. Puis je l'ai vu disparaître au tout prochain événement réseau, ce qui est un genre d'agacement très particulier en fin de longue journée. Soit tu coupes systemd-resolved, soit tu règles le DNS via la pile elle-même (nameservers de netplan, ipv4.dns de nmcli, ce genre de chose).

Schémas de migration

De l'ifupdown Debian vers netplan

Tu fais passer une machine de Debian 12 à Ubuntu 24.04 ? Ne t'attends pas à ce que ta config ifupdown fasse le voyage avec elle. Netplan ne lit pas du tout /etc/network/interfaces, donc tu réécris le truc de zéro. Voici la comparaison côte à côte :

# ifupdown
auto eth0
iface eth0 inet static
    address 10.0.0.5/24
    gateway 10.0.0.1
    dns-nameservers 1.1.1.1

# Equivalent netplan
network:
  version: 2
  ethernets:
    eth0:
      addresses: [10.0.0.5/24]
      routes:
        - to: default
          via: 10.0.0.1
      nameservers:
        addresses: [1.1.1.1]

Des network-scripts RHEL 7/8 vers le nmcli de RHEL 9

RHEL 9 a tiré le tapis sous /etc/sysconfig/network-scripts. Ce n'est plus la source de vérité. Tes vieux fichiers ifcfg-* se laisseront encore parser si tu installes NetworkManager-initscripts-ifcfg-rh, mais c'est une béquille, pas une maison. La vraie maison désormais, ce sont les keyfiles de NetworkManager. Voici comment ça se transpose :

# Legacy /etc/sysconfig/network-scripts/ifcfg-eth0 (RHEL 7/8)
TYPE=Ethernet
BOOTPROTO=none
DEVICE=eth0
ONBOOT=yes
IPADDR=10.0.0.5
PREFIX=24
GATEWAY=10.0.0.1
DNS1=1.1.1.1

# Equivalent on RHEL 9 (via nmcli)
sudo nmcli con add type ethernet con-name eth0 ifname eth0 \
  ip4 10.0.0.5/24 gw4 10.0.0.1
sudo nmcli con mod eth0 ipv4.dns 1.1.1.1 ipv4.method manual
sudo nmcli con up eth0

Tu fais ça sur tout un parc ? Ne reste pas là à balancer des milliers de nmcli con add à la main, tu vas loucher. Génère les keyfiles hors ligne, utilise nmcli con import type keyfile, puis rsync-les en place. Bien plus propre, et tu peux relire le diff avant que quoi que ce soit s'approche d'une carte réseau de production.

De wicked (openSUSE Leap) vers NetworkManager (openSUSE Tumbleweed ou la prochaine Leap majeure)

Si tu fais tourner openSUSE, c'est la migration qui t'attend dans les 12 à 18 prochains mois. SUSE a déjà dit tout haut ce qui se murmurait : NetworkManager devient le défaut de Leap à terme. Tes fichiers wicked /etc/sysconfig/network/ifcfg-* ne se chargeront pas tels quels sous NetworkManager. Mais ne stresse pas. La conversion est mécanique, et tu peux scripter tout ça :

# wicked /etc/sysconfig/network/ifcfg-eth0
BOOTPROTO='static'
IPADDR='10.0.0.5/24'
STARTMODE='auto'

# NetworkManager equivalent
sudo nmcli con add type ethernet con-name eth0 ifname eth0 \
  ip4 10.0.0.5/24 gw4 10.0.0.1
sudo nmcli con up eth0

Arbre de décision : quelle pile pour quel scénario

Sur une nouvelle installation, neuf fois sur dix le défaut de la distro tranche pour toi, et c'est très bien. Mais quand tu as réellement le choix, voici comment je décide :

• Serveur, une IP statique, pas de Wi-Fi, jamais déplacé vers systemd-networkd ou netplan. Le moins de pièces mobiles, parfaitement prévisible. Et ça vit heureux dans Git en config-as-code.
• Serveur avec du routage tordu, un VPN, une pile de network namespaces vers NetworkManager. Le démon gère toutes ces transitions sans drame, et le scripting nmcli a franchement bien mûri.
• Bureau ou portable qui jongle entre Wi-Fi, VPN, un réseau différent chaque jour vers NetworkManager, sans hésiter. Rien d'autre ne s'en approche sur les bascules.
• Hôte de conteneurs où les pods reçoivent des paires veth et des namespaces vers systemd-networkd. Empreinte minuscule, et il s'écarte du chemin de cri-o, containerd, docker, tous.
• Machine Debian bare-metal avec une IP statique qui ne changera jamais vers ifupdown. Rasoir et sans démon, avec toute la config posée là dans /etc à l'instant où tu en as besoin.
• Automatisation multi-distros avec Ansible ou Salt vers netplan sur Ubuntu, keyfiles NetworkManager partout ailleurs. Les deux se rendent proprement en templates. Les stanzas d'ifupdown, franchement, sont pénibles à templater.

Les pièges communs à toutes les piles

• Nommage des interfaces : de nos jours ta carte réseau s'appelle sans doute enp3s0 ou ens18, pas eth0. Ta config doit correspondre à ce que ip link affiche réellement. Copie eth0 direct depuis un tuto au hasard et il se peut qu'il n'existe même pas sur ta machine. Si tu veux vraiment retrouver le bon vieux eth0, le paramètre noyau net.ifnames=0 fait l'affaire.
• IPv6 activé par défaut : toute distro moderne active IPv6 d'entrée. Si ton réseau ne fait pas réellement du v6, tu peux te retrouver à plisser les yeux devant des connexions poussives pendant que les requêtes AAAA expirent en arrière-plan. Soit tu donnes à la machine une vraie connectivité v6, soit tu coupes le v6 volontairement dans la config de la pile. Choisis.
• Le DNS meurt mais le ping marche : le casse-tête classique de systemd-resolved. ping 1.1.1.1 passe sans souci, ping google.com reste juste pendu là. Quand ça arrive, va direct à resolvectl status et regarde ce que le stub fabrique vraiment.
• Verrouillé hors du SSH après un redémarrage : celui-là je l'ai appris à la dure, et j'aimerais autant t'épargner ça. Pousse des changements réseau sur une machine distante sans filet et tu peux te barricader complètement dehors, aucun retour possible à part une console. netplan try annule tout en 120 secondes. nmcli applique à chaud, sans aucun redémarrage. Pour ifupdown, lance un sleep 60 && systemctl restart networking dans une session tmux, comme ça si tu perds le lien tu peux te reconnecter et le tuer avant que le redémarrage tombe.
• Connexions épinglées à une MAC : certaines piles lient un profil à une adresse MAC bien précise. Clone une VM ou change une carte réseau et le profil refuse net de s'attacher à la nouvelle interface, sans avertissement, ça ne monte juste pas. Pars à la chasse au match-device-id ou au HWADDR= dans la config et soit tu corriges le lien, soit tu l'arraches complètement.

Sources et pour aller plus loin

• Netplan, reference
• man7.org, systemd.network(5)

Questions fréquentes