Debian 13 : un nouveau nom d’interface a cassé le réseau — des noms stables qui survivent aux redémarrages (cas n°7)

janvier 7, 2026 • février 3, 2026 • Lecture : 30 min • Views: 2

Cet article vous a aidé ?

Il est 02:13. Vous redémarrez une machine Debian 13 après une mise à jour du noyau de routine. Elle revient—en partie. SSH est mort, la supervision passe au rouge, et la console affiche une LED de lien parfaitement saine sur la carte réseau qui apparemment « n’existe pas ».

Rien n’est plus humiliant que de perdre un hôte parce que la carte réseau a décidé qu’elle voulait un nouveau surnom. Ce cas porte sur la récupération de cet hôte, puis sur la garantie que cela ne se reproduira jamais — même après des redémarrages, des mises à jour du noyau, des échanges de NIC, des réarrangements PCIe ou la mauvaise mémoire de votre futur vous.

Ce qui a réellement cassé : le nom a changé, pas le réseau

Quand le « réseau a cassé » après un redémarrage sur Debian 13, la réalité la plus courante est ennuyeuse : la NIC fonctionne toujours, le lien est up, le pilote est chargé, DHCP est OK… mais votre configuration pointe vers eth0 et le noyau l’appelle désormais enp2s0 (ou enp5s0f1, ou ens192, ou quelque chose d’aussi peu romantique).

Cette divergence suffit à :

Empêcher ifupdown de monter l’interface parce que « device not found ».
Casser une configuration IP statique dans /etc/network/interfaces.
Casser les connexions NetworkManager liées à un nom d’interface.
Casser les bonds et bridges qui référencent les interfaces membres par nom.
Casser les sous-interfaces VLAN (ex. bond0.123 ou enp2s0.10).
Embrouiller la supervision et les règles de pare-feu si elles sont indexées sur les noms d’interface.

Les noms d’interface sont des identifiants dans les configs. Si l’identifiant change, votre config devient un poème sur une NIC qui était là autrefois.

Voici l’idée principale : vous ne « réparez pas le réseau » en modifiant au hasard toutes les configs pour coller au nouveau nom. Vous réparez la politique de nommage afin que les noms restent stables, puis vous faites dépendre vos configs de cette politique.

Méthode de diagnostic rapide (vérifier 1er/2e/3e)

Premier point : le noyau voit-il la NIC et le lien est-il actif ?

Vérifier : ip -br link et dmesg pour l’attachement du pilote.
Si la NIC est totalement absente, vous dépannez du matériel/driver/firmware, pas du nommage.
Si elle est présente mais non configurée, un décalage de nommage est probable.

Deuxième point : le nom d’interface a-t-il changé et la config référence-t-elle l’ancien ?

Comparer : ip -br addr vs /etc/network/interfaces ou profils NetworkManager.
Rechercher : « Cannot find device » ou « unknown interface » dans les logs.

Troisième point : qu’est-ce qui définit le nom (systemd/udev, BIOS/firmware, hyperviseur) ?

Vérifier : udevadm test-builtin net_id et networkctl status.
Décider de : pin via .link, matcher par MAC, par chemin PCI, ou désactiver le nommage prédictible.

Si vous suivez cet ordre, vous évitez le mode d’échec classique : passer une heure à « réparer le DHCP » alors que le nom de la NIC a simplement dérivé.

Faits intéressants & historique : pourquoi Linux nomme les NIC ainsi

eth0 n’a pas toujours été stable non plus. Les anciens noms dépendaient de l’ordre de détection ; ajouter une NIC pouvait permuter eth0/eth1 d’un boot à l’autre.
Les noms prédictibles sont devenus courants autour de systemd v197. L’objectif : des noms stables basés sur la topologie matérielle plutôt que l’ordre de découverte.
Les motifs courants codent en fait la localisation. enp2s0 signifie grosso modo « Ethernet, bus PCI 2, emplacement 0 ». Utile — jusqu’à ce que le firmware change la numérotation.
Il existe plusieurs « schémas » de nommage. systemd peut utiliser l’index embarqué, l’index de slot, le chemin, le MAC, ou un mix selon ce que la plateforme expose.
Les hyperviseurs adorent intervenir. Dans les VM, votre « topologie matérielle » peut changer après une migration, un changement de NIC virtuelle ou une autre présentation de bus virtuel.
Les règles udev étaient autrefois l’approche principale. Beaucoup de guides anciens montrent des règles udev personnalisées ; les fichiers .link systemd sont maintenant le mécanisme propre et supporté.
Les adresses MAC sont stables jusqu’à ce qu’elles ne le soient plus. Certaines plateformes virtuelles génèrent de nouveaux MAC lors d’un clone, ou des admins « changent vite fait » et oublient.
Les renommages peuvent être déclenchés par des changements d’initramfs. Si l’initramfs contient des règles ou pilotes différents, la décision de nommage peut survenir plus tôt ou différemment.

Une idée paraphrasée d’une voix fiabilité à garder sur un post-it : apprendre des incidents rend les systèmes plus robustes — John Allspaw, sur la fiabilité opérationnelle et l’apprentissage à partir des incidents.

Tâches pratiques : commandes, ce que signifie la sortie, et la décision que vous prenez

Vous n’avez pas besoin d’une centaine de commandes. Vous avez besoin de la bonne douzaine, utilisée dans le bon ordre, avec une décision attachée à chacune. Voici seize commandes qui rapportent constamment leur salaire.

Task 1: Lister rapidement les interfaces (et repérer les renommages)

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp2s0           DOWN           3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST>
enp3s0           UP             3c:fd:fe:dd:ee:ff <BROADCAST,MULTICAST,UP,LOWER_UP>

Ce que ça signifie : Vous avez enp2s0 et enp3s0, pas eth0. L’une est UP, l’autre est DOWN.

Décision : Si les configs réfèrent à eth0, vous êtes en territoire de mismatch de nommage. Identifiez quelle interface doit porter l’IP de service.

Task 2: Confirmer adresses et application de DHCP/statique

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
enp2s0           DOWN
enp3s0           UP             192.0.2.10/24 fe80::3efd:feff:fedd:eeff/64

Ce que ça signifie : enp3s0 a une IPv4 ; enp2s0 n’en a pas. Le service appartient probablement à enp3s0.

Décision : Si l’IP attendue n’est nulle part, l’interface peut être up mais non configurée à cause d’un nom mismatch, d’un échec VLAN/bond ou d’une gateway manquante.

Task 3: Vérifier l’état du lien et la vitesse négociée (vérif physique)

cr0x@server:~$ ethtool enp3s0 | sed -n '1,20p'
Settings for enp3s0:
	Supported ports: [ TP ]
	Supported link modes:   1000baseT/Full
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Advertised link modes:  1000baseT/Full
	Advertised auto-negotiation: Yes
	Speed: 1000Mb/s
	Duplex: Full
	Auto-negotiation: on
	Link detected: yes

Ce que ça signifie : Le câble et le port du switch sont corrects. Ce n’est pas « le réseau est tombé ».

Décision : Arrêtez de blâmer le switch. Montez dans la pile : nommage/gestion de service.

Task 4: Voir ce que systemd pense du nom de l’interface et pourquoi

cr0x@server:~$ networkctl status enp3s0
● 2: enp3s0
                 Link File: /usr/lib/systemd/network/99-default.link
              Network File: n/a
                      Type: ether
                     State: routable (configured)
                      Path: pci-0000:03:00.0
                    Driver: e1000e
                HW Address: 3c:fd:fe:dd:ee:ff
                     Address: 192.0.2.10/24
                            fe80::3efd:feff:fedd:eeff/64

Ce que ça signifie : systemd a appliqué les règles de nommage par défaut et voit le chemin PCI. Parfait : vous pouvez matcher sur cela.

Décision : Si vous voulez stabilité en cas de changement de MAC, match par chemin PCI. Si vous voulez stabilité en cas de réarrangements PCI (VMs), envisagez le match par MAC (avec réserves).

Task 5: Identifier les candidats de « nom prédictible » générés par udev

cr0x@server:~$ udevadm test-builtin net_id /sys/class/net/enp3s0 2>/dev/null | grep ID_NET_NAME
ID_NET_NAME_MAC=enx3cfdfeddeeff
ID_NET_NAME_PATH=enp3s0
ID_NET_NAME_SLOT=ens3

Ce que ça signifie : Le système peut nommer cette NIC par MAC (enx...), par chemin (enp3s0) ou par slot (ens3) selon le schéma et les règles.

Décision : Choisissez votre ancrage : MAC-based est très stable sur matériel physique, moins sur VMs clonées. Path/slot est stable quand la topologie matérielle est stable.

Task 6: Trouver ce que votre configuration attend (ifupdown)

cr0x@server:~$ grep -RIn 'auto\|allow-hotplug\|iface' /etc/network/interfaces /etc/network/interfaces.d
/etc/network/interfaces:3:auto lo
/etc/network/interfaces:5:auto eth0
/etc/network/interfaces:6:iface eth0 inet static

Ce que ça signifie : Votre config hard-code eth0. Debian 13 utilise le nommage prédictible, donc eth0 n’existe pas.

Décision : Ne renommez pas simplement eth0 en un seul endroit si vous avez aussi des bonds/bridges/règles de pare-feu. Soit vous épinglez l’interface au nom attendu, soit vous mettez à jour tous les consommateurs de manière intentionnelle.

Task 7: Vérifier les logs des services pour le message d’erreur honnête

cr0x@server:~$ journalctl -u networking -b --no-pager | tail -n 30
ifup: unknown interface eth0
ifup: failed to bring up eth0
networking.service: Failed with result 'exit-code'.

Ce que ça signifie : Le service échoue parce que le nom n’existe pas. Pas de routage. Pas de DNS. Pas de DHCP.

Décision : Fixez le nommage ou fixez la config. Redémarrer le service 15 fois n’inventera pas un eth0.

Task 8: Vérifier quels pilotes sont liés et si un renommage a eu lieu au boot

cr0x@server:~$ dmesg -T | egrep -i 'renamed|link up|eth|enp' | tail -n 25
[Mon Dec 30 02:13:22 2025] e1000e 0000:03:00.0 enp3s0: renamed from eth0
[Mon Dec 30 02:13:22 2025] e1000e 0000:03:00.0 enp3s0: Link is Up 1000 Mbps Full Duplex

Ce que ça signifie : Le noyau l’a initialement appelée eth0, puis udev/systemd l’a renommée en enp3s0.

Décision : Si vous voulez conserver eth0, vous pouvez — mais faites-le explicitement (et de manière cohérente). Sinon, migrez les configs vers le nom prédictible.

Task 9: Confirmer la politique de nommage par défaut dans la ligne de commande du noyau

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.12.0 root=/dev/mapper/vg0-root ro quiet

Ce que ça signifie : Vous ne surchargez pas le nommage via net.ifnames=0 ou biosdevname=0.

Décision : Si vous avez besoin de l’instrument brutal (désactiver le nommage prédictible), c’est ici que cela apparaîtra une fois configuré.

Task 10: Montrer MAC, emplacement PCI et mapping d’interface en une commande

cr0x@server:~$ for i in /sys/class/net/en*; do n=$(basename "$i"); printf "%s " "$n"; cat "$i/address"; readlink -f "$i/device"; done
enp2s0 3c:fd:fe:aa:bb:cc
/sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0
enp3s0 3c:fd:fe:dd:ee:ff
/sys/devices/pci0000:00/0000:00:1c.4/0000:03:00.0

Ce que ça signifie : Vous pouvez matcher une NIC par MAC (address) ou par chemin de périphérique (.../0000:03:00.0).

Décision : Choisissez des critères de correspondance pour votre règle de nommage stable. Serveurs physiques : le chemin PCI est généralement stable. VMs : le MAC peut être plus stable que le slot PCI (dépend de l’hyperviseur).

Task 11: Détecter si NetworkManager gère les appareils et profils

cr0x@server:~$ systemctl is-active NetworkManager
inactive

Ce que ça signifie : NetworkManager n’est pas en jeu ; ifupdown/systemd-networkd l’est probablement.

Décision : Ne réparez pas le mauvais gestionnaire. Si NetworkManager est actif, inspectez les profils ; sinon, concentrez-vous sur ifupdown ou systemd-networkd.

Task 12: Si NetworkManager est actif, vérifier si les profils sont attachés au nom d’interface

cr0x@server:~$ nmcli -f NAME,UUID,DEVICE con show
Wired connection 1  2a0b1c1d-8a9b-4c1f-9a62-2c4f2f0b7e1a  --

Ce que ça signifie : Le profil existe mais n’est attaché à aucun appareil (DEVICE est --).

Décision : Reconnecter le profil au nouveau nom d’interface, ou supprimer la dépendance au nom en matchant via MAC dans les paramètres du profil.

Task 13: Si vous utilisez systemd-networkd, vérifier l’état des unités et la correspondance des configs

cr0x@server:~$ systemctl is-active systemd-networkd
active

Ce que ça signifie : systemd-networkd tourne. Bien : vous pouvez matcher dans des fichiers .network par MAC/Path/Name et éviter les noms fragiles.

Décision : Décidez si vous corrigez le nom de l’interface (.link) ou si vous matcherez les interfaces dans .network par propriétés stables (souvent préférable).

Task 14: Valider dépendances VLAN/bond/bridge (dommages collatéraux fréquents)

cr0x@server:~$ ip -d link show | egrep -A2 'bond|bridge|vlan'
5: bond0: <NO-CARRIER,BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:dd:ee:ff brd ff:ff:ff:ff:ff:ff
7: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:dd:ee:ff brd ff:ff:ff:ff:ff:ff

Ce que ça signifie : Les périphériques de niveau supérieur existent mais n’ont pas de carrier. C’est généralement parce que l’interface esclave n’a pas été esclavagée (mauvais nom) ou n’est jamais montée.

Décision : Corrigez d’abord le nom de base de l’interface, puis réévaluez la création du bond/bridge. Ne déboguez pas le LACP avant d’avoir confirmé l’existence des esclaves.

Task 15: Vérifier les règles de pare-feu dépendantes des noms d’interface

cr0x@server:~$ nft list ruleset | grep -n 'iifname\|oifname' | head
42:		iifname "eth0" accept
88:		oifname "eth0" masquerade

Ce que ça signifie : Votre pare-feu attend littéralement eth0. Il bloquera volontiers le trafic sur enp3s0.

Décision : Mettez à jour les règles vers le nom stable que vous conserverez, ou basez-vous sur l’adresse/sous-réseau/mark plutôt que sur le nom d’interface quand c’est possible.

Task 16: S’assurer de ne pas avoir créé deux vérités via des configs obsolètes

cr0x@server:~$ ls -1 /etc/systemd/network /etc/network/interfaces.d 2>/dev/null
/etc/network/interfaces.d:
eth0.cfg

/etc/systemd/network:
10-wan.network

Ce que ça signifie : Vous avez potentiellement à la fois des configs ifupdown et systemd-networkd. Recette parfaite pour « ça marche parfois ».

Décision : Choisissez un seul stack réseau par rôle d’hôte. Supprimez ou désactivez l’autre. La gestion mixte n’est pas « flexibilité », c’est du carburant pour incidents futurs.

Récupération immédiate : revenir en ligne sans se compliquer la vie

Quand vous êtes en panne, il vous faut deux choses : rétablir l’accès, et éviter d’empirer la situation. L’astuce consiste à appliquer une correction temporaire réversible, puis à implémenter le changement permanent.

Mesure de récupération 1 : monter manuellement la bonne interface

Si vous avez un accès console (KVM, série, console d’hyperviseur), vous pouvez souvent restaurer la connectivité assez longtemps pour déployer la vraie correction.

cr0x@server:~$ ip link set enp3s0 up
cr0x@server:~$ ip addr add 192.0.2.10/24 dev enp3s0
cr0x@server:~$ ip route add default via 192.0.2.1
cr0x@server:~$ ping -c 2 192.0.2.1
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=0.420 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=0.391 ms

Ce que ça signifie : Vous avez prouvé que L1–L3 sont corrects. Vous pouvez maintenant vous connecter à distance (une fois que SSH et le pare-feu permettent).

Décision : N’utilisez ceci que comme un pont vers la correction permanente. Les IP manuelles disparaissent au reboot ; c’est voulu.

Mesure de récupération 2 : ne « réparez » pas en renommant tout au hasard

Si vous êtes tenté de remplacer eth0 par enp3s0 partout dans les configs en panique, faites une pause. Cela marche jusqu’au prochain renommage, et ça ne chiffre pas à l’échelle d’une flotte. Votre prochain incident sera plus rapide, ce qui n’est pas l’optimisation souhaitée.

Blague #1 : Les renommages d’interface sont le seul genre de crise d’identité qui peut faire tomber un datacenter sans changer un seul câble.

Stratégies de nommage stables qui survivent aux redémarrages (choisissez)

Il y a trois stratégies sensées. Deux sont modernes. Une est une couverture de confort héritée qui est parfois toujours le bon choix.

Stratégie A (recommandée) : Conserver le nommage prédictible, l’épinglez avec les fichiers systemd `.link`

C’est généralement la meilleure option sur Debian 13. Vous conservez le système de noms prédictible, mais vous le surchargez pour les interfaces qui comptent (WAN/LAN/stockage/heartbeat). Vous pouvez matcher par MAC, par chemin PCI, par pilote ou par index embarqué — puis définir un nom que vous contrôlez (comme wan0, lan0, stor0).

Pourquoi ça survit aux redémarrages : la règle s’exécute à la découverte du périphérique. À chaque boot, les mêmes critères de match donnent le même nom.

Où ça échoue : si vos critères de match ne sont pas réellement stables (MAC de VM changée, firmware change le chemin, NIC déplacée de slot).

Stratégie B (également bonne) : Ne pas se préoccuper du nom ; matcher dans la config réseau par MAC/chemin

Si vous utilisez systemd-networkd, vous pouvez écrire des fichiers .network qui matchent par MAC ou chemin puis configurer IP/gateway sans vous soucier du nom. C’est étonnamment résilient.

Pourquoi ça survit aux redémarrages : même si le nom change, le match cible toujours la bonne NIC.

Où ça échoue : les outils et politiques (pare-feu, supervision) se basent souvent encore sur les noms d’interface. De plus, les humains dépannant à 03h00 aiment des noms significatifs.

Stratégie C (instrument brutal) : Désactiver le nommage prédictible et revenir à `eth0`

C’est l’approche « faire comme en 2012 ». Elle peut être correcte dans des environnements contrôlés où des logiciels hérités attendent eth0, ou quand vous standardisez sur de l’automatisation ancienne.

Pourquoi ça survit aux redémarrages : ça revient à l’énumération du noyau. Mais souvenez-vous : l’ordre d’énumération peut aussi changer.

Où ça échoue : ajouter/retirer des NICs ou changer de pilotes peut permuter eth0 et eth1. La prédictibilité n’est pas garantie ; c’est juste familier.

La bonne méthode (généralement) : fichiers systemd `.link`

Si vous voulez des noms d’interface stables et signifiants, faites-le avec des fichiers .link dans /etc/systemd/network/. Ils sont explicites, lisibles, et contrôlés par vous plutôt que par l’humeur du matériel du jour.

Choisir un schéma de nommage qui correspond à votre réalité

Serveur physique, NIC reste dans le même slot : matcher par chemin PCI (Path=pci-0000:03:00.0) ou par MAC.
VMs migrées : matcher plus souvent par MAC (si le MAC est stable sur votre plateforme), mais attention aux clones.
Réseaux de stockage et clusters HA : envisager un nommage par rôle (stor0, hb0) pour éviter que les humains confondent « port gauche » et « port droit ».

Créer un fichier .link qui épingle un nom par MAC

cr0x@server:~$ sudo tee /etc/systemd/network/10-wan.link >/dev/null <<'EOF'
[Match]
MACAddress=3c:fd:fe:dd:ee:ff

[Link]
Name=wan0
EOF

Ce que ça signifie : Toute NIC avec ce MAC sera renommée en wan0 tôt au démarrage.

Décision : Utilisez le match par MAC quand vous faites confiance à la stabilité du MAC. Sur serveurs physiques, c’est généralement OK. Sur VMs clonées, privilégiez un autre match.

Créer un fichier .link qui épingle un nom par chemin PCI

cr0x@server:~$ sudo tee /etc/systemd/network/10-stor.link >/dev/null <<'EOF'
[Match]
Path=pci-0000:02:00.0

[Link]
Name=stor0
EOF

Ce que ça signifie : Le périphérique à ce chemin PCI devient stor0.

Décision : Le match par chemin est excellent jusqu’à ce que vous déplaciez la carte ou que le firmware change la manière d’exposer la topologie. Dans un châssis qui ne change jamais, c’est solide.

Appliquer les changements en sécurité

Renommer une interface sur un système en production peut vous couper si vous êtes connecté dessus. Planifiez le moment.

cr0x@server:~$ sudo udevadm control --reload
cr0x@server:~$ sudo udevadm trigger -c add -s net

Ce que ça signifie : udev recharge les règles et retriggère les périphériques réseau. Sur certains systèmes le renommage prendra effet ; sur d’autres, vous devrez redémarrer pour une transition propre.

Décision : Si c’est un hôte distant et que vous n’avez pas de console hors-bande, planifiez un redémarrage de maintenance et faites-le proprement.

Vérifier le nouveau nom et mettre à jour les consommateurs de la config réseau

cr0x@server:~$ ip -br link | grep -E 'wan0|stor0|enp|eth'
wan0             UP             3c:fd:fe:dd:ee:ff <BROADCAST,MULTICAST,UP,LOWER_UP>
stor0            DOWN           3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST>

Ce que ça signifie : Le renommage fonctionne.

Décision : Mettez maintenant à jour une seule fois—vos configs de bond/bridge/VLAN, règles de pare-feu et supervision pour utiliser wan0/stor0 (ou matcher par MAC quand c’est possible).

Un détail que l’on oublie : le nommage se produit tôt

Si votre initramfs inclut le réseau et tente de monter une interface par nom (boot sans disque, root distant, iSCSI, quelques configurations d’initroot chiffré), votre nommage doit être cohérent à cette étape aussi. Si vous changez les règles de nommage, reconstruisez l’initramfs si votre environnement l’exige.

cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.12.0

Ce que ça signifie : Votre initramfs contient maintenant les règles/configs mises à jour (selon le cas).

Décision : Si vous avez été piqué par « marche après le boot, échoue en early boot », considérez l’initramfs comme partie intégrante du système, pas un blob magique.

La méthode radicale : désactiver le nommage prédictible (quand c’est acceptable)

Parfois vous héritez d’une automatisation qui suppose eth0. Parfois un script fournisseur est soudé à ce nom. Parfois vous avez besoin du chemin le plus rapide pour restaurer une flotte sans réécrire tout en plein incident.

Désactiver les noms prédictibles est acceptable quand vous imposez aussi un ordre d’énumération stable (ou que vous n’avez qu’une seule NIC). Ce n’est pas acceptable sur des hôtes multi-NIC faisant des bonds et des trunks VLAN à moins que vous aimiez la roulette.

Définir les paramètres du noyau pour désactiver les noms prédictibles

cr0x@server:~$ sudo sed -i 's/GRUB_CMDLINE_LINUX="/GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0 /' /etc/default/grub
cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.12.0
Found initrd image: /boot/initrd.img-6.12.0
done

Ce que ça signifie : Les prochains boots demanderont au noyau de garder le nommage traditionnel. Selon l’environnement, vous verrez probablement eth0 de nouveau.

Décision : Ne le faites que si vous tolérez les changements d’énumération, ou si vous contraignez l’ordre par d’autres moyens. Préférez sinon .link ou le match par MAC dans la config.

Redémarrer et confirmer

cr0x@server:~$ sudo reboot
Connection to server closed by remote host.
Connection to server closed.

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0             UP             3c:fd:fe:dd:ee:ff <BROADCAST,MULTICAST,UP,LOWER_UP>

Ce que ça signifie : Le système est revenu au nommage legacy.

Décision : Si vous avez plus d’une NIC, vérifiez chaque mappage. Si eth0 n’est pas la NIC que vous pensez, arrêtez-vous et corrigez avant que le mauvais trafic n’aille au mauvais endroit.

Bonds, VLANs, bridges et hyperviseurs : où les renommages font le plus de dégâts

Les machines à NIC unique survivent souvent aux renommages avec une petite gêne. Les machines multi-NIC peuvent totalement tomber, ou pire : fonctionner partiellement d’une manière qui vous fait perdre des heures.

Bonds (LACP/active-backup)

Les bonds dépendent des noms des esclaves. Si l’esclave n’existe pas, le bond monte sans membres et affiche NO-CARRIER.

Symptôme typique : l’interface bond existe, mais aucun trafic ne circule. Vous verrez une interface bond en DOWN même si la NIC physique a un lien.

Bridges (courants en virtualisation)

Les bridges dépendent d’esclavagede la bonne uplink. Si le nom de l’uplink a changé, votre réseau VM peut sembler monter (le bridge existe), mais il est isolé.

C’est là que « ça marche sur l’hôte mais pas dans les VMs » prend sa source.

Sous-interfaces VLAN

Si vous avez enp3s0.100 et que la base devient wan0, le nom de la VLAN devrait devenir wan0.100 si vous la définissez ainsi. Si vous avez codé en dur l’ancien nom de base, les VLANs n’apparaîtront pas.

Hyperviseurs et « matériel virtuel stable »

En VM, « chemin PCI stable » est souvent un mensonge qu’on se raconte pour dormir. Les migrations, mises à jour, et changements de modèle de NIC virtuelle peuvent déplacer la présentation bus/slot. Parfois la VM voit le même MAC, parfois non.

Blague #2 : Une migration d’hyperviseur, c’est juste un « changement matériel » qui porte un costume et prétend que c’est un « événement à chaud ».

Trois mini-histoires d’entreprise issues du terrain

Mini-histoire 1 : L’incident causé par une fausse hypothèse (« eth0 est toujours la primaire »)

Une entreprise de taille moyenne gérait une flotte mixte : quelques serveurs Debian plus anciens avec eth0/eth1 et des plus récents avec des noms prédictibles. Une équipe maintenait un script de provisioning qui faisait une chose très efficacement : il supposait que eth0 était l’interface publique et écrivait les règles de pare-feu en conséquence.

Sur Debian 13, une nouvelle vague d’hôtes a démarré en enp1s0 et enp2s0. Le script écrivait toujours des règles nftables pour eth0. Le service réseau montait enp1s0 correctement, mais le pare-feu bloquait l’SSH entrant parce que la règle d’autorisation ne correspondait jamais.

Le mode d’échec était subtil : les hôtes pouvaient sortir (l’agent de supervision appelait la maison, les mises à jour fonctionnaient), mais la gestion entrante était morte. On a blâmé les security groups, le load balancer et le DNS. Personne n’a blâmé le nom d’interface parce que les voyants étaient allumés et « le réseau est up ».

La correction n’a pas été de remplacer eth0 par enp1s0 dans le script. La correction a été d’arrêter de se reposer sur les noms d’interface pour la politique. Ils ont changé les règles de pare-feu pour matcher sur des sous-réseaux source et sur l’état des connexions, et ont épinglé les noms d’interface avec .link seulement là où le rôle opérationnel l’exigeait.

Après cela, le même script a fonctionné sur les deux schémas de nommage. L’incident s’est terminé, et l’entreprise a appris une leçon SRE classique : les hypothèses sont invisibles jusqu’à ce qu’elles échouent bruyamment.

Mini-histoire 2 : L’optimisation qui s’est retournée (pin par MAC… puis cloner des VMs)

Une autre organisation standardisait les noms d’interface via des .link appariés MAC. C’était propre : wan0, lan0, stor0. Les humains aimaient. Les graphes de supervision étaient plus lisibles. La doc ne disait plus « le port de gauche ».

Puis ils ont déployé un template VM pour un nouveau service. Le template incluait les fichiers .link matchant les MAC du template. En production, les clones ont reçu de nouveaux MAC — comme ils doivent le faire — mais les règles .link n’ont rien matché. Les noms sont donc retombés aux valeurs prédictibles.

Ils se sont retrouvés avec deux mondes : le test de template disait wan0, la production disait ens192. Leur automatisation de déploiement référençait wan0. Certains hôtes ont booté sans IP. D’autres sont montés parce qu’un autre composant matchait par DHCP client ID, créant un succès partiel accidentel qui a prolongé l’incident.

La correction a été d’arrêter d’emballer l’identité spécifique à l’hôte dans les templates. Ils ont basculé vers le match par chemin PCI à l’intérieur de la VM seulement quand l’hyperviseur le garantissait, et sinon ils ont matché dans .network par MAC mais ont généré le match MAC au moment du provisioning (pas dans l’image golden).

L’optimisation — « rendre jolis les noms partout » — s’est retournée parce qu’elle faisait passer l’identité dans un artefact censé être générique. Bonnes intentions, résultat classique.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (hors-bande + vérifications préalables)

Une équipe de services financiers avait une habitude qui paraissait excessivement prudente : chaque changement impactant le réseau nécessitait (1) un accès console hors-bande vérifié, et (2) un script de pré-vérification comparant les noms d’interface configurés aux interfaces réelles.

Quand ils ont mis à niveau un nœud de cluster vers Debian 13, le nom de la NIC a changé parce que le modèle matériel virtuel sous-jacent avait changé lors d’une mise à jour d’hyperviseur la semaine précédente. Le script de pré-vérification l’a signalé immédiatement : « Configured interface bond slaves not present. » Il a aborté le changement avant le reboot.

Parce qu’ils étaient ennuyeux, ils ont été rapides. Ils ont ajusté le nommage .link en mode rôle, mis à jour les configs de bond, reconstruit l’initramfs, et planifié le reboot en fenêtre contrôlée — toujours avec l’accès hors-bande confirmé.

Le nœud a redémarré proprement. Pas de panne. Pas de drame. Le rapport post-change était presque insultant par son absence d’excitation, ce qu’on souhaite quand l’argent est en jeu.

Erreurs fréquentes : symptôme → cause → correction

Symptôme : networking.service échoue avec « unknown interface eth0 ».
Cause : La config référence un nom legacy ; le système utilise le nommage prédictible.
Correction : Epinglez le nom d’interface avec un fichier .link ou mettez à jour les configs vers le nouveau nom stable ; n’oubliez pas pare-feu/bonds/VLANs.
Symptôme : L’interface est UP avec lien, mais pas d’IP après reboot.
Cause : Le client DHCP ou la config statique est lié à un autre nom d’interface ou le profil NetworkManager n’est pas attaché.
Correction : Rattachez le profil (NetworkManager) ou match par MAC/chemin (systemd-networkd) et assurez-vous qu’un seul gestionnaire réseau possède le périphérique.
Symptôme : Bond/bridge existe, mais NO-CARRIER et trafic coupé.
Cause : Les esclaves du bond/uplink du bridge sont référencés par l’ancien nom ; les esclaves n’ont jamais été esclavagés.
Correction : Corrigez d’abord le nommage de base ; puis vérifiez l’esclavage ; puis vérifiez le switch/LACP.
Symptôme : L’hôte peut sortir mais vous ne pouvez pas SSHer ; la supervision fonctionne partiellement.
Cause : Les règles de pare-feu matchaient iifname "eth0" qui n’existe plus.
Correction : Mettez à jour le pare-feu vers le nom stable ou redessinez pour matcher sur sous-réseau/état ; validez le jeu de règles après renommage.
Symptôme : Ça marche jusqu’au reboot ; après redémarrage, le nom change à nouveau.
Cause : Vous avez fait un renommage à runtime ou édité un fichier mais sans définir de politique de nommage persistante.
Correction : Créez des règles .link (ou désactivez intentionnellement le nommage prédictible) et persistez le choix ; reconstruisez l’initramfs si l’early boot importe.
Symptôme : Le nommage MAC « stable » casse seulement sur clones/nouvelles VMs.
Cause : L’image golden incluait des règles .link mac-matched pour le MAC du template.
Correction : Générez les règles .link au moment du provisioning, ou matchez par d’autres identifiants stables ; gardez les templates génériques.
Symptôme : Deux interfaces échangent de rôle après l’ajout d’une nouvelle NIC.
Cause : Vous avez désactivé le nommage prédictible et compté sur l’ordre d’énumération.
Correction : Réactivez le nommage prédictible et épinglez avec .link, ou match explicitement dans la config réseau par MAC/chemin.
Symptôme : Flaps aléatoires ou noms dupliqués après des changements.
Cause : Règles conflictuelles : plusieurs fichiers .link matchent la même NIC, ou ifupdown et networkd gèrent simultanément.
Correction : Assurez des matches uniques, contrôlez la priorité des règles (ordre lexical des fichiers), et utilisez un seul gestionnaire réseau par hôte.

Listes de vérification / plan pas à pas

Pas à pas : réparer un hôte cassé maintenant (NIC unique)

Accès console (IPMI/iDRAC/console virt). N’expérimentez pas sur une session SSH mourante.
Exécuter ip -br link et ip -br addr. Identifier la NIC qui doit posséder l’IP de service.
Vérifier journalctl -u networking -b (ou logs networkd/NetworkManager). Confirmer que c’est un mismatch de nom, pas un échec du pilote.
Attribuer temporairement IP/gateway avec ip addr add/ip route add si vous avez besoin d’accès distant immédiatement.
Créer un fichier .link pour nommer la NIC de manière stable (wan0 convient) en utilisant MAC ou chemin.
Mettre à jour la configuration réseau pour référencer wan0 (ou matcher par MAC/chemin si vous utilisez networkd).
Mettre à jour les règles de pare-feu qui matchent sur des noms d’interface.
Reconstruire l’initramfs si le réseau en early boot est critique pour votre environnement.
Redémarrer pendant une fenêtre contrôlée et vérifier nom, IP, routage et accès entrant.

Pas à pas : réparer un hôte bond/bridge (multi-NIC)

Identifier les NIC physiques et leur mapping MAC/chemin (udevadm test-builtin net_id et /sys/class/net).
Décider des noms stables par rôle : wan0, lan0, stor0, pas des numéros de slot que vous n’oublierez pas.
Créer un .link par rôle avec des matches uniques (MAC ou chemin PCI). Vérifier l’absence de chevauchement.
Mettre à jour les définitions des esclaves de bond et les ports de bridge vers les nouveaux noms stables.
Vérifier ip -d link show bond0 montre les bons esclaves et que le carrier apparaît.
Ensuite seulement, vérifier la configuration switch-side LACP ou le trunk VLAN.
Redémarrer une fois, vérifier à nouveau et capturer des sorties « known good » pour des diffs futurs.

Checklist avant changement pour les mises à niveau Debian 13 (faire avant reboot)

Confirmer que l’accès console hors-bande fonctionne.
Capturer ip -br link, ip -br addr, et networkctl status.
Inventorier les dépendances : règles nftables, bonds, bridges, VLANs, contrôles de supervision.
S’assurer de ne pas avoir de gestionnaires concurrents (ifupdown vs networkd vs NetworkManager) sauf raison très spécifique.
Si vous dépendez du réseau en early boot (root distant, iSCSI, etc.), planifier la reconstruction d’initramfs et tester les boots.

FAQ

1) Pourquoi Debian 13 a-t-il renommé mon interface après une mise à jour ?

Parce que le nommage est dérivé des règles udev/systemd, qui peuvent changer avec les mises à jour, différents pilotes, firmware/BIOS ou un changement de topologie (physique ou virtuel). Votre NIC n’a pas « cassé » ; l’identifiant a changé.

2) Dois-je simplement désactiver les noms d’interface prédictibles ?

Uniquement si vous avez une bonne raison (outillage legacy, NIC unique, matériel contrôlé) et que vous acceptez que l’ordre d’énumération puisse encore changer. Pour des serveurs multi-NIC, préférez l’épinglage via .link ou le match par MAC/chemin dans les configs networkd.

3) Le match par adresse MAC est-il toujours le meilleur ?

Non. Serveurs physiques : généralement oui. VMs : seulement si les MAC sont stables dans votre cycle de vie. Si vous clonez ou régénérez les MAC, les règles basées sur MAC dans les templates vous trahiront.

4) Quelle est la différence entre épingler avec `.link` et matcher dans `.network` ?

.link contrôle le nom de l’interface lui-même. .network associe les interfaces pour appliquer des paramètres IP. Vous pouvez éviter la dépendance au nom en matchant dans .network, mais les noms restent importants pour les humains et d’autres outils.

5) Mon interface est renommée, mais DHCP fonctionne encore. Pourquoi mes services ont-ils cassé ?

Parce que les services dépendent souvent des noms d’interface : règles de pare-feu (iifname), politiques de routage, périphériques VLAN, bonds ou scripts. Le DHCP qui fonctionne ne prouve que la NIC a une adresse, pas que le reste du système est d’accord sur le nom.

6) Comment savoir quel nom d’interface est « correct » pour mon hôte ?

Arrêtez de penser en « correct » et commencez à penser en « stable ». Choisissez des noms par rôle (WAN/LAN/stockage) et liez ces noms à des identifiants stables (MAC/chemin). Puis faites référencer ces noms de rôle par vos configs.

7) Deux fichiers `.link` peuvent-ils se disputer la même NIC ?

Oui. Si deux fichiers matchent le même périphérique, celui ayant la priorité la plus haute (souvent l’ordre lexical) gagne, et vous aurez des comportements incohérents selon les changements. Gardez les matches spécifiques et le nommage des fichiers intentionnel.

8) Dois-je reconstruire l’initramfs après avoir changé les règles de nommage ?

Souvent non pour un boot serveur typique. Mais si vous utilisez le réseau en early boot (boot sans disque, root distant, iSCSI, certains setups chiffrés), considérez cela comme obligatoire : reconstruisez et testez.

9) Et les conteneurs — s’en préoccupent-ils ?

Les conteneurs voient généralement des noms veth et des namespaces ; le nom de l’uplink de l’hôte reste important pour le pare-feu, le routage et la configuration CNI. Si vous cassez l’uplink de l’hôte, vos conteneurs échoueront avec lui.

10) Quelle est l’approche la plus sûre à long terme pour une flotte mixte ?

Standardisez sur des noms basés rôle via .link pour les uplinks importants, et écrivez des politiques de haut niveau (pare-feu, supervision) pour être résilientes — évitez de coder en dur des noms d’interface éphémères quand c’est possible.

Conclusion : prochaines étapes pratiques

Si Debian 13 « a cassé le réseau », supposez que vous avez affaire à une discordance de nom d’interface jusqu’à preuve du contraire. Confirmez l’existence de la NIC, confirmez le lien, confirmez que la config référence un nom qui n’existe plus. Puis corrigez-le une fois, correctement.

Choisissez une stratégie de nommage stable : les noms rôle-based via .link sont la meilleure réponse par défaut.
Auditez les dépendances : bonds/bridges/VLANs, règles de pare-feu, supervision, et tous les scripts qui supposent eth0.
Faites en sorte que la correction survive aux redémarrages : persistez la politique de nommage, mettez à jour les configs, reconstruisez l’initramfs si l’early boot importe.
Institutionnalisez cela : ajoutez une vérification pré-vol qui compare les noms d’interface configurés aux périphériques réels avant les reboots/mises à niveau.

L’objectif n’est pas de gagner l’incident d’aujourd’hui. L’objectif est de faire en sorte que le prochain redémarrage soit ennuyeux.