Debian 13 : le réseau ne se relève pas après un reboot — checklist systemd-networkd sans blabla

Modèle mental : ce que « le réseau est up » signifie réellement

On dit souvent « le réseau est down » comme si c’était une seule chose. Sur une machine Debian 13 utilisant systemd-networkd, « le réseau est up » est une chaîne de conditions distinctes :

• Liaison matérielle : la NIC détecte le carrier, l’autonégociation est faite, le pilote est content.
• L’interface existe et est nommée : votre configuration correspond au nom réel d’interface après le renommage prévisible par udev.
• Adressage : le DHCP réussit (ou les adresses statiques sont appliquées) et l’adresse est effectivement liée à l’interface.
• Routage : vous avez une route par défaut (ou les routes de politique pertinentes) et le noyau sélectionne ce que vous attendez.
• DNS : /etc/resolv.conf pointe vers quelque chose de réel, ou systemd-resolved est configuré correctement, ou vous avez fourni des serveurs de noms explicites.
• Pare-feu : le pare-feu local ne mange pas discrètement les réponses DHCP, l’ARP ou votre propre SSH.
• Dépendances : des services qui démarrent « après le réseau » ne sont pas accidentellement en train de bloquer le réseau lui‑même (oui, ça arrive).

systemd-networkd ne gère qu’une partie de ces éléments. Il configure les liens, les adresses et les routes, et peut pousser des paramètres DNS dans systemd-resolved. Il ne négocie pas avec votre switch. Il ne réparera pas non plus un module noyau qui devient capricieux après une mise à jour de firmware.

La règle est simple : ne redémarrez pas « le networking » en espérant que ça résolve le problème. Identifiez quel maillon de la chaîne est cassé. Réparez celui-là, puis confirmez le maillon suivant.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Premier : est-ce un décalage de nom/configuration ou un conflit de services ?

Les pannes les plus rapides sont ennuyeuses : le nom de l’interface a changé, ou deux piles réseau se battent. Confirmez le nom de l’interface et qui la contrôle.

• Vérifiez les noms et l’état réels des NIC (ip link).
• Vérifiez si systemd-networkd est activé et en cours d’exécution.
• Vérifiez la présence de NetworkManager, de restes d’ifupdown, ou d’une configuration de bridge de conteneur qui écrase tout.
• Vérifiez que /etc/systemd/network/*.network correspond à la bonne interface (par nom ou par MAC).

Deuxième : la liaison est-elle up et le DHCP/l’adressage s’appliquent‑ils ?

Si la NIC n’a pas de carrier ou si DHCP ne se termine jamais, vous perdrez des heures à courir après les routes et le DNS.

• Confirmez le carrier et la vitesse/duplex négociés (ethtool).
• Vérifiez networkctl status pour « configured » vs « configuring » vs « failed ».
• Lisez le journal de systemd-networkd pour des erreurs DHCP explicites et des timeouts.

Troisième : routage et DNS, dans cet ordre

Le routage fait la différence entre « je peux ping mon gateway » et « je peux atteindre quoi que ce soit ». Le DNS fait la différence entre « je peux atteindre 1.1.1.1 » et « je peux atteindre tout par nom ». Ne les inversez pas.

• Vérifiez la route par défaut et l’adresse source choisie (ip route, ip route get).
• Vérifiez le chemin du résolveur (resolvectl status et le lien effectif de /etc/resolv.conf).
• Ensuite seulement testez la connectivité sortante et la résolution de noms.

Conseil opérationnel : Quand vous êtes sur la console à 3 h du matin, vous voulez un seul récit : « Liaison OK → adresse présente → route présente → DNS correct. » Tout le reste, c’est de l’ambiance.

Faits intéressants et contexte historique (pour ne pas refaire les mêmes erreurs)

1. Les noms d’interface prédictibles n’ont pas toujours été la valeur par défaut. Les anciens Linux utilisaient eth0/eth1 ; le nommage udev moderne essaie d’être stable, mais des changements de firmware/topologie PCI peuvent encore renommer les interfaces.
2. Debian utilisait historiquement ifupdown. Pendant des années, /etc/network/interfaces pilotait le réseau. Beaucoup de pannes « mystérieuses » viennent d’hypothèses héritées de cette époque.
3. systemd-networkd est volontairement minimaliste. Il est conçu pour les serveurs et les conteneurs : moins de pièces mobiles, une configuration déclarative, moins de magie desktop.
4. systemd-resolved a changé la notion de « config DNS ». Beaucoup de gens éditent encore /etc/resolv.conf directement, puis s’étonnent qu’il soit écrasé ou qu’il pointe vers un stub resolver.
5. DHCP n’est pas juste « obtenir une IP ». Les baux incluent routes, MTU, DNS, NTP, et peuvent être affectés par des identifiants clients et DUID — des détails qui ressortent après des reboots ou réinstallations.
6. wait-online est un choix de politique, pas une obligation. systemd-networkd-wait-online peut empêcher des services de démarrer avant que le réseau soit utilisable, mais il peut aussi bloquer le démarrage si on en abuse.
7. Netplan a popularisé la configuration déclarative ailleurs. Debian ne l’exige pas ; certains admins copient des modèles mentaux d’autres distros et se retrouvent sans rien configurer.
8. Un carrier ne garantit pas la connectivité. Un lien peut être « up » alors que le tagging VLAN est faux, le port du switch dans le mauvais VLAN, ou que le mode de bonding ne correspond pas à la configuration du switch.

Tâches pratiques : commandes, sorties attendues et décisions

Ce sont des tâches réelles que vous pouvez exécuter sur un système Debian 13. Pour chacune : la commande, ce que vous recherchez, et la décision suivante.

Task 1 — Confirmer quels services tournent réellement

cr0x@server:~$ systemctl status systemd-networkd --no-pager
● systemd-networkd.service - Network Configuration
     Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; preset: enabled)
     Active: active (running) since Sun 2025-12-28 01:07:14 UTC; 2min 11s ago
       Docs: man:systemd-networkd.service(8)

Sens : S’il n’est pas « active (running) », arrêtez de deviner. S’il est désactivé, votre boot ne configurera rien.

Décision : S’il est inactive/failed, allez directement au journal (Task 6) et à la validation de la configuration (Task 8). S’il tourne, continuez.

Task 2 — Vérifier les gestionnaires réseau concurrents

cr0x@server:~$ systemctl is-enabled NetworkManager 2>/dev/null; systemctl is-active NetworkManager 2>/dev/null
enabled
active

Sens : Si NetworkManager est actif sur un serveur que vous vouliez gérer avec networkd, vous êtes en « deux capitaines sur le même bateau ».

Décision : Choisissez-en un. Pour les serveurs, je désactive généralement NetworkManager sauf raison spécifique. Si vous le conservez, ne configurez pas networkd pour les mêmes interfaces.

Task 3 — Identifier les noms d’interfaces existants maintenant

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

Sens : Vous savez maintenant quels noms vous pouvez matcher dans les fichiers .network. Notez aussi lesquels ont LOWER_UP (carrier).

Décision : Si votre config référence eth0 mais que vous avez enp7s0, c’est votre bug. Corrigez le matching (Task 9).

Task 4 — Demandez à networkd ce qu’il pense se passer

cr0x@server:~$ networkctl status enp7s0 --no-pager
● 2: enp7s0
             Link File: /usr/lib/systemd/network/99-default.link
          Network File: /etc/systemd/network/10-lan.network
                  Type: ether
                 State: routable (configured)
          Online state: online
                Address: 192.0.2.10/24
                         fe80::3efd:feff:fedd:eeff/64
                Gateway: 192.0.2.1
                    DNS: 192.0.2.53

Sens : « routable (configured) » est ce que vous voulez. « configuring » signifie que DHCP ou la négociation du lien n’est pas terminée. « failed » signifie que votre config n’a pas été appliquée ou qu’un niveau inférieur a échoué.

Décision : Si ce n’est pas configuré, allez aux logs DHCP et au diagnostic lien (Tasks 5–7).

Task 5 — Vérifier la liaison physique et la négociation

cr0x@server:~$ ethtool enp7s0 | sed -n '1,25p'
Settings for enp7s0:
	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

Sens : Si Link detected: no, ne blâmez pas DHCP. Vous avez un problème de câble/switchport/VLAN/driver. Si la vitesse est à 10Mb/s de manière inattendue, vous pourriez avoir des problèmes de câblage provoquant des timeouts DHCP intermittents.

Décision : Réparez L1/L2 d’abord. Si la liaison est bonne, poursuivez vers DHCP/adresses.

Task 6 — Lire les logs de networkd pour ce boot (la vérité, pas l’ambiance)

cr0x@server:~$ journalctl -u systemd-networkd -b --no-pager -n 80
Dec 28 01:07:15 server systemd-networkd[412]: enp7s0: DHCPv4 client: started
Dec 28 01:07:18 server systemd-networkd[412]: enp7s0: DHCPv4 address 192.0.2.10/24, gateway 192.0.2.1 acquired
Dec 28 01:07:18 server systemd-networkd[412]: enp7s0: Gained carrier

Sens : Vous cherchez des erreurs nettes : « no carrier », « DHCPv4 lease lost », « could not set address », « link is not managed ».

Décision : Si vous voyez « link is not managed », votre matching est faux (Task 9). Si DHCP timeout, continuez avec Tasks 7 et 11.

Task 7 — Vérifier l’état du client DHCP et les détails du bail

cr0x@server:~$ networkctl status enp7s0 --no-pager | sed -n '1,120p'
● 2: enp7s0
                 State: configuring (configuring)
          Online state: unknown
                Address: fe80::3efd:feff:fedd:eeff/64

Sens : Une adresse link-local IPv6 seule signifie typiquement que le DHCPv4 n’a pas réussi et qu’il n’y a pas d’IPv4 statique.

Décision : S’il reste en configuring, capturez le trafic DHCP (Task 11) et vérifiez le pare‑feu/bridge/vlan.

Task 8 — Valider que vos fichiers de configuration networkd existent et sont sensés

cr0x@server:~$ ls -l /etc/systemd/network
total 8
-rw-r--r-- 1 root root 210 Dec 27 22:10 10-lan.network
-rw-r--r-- 1 root root 120 Dec 27 22:10 10-lan.link

Sens : Si ce répertoire est vide, networkd fera très peu sauf si vous comptez sur le comportement DHCP par défaut (ce qui n’est pas un plan ; c’est une vibe).

Décision : Ouvrez les fichiers et confirmez les critères de matching et les paramètres DHCP/statique (Task 9).

Task 9 — Confirmer que vos règles de match correspondent bien à la NIC

cr0x@server:~$ sed -n '1,120p' /etc/systemd/network/10-lan.network
[Match]
MACAddress=3c:fd:fe:dd:ee:ff

[Network]
DHCP=yes
IPv6AcceptRA=yes

Sens : Matcher par MAC est robuste face aux renommages d’interface. Matcher par Name=enp7s0 va tant que BIOS/PCI ne change pas l’énumération. Choisissez votre compromis.

Décision : Si votre match ne matche pas, networkd ignore le fichier. Corrigez le match, puis redémarrez networkd (Task 10).

Task 10 — Redémarrer networkd et observer l’application en direct

cr0x@server:~$ systemctl restart systemd-networkd
cr0x@server:~$ journalctl -u systemd-networkd -n 30 --no-pager
Dec 28 01:10:02 server systemd-networkd[615]: enp7s0: Link UP
Dec 28 01:10:02 server systemd-networkd[615]: enp7s0: DHCPv4 client: started
Dec 28 01:10:05 server systemd-networkd[615]: enp7s0: DHCPv4 address 192.0.2.10/24, gateway 192.0.2.1 acquired

Sens : Si un restart règle le problème, vous avez probablement une course au boot (delai d’initialisation firmware, disponibilité du pilote, ou mauvaise utilisation de wait-online) plutôt qu’une erreur de config permanente.

Décision : Si ça ne marche qu’au boot, corrigez l’ordre avec la politique wait-online et la stabilité pilote/firmware (voir la section checklist).

Task 11 — Capturer les paquets DHCP pour prouver si des réponses existent

cr0x@server:~$ timeout 15 tcpdump -ni enp7s0 -vvv 'udp port 67 or udp port 68'
tcpdump: listening on enp7s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP (tos 0x0, ttl 64, id 42121, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 3c:fd:fe:dd:ee:ff, length 300, xid 0x6a2c9f10, Flags [none]
IP (tos 0x0, ttl 64, id 1242, offset 0, flags [none], proto UDP (17), length 342)
    192.0.2.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, xid 0x6a2c9f10, yiaddr 192.0.2.10, length 314

Sens : Si vous voyez des requêtes mais pas de réponses, le problème est en amont (VLAN switch, relais DHCP, pare‑feu, sécurité de port). Si vous voyez des réponses mais que networkd ne configure toujours pas, c’est local (pare‑feu, gestionnaire concurrent, ou parsing du bail).

Décision : Pas de réponses : escaladez vers l’équipe réseau avec les preuves. Réponses présentes : concentrez‑vous sur la configuration de l’hôte et les logs.

Task 12 — Vérifier adresses et routes telles que vues par le noyau

cr0x@server:~$ ip -4 addr show dev enp7s0
2: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 192.0.2.10/24 brd 192.0.2.255 scope global dynamic enp7s0
       valid_lft 86368sec preferred_lft 86368sec
cr0x@server:~$ ip route
default via 192.0.2.1 dev enp7s0 proto dhcp src 192.0.2.10 metric 1024
192.0.2.0/24 dev enp7s0 proto kernel scope link src 192.0.2.10

Sens : Pas de route par défaut signifie « LAN local seulement ». Une route par défaut incorrecte signifie « roulette de connectivité ». Les metrics comptent si vous avez plusieurs uplinks.

Décision : Si la route par défaut manque, corrigez les options DHCP ou définissez une gateway statique dans le fichier .network. Si elle est mauvaise, vérifiez des clients DHCP multiples ou des configs réseau qui s’appliquent en conflit.

Task 13 — Confirmer le chemin du résolveur (et arrêter d’éditer le mauvais fichier)

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Dec 27 22:10 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf
cr0x@server:~$ resolvectl status | sed -n '1,120p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
 resolv.conf mode: stub
Current DNS Server: 192.0.2.53
       DNS Servers: 192.0.2.53

Sens : Si resolvectl n’affiche aucun serveur DNS, vous avez le routage mais pas la résolution de noms. Si /etc/resolv.conf pointe vers un ancien fichier statique alors que systemd-resolved est activé, vous debuggez probablement le mauvais chemin.

Décision : Décidez si vous voulez utiliser resolved ou pas. Si oui, fournissez‑lui des DNS via networkd. Si non, désactivez‑le et gérez explicitement /etc/resolv.conf.

Task 14 — Confirmer ce que « online » signifie sur votre système (wait-online)

cr0x@server:~$ systemctl status systemd-networkd-wait-online --no-pager
● systemd-networkd-wait-online.service - Wait for Network to be Configured
     Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; enabled; preset: enabled)
     Active: active (exited) since Sun 2025-12-28 01:07:19 UTC; 3min ago

Sens : Si ce service bloque ou expire pendant le boot, vous pouvez vous retrouver avec des services retardés ou un démarrage « terminé » sans réseau utilisable selon les dépendances d’unités.

Décision : Si vous n’avez pas besoin d’un gating strict, désactivez‑le. Si vous en avez besoin, configurez‑le précisément (quelle interface, quel état) et évitez d’attendre des liens qui sont intentionnellement absents au démarrage.

Task 15 — Vérifier que vous n’avez pas perdu le pilote/firmware après des mises à jour

cr0x@server:~$ dmesg -T | grep -Ei 'firmware|enp7s0|link up|link down|renamed' | tail -n 30
[Sun Dec 28 01:07:13 2025] r8169 0000:07:00.0 enp7s0: renamed from eth0
[Sun Dec 28 01:07:14 2025] r8169 0000:07:00.0 enp7s0: Link is Up - 1Gbps/Full - flow control off

Sens : Les échecs de chargement de firmware, les resets du pilote et les renommages apparaissent ici tôt. Une ligne de renommage est un avertissement que matcher par nom peut être fragile.

Décision : Si le firmware manque, installez le bon paquet de firmware. Si le pilote fait flapper le lien, envisagez de figer une combinaison noyau/firmware connue comme fonctionnelle jusqu’à validation.

Task 16 — Vérifier les règles de pare‑feu qui cassent DHCP ou ARP (oui, vraiment)

cr0x@server:~$ nft list ruleset | sed -n '1,120p'
table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
		ct state established,related accept
		iif "lo" accept
		tcp dport 22 accept
	}
}

Sens : Une politique d’entrée par défaut drop sans autorisation explicite du DHCP peut bloquer le DHCP (UDP 67/68) selon la structure des règles et des hooks. Surveillez aussi les bizarreries de la table raw et le filtrage de bridge.

Décision : Si le DHCP est bloqué, autorisez‑le sur l’interface concernée pendant le boot, ou utilisez un adressage statique. Restez explicite ; « ça marche la plupart du temps » n’est pas une stratégie de sécurité.

Blague #1 : DHCP, c’est comme le concierge d’un hôtel — serviable, mais si vous arrivez à 2 h du matin et que la réception est fermée, vous dormez dans le hall.

Trois micro-récits du monde de l’entreprise (comment ça échoue en production)

Incident #1 : la panne causée par une mauvaise hypothèse

L’environnement était ennuyeux à dessein : une petite flotte de serveurs Debian derrière un switch top-of-rack, des réservations DHCP basées sur le MAC, et systemd-networkd qui gérait tout. L’équipe avait une forte hypothèse : « les noms d’interface sont stables sur les serveurs. » Ils matchaient partout sur Name=enp3s0.

Puis un lot d’hôtes a reçu une mise à jour BIOS. Elle a modifié l’énumération PCI juste assez pour que la NIC passe d’un slot à un autre. Le noyau n’a pas cassé ; il a fait ce qu’il fait toujours. Le nom de l’interface a changé.

Au reboot, networkd est parti proprement, a lu le fichier .network, et l’a appliqué à exactement zéro interface. Aucune erreur criante sur la console. Pas de DHCP. Pas de routes. La supervision montrait les hôtes down ; les mains à distance affirmaient que les voyants du lien semblaient normaux.

La correction technique fut triviale : matcher par MAC dans [Match], et éventuellement ajouter un fichier .link pour attacher un nom stable si l’équipe en avait besoin. Mais la vraie correction fut procédurale : arrêter de compter sur « assez stable ». Si une règle de match peut devenir obsolète sans modification de config, elle le fera—généralement pendant des fenêtres de maintenance quand tout le monde est fatigué.

Incident #2 : l’optimisation qui s’est retournée contre eux

Une autre organisation voulait réduire le temps de boot. Ils désactivèrent tout ce qui ressemblait à de l’attente. systemd-networkd-wait-online fut désactivé partout, et certaines unités furent réécrites pour démarrer plus tôt.

Les boots furent plus rapides. Les pannes aussi.

Quelques services supposaient que le réseau était routable au démarrage. Sur cold boots, DHCP prenait quelques secondes de plus parce que le switch utilisait une fonctionnalité de sécurité retardant le forwarding pendant la vérification du MAC. Les services se lancèrent, échouèrent à contacter des dépendances en amont, et tombèrent en crash loops. Le réseau monta quelques instants plus tard—trop tard pour l’appli qui avait déjà jugé le monde cassé.

Le postmortem fut douloureux car tout semblait normal quand les ingénieurs se connectaient : réseau up, DHCP loué, routes correctes. La panne était temporelle. L’« optimisation » avait supprimé un point de synchronisation sans le remplacer correctement.

Ils réintroduisirent finalement un gating, mais de façon sélective : uniquement pour les hôtes et services qui ont réellement besoin du réseau au démarrage, et avec un périmètre plus restreint (attendre une interface spécifique, pas « n’importe quel lien »). La perte de temps de boot fut faible. L’amélioration de la fiabilité, grande.

Incident #3 : la pratique ennuyeuse qui a sauvé la mise

Celle‑ci est ma préférée parce qu’elle est résolument peu glamour. L’équipe exécutait systemd-networkd avec deux règles : matcher par MAC, et garder une configuration statique minimale « connue bonne » prête à être déployée par l’automatisation pour chaque rack.

Un matin, après une maintenance planifiée d’alimentation, un ensemble de switches revint avec une configuration partielle. Le relais DHCP était cassé sur un VLAN. Les serveurs redémarrèrent, la liaison monta, les requêtes DHCP partirent et rien ne revint. Le réseau n’était pas « down » ; il refusait juste d’attribuer des adresses sur ce segment.

Le personne d’astreinte n’a pas perdu de temps. Il a utilisé la console pour lancer un tcpdump de 15 secondes sur les ports DHCP, n’a vu aucune réponse, et a appliqué le fallback statique pré‑défini (adresse, gateway, DNS). Cela a rendu les hôtes joignables immédiatement, ce qui a permis à l’équipe réseau de réparer le relais sans en plus se battre contre « on n’arrive même pas à atteindre la machine ».

La clé n’était pas des exploits héroïques. C’était d’avoir une issue de secours testée. Quand vous savez déjà à quoi ressemble le « bon état », vous arrêtez de traiter les incidents comme des mystères.

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

1) « L’interface est UP mais n’a pas d’adresse IPv4 »

Symptôme : ip link montre UP,LOWER_UP, mais ip -4 addr n’affiche rien.

Cause racine : DHCP non lancé, réponses DHCP bloquées, ou l’interface n’est pas gérée par networkd à cause d’un échec de matching.

Correction : Confirmez networkctl status et le journal de networkd. Lancez un tcpdump pour DHCP. Corrigez les règles [Match] ou autorisez le DHCP dans le pare‑feu.

2) « networkctl indique ‘link is not managed’ »

Symptôme : networkctl status enp7s0 dit non géré.

Cause racine : Aucun fichier .network correspondant, ou un autre gestionnaire a pris la main.

Correction : Ajoutez un fichier .network avec le matching correct ; désactivez le gestionnaire concurrent pour cette interface.

3) « DHCP réussit mais il n’y a pas de route par défaut »

Symptôme : Vous avez une adresse, mais ip route n’affiche pas de default via.

Cause racine : Le serveur DHCP ne fournit pas l’option routeur, des règles de routage de politique l’emportent, ou plusieurs interfaces entrent en compétition.

Correction : Définissez Gateway= explicitement pour les configurations statiques, ou corrigez l’étendue DHCP. Si multi‑homé, définissez les metrics et la politique de routage volontairement.

4) « Je peux ping le gateway mais je ne résous pas les noms »

Symptôme : ping 192.0.2.1 fonctionne, ping deb.debian.org échoue.

Cause racine : DNS non configuré, stub systemd-resolved mal câblé, ou /etc/resolv.conf obsolète.

Correction : Utilisez resolvectl status. Décidez resolved activé/désactivé. Assurez-vous que le DNS est fourni par networkd ou que le resolv.conf statique est géré par l’outil approprié.

5) « Le réseau fonctionne après un restart manuel, échoue seulement au boot »

Symptôme : systemctl restart systemd-networkd le remet en état ; un reboot non.

Cause racine : Course au démarrage : pilote pas prêt, lien monte tard, dispositif VLAN créé après la passe initiale de networkd, ou wait-online mal spécifié.

Correction : Utilisez des règles de matching déterministes ; envisagez d’ajouter une politique RequiredForOnline=, ajustez wait-online pour attendre la bonne interface, et inspectez dmesg pour pilotes/firmware.

6) « SSH inaccessible seulement après reboot, console locale OK »

Symptôme : L’hôte tourne, mais l’accès distant échoue jusqu’à ce que quelqu’un touche au réseau.

Cause racine : Le pare‑feu se charge avant que les adresses/routes existent, ou une politique drop bloque DHCP/ARP/neighbor discovery au début du boot.

Correction : Faites des règles de pare‑feu qui autorisent explicitement le trafic de bootstrap au démarrage, ou séquencez l’activation du pare‑feu après que le réseau soit configuré (prudemment, avec dépendances claires).

Blague #2 : La phrase « ça marche sur ma machine » est moins rassurante quand votre machine est un serveur dans une baie verrouillée que vous n’avez pas le droit de toucher.

Checklists / plan pas à pas (du cassé à l’ennuyeux)

Checklist A — Triage immédiat sur console (10 minutes, sans idéologie)

1. Lister interfaces et carrier : ip -br link. Si aucun LOWER_UP, réglez d’abord le physique/switch/VLAN/driver.
2. Confirmer le propriétaire : systemctl is-active systemd-networkd et vérifier les conflits NetworkManager/ifupdown.
3. Demander à networkd : networkctl status. Repérez « not managed », « configuring », ou « failed ».
4. Lire les logs : journalctl -u systemd-networkd -b. Cherchez timeouts DHCP, échecs de matching, flapping de lien.
5. Vérifier l’état noyau : ip -4 addr et ip route. Si pas de route par défaut, corrigez‑la avant le DNS.
6. Vérification DNS : resolvectl status et ls -l /etc/resolv.conf. Comprenez qui gère le DNS.
7. Si DHCP est bloqué : lancez un tcpdump de 15 secondes pour DHCP. Prouvez si des réponses existent.

Checklist B — Rendre votre config networkd résiliente

1. Matcher par MAC (généralement) : Dans [Match], préférez MACAddress= pour les NIC physiques. Le matching par nom est acceptable pour les interfaces virtuelles que vous contrôlez entièrement.
2. Un interface par fichier : Évitez les « wildcard match » qui configurent accidentellement NIC de management et NIC de stockage de la même façon.
3. Être explicite sur DHCP vs statique : Ne laissez pas le « comportement DHCP par défaut » être un accident. Si vous voulez DHCP, dites‑le. Si vous voulez statique, écrivez‑le complètement (Address, Gateway, DNS).
4. Définir l’intention de routage sur des hôtes multi‑homés : Mettez des metrics, des règles de routage de politique, et évitez deux routes par défaut sauf si c’est voulu.
5. Décidez votre modèle DNS : Soit vous exécutez systemd-resolved et vous l’intégrez, soit vous le désactivez et gérez /etc/resolv.conf. La propriété mixte conduit aux heisenbugs.

Checklist C — Ordonnancement du boot sans douleur auto‑infligée

1. N’utilisez wait-online que si c’est nécessaire. Si rien n’a besoin du réseau au démarrage, ne bloquez pas le boot juste pour vous rassurer.
2. Si vous avez besoin de wait-online, scindez‑le. Attendre « n’importe quelle interface » sur un hôte avec des liens optionnels est un générateur de blocage de boot.
3. Arrêtez d’écrire des services qui supposent que le réseau est instantanément prêt. Ajoutez retries/backoff. Les services doivent survivre à un DHCP lent sans se mettre en colère.
4. Surveillez les régressions pilote/firmware. Si le réseau casse après un changement de noyau/firmware, confirmez‑le dans dmesg et n’hésitez pas à revenir en arrière le temps de valider.

Une citation fiabilité (une seule)

L’espoir n’est pas une stratégie. — James Cameron

Ce n’est pas de la « théorie ops ». C’est la différence entre lire les logs et redémarrer jusqu’à ce que ça marche.

FAQ

1) Dois‑je utiliser systemd-networkd sur des serveurs Debian ?

Si vous appréciez un comportement prévisible et une configuration simple, oui. Il est excellent pour les serveurs, VMs et tout ce que vous voulez configurer de manière déclarative. Si vous avez besoin d’un roaming Wi‑Fi interactif ou d’une intégration GUI, c’est le domaine de NetworkManager.

2) Le nom de mon interface a changé après un reboot. Comment empêcher que ça casse la config ?

Ne matchtez pas sur le nom pour les NIC physiques. Matchtez sur MACAddress= dans la section [Match]. Si vous avez vraiment besoin de noms stables, utilisez un fichier .link pour attribuer un nom basé sur le MAC.

3) DHCP fonctionne parfois, parfois non. Que dois‑je vérifier en premier ?

Le carrier et le comportement du switch. Lancez ethtool et capturez les paquets DHCP avec tcpdump. Si votre hôte envoie des requêtes mais ne voit pas de réponses, ce n’est presque jamais un « problème Linux ».

4) Pourquoi redémarrer systemd-networkd le règle‑t‑il parfois ?

Cela pointe typiquement vers une question de timing : le lien monte tard, les dispositifs VLAN apparaissent après la passe initiale de networkd, ou un autre service fait une course. La correction est d’enlever la course (règles de match meilleures, dépendances correctes), pas d’ajouter un hack de redémarrage.

5) Dois‑je activer systemd-networkd-wait-online ?

Seulement si vous avez des services qui ont réellement besoin que le réseau soit configuré avant de démarrer. Si vous l’activez, configurez vos unités pour attendre ce dont elles ont besoin—idéalement une interface et un état spécifiques—plutôt que « le réseau en général ».

6) Le DNS est cassé mais les routes sont OK. Où chercher ?

Commencez par resolvectl status et ls -l /etc/resolv.conf. Confirmez si vous utilisez systemd-resolved (mode stub) ou un resolv.conf statique. Corrigez la propriété, puis les serveurs de noms.

7) Est‑ce que nftables peut casser le DHCP ?

Oui. Surtout avec des politiques default‑drop et des autorisations incomplètes. DHCP utilise UDP 67/68 et des broadcasts ; des jeux de règles trop stricts les bloquent. Prouvez‑le avec tcpdump et ajustez les règles explicitement.

8) Comment déboguer une route par défaut manquante sur des hôtes multi‑NIC ?

Utilisez ip route et ip route get 1.1.1.1 pour voir le chemin choisi et l’adresse source. Puis définissez des metrics ou des règles de routage de politique pour que le noyau cesse de « choisir » et commence à obéir.

9) « link up » suffit‑il à dire que le réseau est sain ?

Non. Link up signifie seulement carrier électrique/optique. Il vous faut toujours un tagging VLAN correct, un adressage correct, des routes correctes et un DNS fonctionnel. LOWER_UP est l’étape 1, pas la ligne d’arrivée.

Conclusion : prochaines étapes dont vous vous remercierez

Quand le réseau Debian 13 ne remonte pas après un reboot, le chemin le plus rapide est la discipline : vérifiez la liaison, vérifiez l’adressage, vérifiez le routage, vérifiez le DNS, dans cet ordre. Lisez le journal de networkd comme s’il vous devait de l’argent. Ne devinez pas.

Prochaines étapes qui rapportent :

• Mettez à jour vos fichiers .network pour matcher par MAC (ou autre propriété stable), pas par nom d’interface sauf si vous contrôlez le nommage.
• Décidez si vous êtes une infrastructure systemd-resolved ou non, et configurez le DNS en conséquence. Pas de solutions hybrides.
• Auditez les conflits : un seul gestionnaire réseau doit configurer une interface donnée.
• Si des races au boot existent dans votre environnement, utilisez wait-online de façon sélective et concevez les services avec des retries plutôt que des ordonnancements magiques.
• Gardez un plan de secours statique testé pour l’accès de management. « On n’arrive pas à atteindre la machine » n’est pas un bon moment pour déboguer une panne alors que la machine est inaccessible.