Ubuntu 24.04 « Réseau inaccessible » : sérum de vérité de la table de routage (et correctifs)

janvier 11, 2026 • février 3, 2026 • Lecture : 29 min • Views: 8

Cet article vous a aidé ?

« Réseau inaccessible » est la franchise brute de Linux. Ce n’est pas un message disant que le DNS est en panne. Ce n’est pas un message disant que l’hôte distant est HS. Cela signifie : « J’ai regardé mes tables de routage et je ne sais pas où envoyer ce paquet. »

Sur Ubuntu 24.04, cette honnêteté peut être gênante — surtout quand l’interface est « UP », l’IP est présente et votre collègue jure que ça fonctionnait « il y a cinq minutes ». C’est le moment d’arrêter les suppositions et d’interroger la décision de routage que le noyau prend réellement.

Ce que « Réseau inaccessible » signifie vraiment (point de vue du noyau)

Quand vous voyez :

cr0x@server:~$ ping -c 1 1.1.1.1
ping: connect: Network is unreachable

Cette erreur est typiquement ENETUNREACH qui remonte depuis le noyau. Traduction : le noyau a essayé de trouver une route vers la destination et a échoué à l’étape de routage — avant même d’essayer ARP/NDP, avant que le câble ne soit touché.

Cette distinction est importante. Si ARP échoue, vous obtenez souvent « Destination Host Unreachable » (depuis l’hôte local) ou des timeouts. Si le DNS échoue, vous obtenez « Name or service not known ». Si la recherche de route échoue, vous obtenez « Network is unreachable ». Linux n’est pas poétique ; il vous donne un mode d’échec précis.

Il y a quelques variantes à connaître :

Aucune route correspondante n’existe dans les tables de routage consultées pour cette destination.
Une route existe mais elle est marquée unreachable, prohibit ou blackhole (oui, ce sont de vrais types de route).
Le policy routing (ip rules) a envoyé la recherche vers une table qui n’a pas de route.
IPv6 a été sélectionné mais le routage IPv6 manque (ou les RA sont désactivées), donc le v6 semble inaccessible même si le v4 fonctionne.

Un changement d’état d’esprit opérationnel : ne « vérifiez pas le réseau ». Vérifiez la décision de routage. Linux vous dira exactement ce qu’il pense. Il faut juste poser la bonne question.

Blague #1 : La table de routage ressemble aux organigrammes d’entreprise : tout le monde affirme qu’elle est exacte, et tout le monde a tort jusqu’à ce que quelque chose casse.

Sérum de vérité de la table de routage : comment Linux décide

Si vous retenez une commande de tout cet article, que ce soit celle-ci :

cr0x@server:~$ ip route get 1.1.1.1
1.1.1.1 via 192.0.2.1 dev ens18 src 192.0.2.10 uid 1000
    cache

ip route get est votre sérum de vérité. Il force le noyau à effectuer la même recherche de route qu’il fera pour le trafic réel, et affiche le saut suivant choisi, l’interface de sortie et la sélection d’adresse source.

Trois points clés qui surprennent souvent des personnes intelligentes :

Le noyau choisit une IP source. Si cette IP source est incorrecte (mauvais sous-réseau, dépréciée, ou provenant d’un VRF/table différente), les réponses ne reviendront pas. Parfois le symptôme est « inaccessible », parfois c’est un timeout. Dans tous les cas, lisez le src.
Les règles peuvent surclasser les routes. La route que vous voyez dans main n’est pas nécessairement celle utilisée. ip rule peut envoyer le trafic vers une table différente selon la source, fwmark, UID ou d’autres sélecteurs.
Les métriques décident des confrontations. Plusieurs routes par défaut sont courantes sur les portables (Wi‑Fi + VPN + Docker + outils « utiles »). Le noyau choisira la métrique la plus basse qui correspond, pas celle que vous aviez en tête.

La pile de décision de routage (à grandes lignes)

Pour la plupart des hôtes Ubuntu 24.04, le chemin ressemble à ceci :

L’application demande une connexion ; le noyau construit un tuple de flux (dst, src si lié, mark, etc.).
La liste ip rule est consultée de haut en bas. Chaque règle choisit une table de routage (ou dit « prohibit »).
Une route correspondante est trouvée : route hôte exacte, puis préfixe plus spécifique, puis défaut.
Le saut suivant est résolu : une route directement connectée utilise ARP/NDP pour le voisin L2 ; via une passerelle utilise ARP/NDP pour la passerelle.
Puis on arrive enfin aux vérifications « l’interface est-elle up », « y a‑t‑il du carrier », « le voisin se résout‑il ».

Donc : si vous voyez « Réseau inaccessible », vous échouez avant la résolution du voisin. Votre mission est de trouver quelle recherche n’a produit aucune route utilisable — et pourquoi.

Il y a une idée paraphrasée de Werner Vogels qui convient aux opérations : Tout échoue, tout le temps ; votre travail est de concevoir pour cela (paraphrase). Le routage est une de ces couches qui « échouent tout le temps » — silencieusement, jusqu’à ce que ça ne marche plus.

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

Quand vous êtes sur un pager, vous ne voulez pas un séminaire réseau. Vous voulez un chemin rapide jusqu’au goulot d’étranglement. Voici l’ordre qui fait gagner le plus de temps en pratique.

Premier : demandez au noyau ce qu’il ferait

ip route get <dst> pour l’adresse IP exacte de destination. Si cela affiche une erreur, le routage manque. Si cela choisit une interface ou une IP source inattendue, le routage existe mais est erroné.
ip rule pour voir si le policy routing dévie votre trafic vers une table que vous aviez oubliée.

Deuxième : vérifiez les bases qui créent les routes

ip addr sur l’interface choisie : adresse correcte ? longueur de préfixe correcte ? pas en tentative ?
ip route et ip -6 route : avez‑vous une route par défaut ? est‑elle dans la table que vous utilisez vraiment ?
État Netplan/NetworkManager/systemd-networkd : la source de configuration applique‑t‑elle réellement ce que vous pensez ?

Troisième : ensuite seulement, poursuivez les problèmes L2 et externes

ip neigh / ip -6 neigh : pouvez‑vous résoudre l’adresse MAC de la passerelle ?
ping la passerelle et un hôte sur le lien.
tcpdump uniquement quand vous avez besoin de preuves, pas pour faire de la thérapie.

Le playbook est volontairement axé sur le routage. « Réseau inaccessible » est généralement le noyau qui vous dit qu’il n’a même pas essayé d’envoyer.

Tâches pratiques : commandes, sorties, décisions (12+)

Voici les tâches que j’exécute en production. Chacune a trois parties : la commande, ce que signifie une sortie typique et la décision à prendre ensuite.

Tâche 1 : Reproduire l’erreur avec une IP, pas un nom

cr0x@server:~$ ping -c 1 1.1.1.1
ping: connect: Network is unreachable

Ce que cela signifie : Pas le DNS. Pas le pare‑feu. La recherche de route du noyau a échoué (ou une route unreachable/prohibit existe).

Décision : Allez directement à ip route get et ip rule. Ne perdez pas de temps sur resolv.conf.

Tâche 2 : Demander la décision de route au noyau

cr0x@server:~$ ip route get 1.1.1.1
RTNETLINK answers: Network is unreachable

Ce que cela signifie : Les tables de routage consultées (sous la politique actuelle) ne produisent pas de route utilisable.

Décision : Inspectez d’abord le policy routing (ip rule), puis les tables de routage (ip route show table ...).

Tâche 3 : Vérifier les règles de policy routing (le coupable habituel du « ça marchait hier »)

cr0x@server:~$ ip rule
0:      from all lookup local
100:    from 10.10.0.0/16 lookup 100
32766:  from all lookup main
32767:  from all lookup default

Ce que cela signifie : Le trafic provenant de 10.10.0.0/16 utilise la table 100. Si votre appli lie cette source (ou si le noyau la choisit), vous pourriez router dans un univers parallèle.

Décision : Vérifiez les routes de la table 100. Si elle est vide ou sans défaut, vous avez trouvé votre « inaccessible ».

Tâche 4 : Montrer les routes dans la table main (IPv4)

cr0x@server:~$ ip route
192.0.2.0/24 dev ens18 proto kernel scope link src 192.0.2.10

Ce que cela signifie : Vous n’avez qu’une route connectée. Pas de route par défaut. L’hôte peut parler à son propre sous‑réseau, et c’est tout.

Décision : Ajouter/corriger la passerelle par défaut via Netplan/NetworkManager, pas à la main (sauf en triage).

Tâche 5 : Afficher les routes dans une table spécifique (table de policy routing 100)

cr0x@server:~$ ip route show table 100
10.10.0.0/16 dev wg0 proto kernel scope link src 10.10.0.5

Ce que cela signifie : La table 100 n’atteint que le sous‑réseau VPN. Si la table 100 est utilisée pour le trafic vers Internet, vous obtiendrez « inaccessible ».

Décision : Soit ajoutez une route par défaut à la table 100 (si c’est intentionnel), soit corrigez la règle qui envoie le trafic là‑dessus.

Tâche 6 : Confirmer que la route par défaut existe (et qu’elle ne concurrence pas)

cr0x@server:~$ ip route show default
default via 192.0.2.1 dev ens18 proto dhcp src 192.0.2.10 metric 100
default via 198.51.100.1 dev ens19 proto dhcp src 198.51.100.10 metric 50

Ce que cela signifie : Deux routes par défaut. Le noyau préférera la métrique 50 (ens19). Cela peut être un réseau déconnecté, un VLAN de gestion, ou un uplink mort.

Décision : Décidez quelle interface doit posséder la route par défaut. Corrigez les métriques ou supprimez la route par défaut indésirable au niveau de la configuration.

Tâche 7 : Voir les adresses et préfixes (mauvais masque = chaos silencieux)

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens18            UP             192.0.2.10/32 fe80::a00:27ff:fe4e:66a1/64

Ce que cela signifie : Un /32 sur une interface LAN est presque jamais correct sauf pour du routage point‑à‑point avec des routes explicitement on‑link. Avec /32, le noyau ne considérera pas la passerelle comme on‑link sauf si on le lui dit.

Décision : Corrigez la longueur de préfixe dans Netplan/DHCP. En solution temporaire, vous pouvez ajouter une route on‑link pour la passerelle (mais vous devriez être légèrement honteux).

Tâche 8 : Vérifier si la passerelle est considérée on‑link

cr0x@server:~$ ip route get 192.0.2.1
RTNETLINK answers: Network is unreachable

Ce que cela signifie : Même l’adresse de la passerelle n’est pas atteignable. Classique erreur de longueur de préfixe ou route connectée manquante.

Décision : Corrigez d’abord l’adressage ; le routage en dépend.

Tâche 9 : Si les routes semblent correctes, vérifiez l’état du voisin L2 pour la passerelle

cr0x@server:~$ ip neigh show dev ens18
192.0.2.1 lladdr 00:11:22:33:44:55 REACHABLE

Ce que cela signifie : La résolution ARP fonctionne. Si vous ne pouvez toujours pas atteindre des destinations hors‑sous‑réseau, le problème est en amont (routage/NAT/pare‑feu de la passerelle) ou le policy routing.

Décision : Pinguez la passerelle, puis tracez les décisions de routage au‑delà. Si le voisin est FAILED, concentrez‑vous sur VLANs, configuration de bridge, câblage ou contrôles de sécurité.

Tâche 10 : Vérification rapide de l’état du lien et des compteurs du pilote

cr0x@server:~$ ip -s link show dev ens18
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 08:00:27:4e:66:a1 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    1249389   15234      0       0       0     123
    TX:  bytes packets errors dropped carrier collsns
     893221   10112      0       0       0       0       0

Ce que cela signifie : LOWER_UP indique le carrier. Les erreurs/collisions/drops vous donnent un test rapide pour des problèmes physiques ou des switches virtuels.

Décision : Si le carrier est down, arrêtez l’analyse de routage et réparez le lien. Si le carrier est up et que les compteurs sont propres, revenez au routage/policy.

Tâche 11 : Inspecter la config générée par Netplan (attraper les divergences entre intention et réalité)

cr0x@server:~$ sudo netplan get
network:
  version: 2
  ethernets:
    ens18:
      dhcp4: true

Ce que cela signifie : Votre système attend DHCP pour IPv4. Si aucune route par défaut n’existe, le serveur DHCP peut ne pas fournir l’option routeur, ou le client ne l’applique pas.

Décision : Confirmez le renderer et les logs (NetworkManager vs systemd-networkd), puis vérifiez les détails du bail DHCP.

Tâche 12 : Identifier le renderer et la pile réseau active

cr0x@server:~$ networkctl status -n0
WARNING: systemd-networkd is not running, output will be incomplete.

Ce que cela signifie : systemd-networkd n’est probablement pas le renderer actif. NetworkManager l’est probablement (commun sur les desktops ; parfois sur les serveurs aussi).

Décision : N’éditez pas l’outil qui ne gère pas l’interface. Si NM gère, modifiez NM ; si networkd gère, modifiez networkd.

Tâche 13 : Vérifier l’état du périphérique et de la connexion dans NetworkManager

cr0x@server:~$ nmcli -f GENERAL.STATE,GENERAL.CONNECTION,IP4.GATEWAY,IP4.ROUTE dev show ens18
GENERAL.STATE:                         100 (connected)
GENERAL.CONNECTION:                    Wired connection 1
IP4.GATEWAY:                           --
IP4.ROUTE[1]:                          dst = 192.0.2.0/24, nh = 0.0.0.0, mt = 100

Ce que cela signifie : Connecté mais sans passerelle. C’est exactement comme on obtient « Réseau inaccessible » pour le trafic hors‑sous‑réseau.

Décision : Corrigez le profil de connexion (passerelle, options DHCP, ou drapeaux « never‑default »). Redémarrer l’interface n’inventera pas une passerelle.

Tâche 14 : Inspecter les informations de bail DHCP pour l’option routeur

cr0x@server:~$ journalctl -u NetworkManager -b | tail -n 8
Dec 30 10:14:22 server NetworkManager[1023]: <info>  [1735553662.1234] dhcp4 (ens18): option routers: (none)
Dec 30 10:14:22 server NetworkManager[1023]: <info>  [1735553662.1236] dhcp4 (ens18): option subnet_mask: 255.255.255.0
Dec 30 10:14:22 server NetworkManager[1023]: <info>  [1735553662.1238] dhcp4 (ens18): state changed bound -> bound

Ce que cela signifie : Le serveur DHCP n’a pas fourni de routeur (passerelle). Votre hôte se comporte correctement ; le réseau ne l’est pas.

Décision : Escaladez vers les propriétaires du réseau/DHCP, ou définissez une passerelle statique si ce segment l’exige.

Tâche 15 : Triage temporaire — ajouter une route par défaut (ne confondez pas triage et correctif)

cr0x@server:~$ sudo ip route add default via 192.0.2.1 dev ens18 metric 100

cr0x@server:~$ ip route get 1.1.1.1
1.1.1.1 via 192.0.2.1 dev ens18 src 192.0.2.10 uid 0
    cache

Ce que cela signifie : Vous avez rétabli le routage pour l’instant.

Décision : Implémentez immédiatement le changement permanent dans Netplan/NM. Les routes manuelles disparaissent au redémarrage et lors des redémarrages réseau, ce qui réserve des surprises à 02:00.

Tâche 16 : Prouver si le policy routing sélectionne une table différente selon la source

cr0x@server:~$ ip route get 1.1.1.1 from 10.10.0.5
RTNETLINK answers: Network is unreachable

Ce que cela signifie : Avec la source 10.10.0.5 (probablement une interface VPN), la recherche échoue. C’est un problème de policy routing, pas « Internet en panne ».

Décision : Corrigez ip rule et les routes de la table. Beaucoup de clients VPN installent des règles qui ont du sens pour des portables mais du sens pourris pour des serveurs.

Tâche 17 : Confirmer que le reverse path filtering ne se fait pas passer pour un échec de routage

cr0x@server:~$ sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.ens18.rp_filter
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.ens18.rp_filter = 1

Ce que cela signifie : Un rp_filter strict peut droper les réponses dans des scénarios de routage asymétrique. Il cause typiquement des timeouts, mais parfois vous verrez des erreurs ICMP confuses selon le chemin.

Décision : Si vous avez du multi‑homing, du policy routing ou des VRF, envisagez 2 (loose) pour les interfaces concernées, mais faites‑le de façon intentionnelle et documentez pourquoi.

Erreurs courantes : symptôme → cause racine → correction

1) « ping: connect: Network is unreachable » vers toute IP hors‑sous‑réseau

Symptôme : Peut pinger sa propre IP et peut‑être la passerelle, mais ne peut pas pinger des IP publiques.

Cause racine : Route par défaut manquante (option routeur absente du DHCP, configuration statique incomplète, ou renderer inapproprié).

Correction : Ajoutez la bonne passerelle par défaut dans le système de configuration réel (Netplan/NM/systemd‑networkd). Vérifiez avec ip route show default et ip route get.

2) « Réseau inaccessible » seulement pour certaines sources / uniquement dans des conteneurs

Symptôme : L’hôte peut atteindre la destination, mais le trafic d’une adresse source spécifique (VPN, conteneur, NIC secondaire) est inaccessible.

Cause racine : Une règle de policy routing envoie ce trafic dans une table vide, ou la table manque de route par défaut.

Correction : Auditez ip rule, puis ip route show table X. Ajoutez les routes manquantes à cette table ou retirez/ajustez la règle.

3) La route par défaut existe, mais « inaccessible » persiste pour un préfixe spécifique

Symptôme : L’Internet fonctionne, mais un certain préfixe RFC1918 ou un sous‑réseau d’entreprise est « inaccessible ».

Cause racine : Une route unreachable existe pour ce préfixe (parfois installée par des clients VPN, des outils kube ou des agents de sécurité) ou une route plus spécifique et incorrecte écrase le défaut.

Correction : Recherchez le préfixe spécifique : ip route show match 10.0.0.0/8. Supprimez ou corrigez la route à sa source (profil de connexion, script VPN, netplan).

4) « Réseau inaccessible » après changement de netmask/préfixe

Symptôme : Vous avez changé /24 en /32 (ou inverse) et maintenant la passerelle est « inaccessible ».

Cause racine : Le noyau ne considère pas la passerelle comme on‑link ; la route connectée ne couvre pas l’IP de la passerelle.

Correction : Corrigez la longueur de préfixe. Si vous avez vraiment besoin d’un /32, ajoutez une route on‑link explicite vers la passerelle et une route par défaut via celle‑ci (et préparez‑vous à expliquer ce choix plus tard).

5) Deux NICs, deux défauts, accessibilité intermittente

Symptôme : Ça fonctionne, puis ça cesse, surtout après reboot ou renouvellement DHCP.

Cause racine : Routes par défaut concurrentes avec métriques variables ; le noyau choisit un chemin egress différent de celui attendu.

Correction : Définissez explicitement les métriques et attribuez la « propriété » de la route par défaut. Sur les serveurs, soyez ennuyeux : une seule route par défaut, des routes explicites pour le reste.

6) Destinations IPv6 inaccessibles alors que IPv4 fonctionne (ou inversement)

Symptôme : Curl vers un nom d’hôte échoue rapidement avec inaccessible ; forcer IPv4 fonctionne.

Cause racine : IPv6 est préféré mais il n’y a pas de route par défaut IPv6 (RA manquantes, accept_ra désactivé, ou pare‑feu bloquant NDP/RA).

Correction : Configurez correctement le routage IPv6 (RA/DHCPv6/statique) ou désactivez IPv6 pour l’interface/le service. Ne le laissez pas à moitié configuré.

7) « Inaccessible » dans un namespace / VRF mais pas sur l’hôte

Symptôme : L’hôte peut atteindre, mais le netns ou VRF ne peut pas.

Cause racine : Tables de routage séparées par namespace/VRF ; vous avez corrigé la table main de l’hôte mais pas celle du namespace.

Correction : Exécutez ip route dans le namespace ou le VRF concerné et configurez les routes là‑bas.

Spécificités Ubuntu 24.04 : Netplan, NetworkManager, systemd-networkd

Ubuntu a une idée élégante et une réalité moins propre : Netplan est un front‑end déclaratif, et le renderer backend est soit NetworkManager soit systemd‑networkd. Sur Ubuntu 24.04, les deux sont courants selon que vous êtes sur un poste de travail, une image cloud, ou un « serveur » sur lequel quelqu’un a installé une GUI parce qu’il aime cliquer.

Règle opérationnelle : ne corrigez pas le routage dans la mauvaise couche. Si NetworkManager possède l’interface, éditer une unité networkd ne changera rien. Si networkd la possède, les changements nmcli ne tiendront pas.

Comment savoir qui gère quoi

Commencez par les services :

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

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

Décision : Si NetworkManager est actif et networkd inactif, traitez NM comme la source de vérité pour la config runtime. Netplan peut encore générer la config NM.

Appliquer Netplan en toute sécurité

Quand vous changez Netplan, utilisez try sur des machines distantes. Il annule automatiquement si vous perdez la connectivité. C’est la chose la plus proche d’une ceinture de sécurité en réseau Linux.

cr0x@server:~$ sudo netplan try
Do you want to keep these settings?

Press ENTER before the timeout to accept the new configuration

Changes will revert in 120 seconds

Décision : Si vous êtes connecté en SSH via l’interface que vous modifiez, utilisez try. Si vous aimez vivre dangereusement, utilisez apply et profitez de votre promenade jusqu’au datacenter.

Pièges courants de Netplan

Passerelle manquante : le DHCP ne la fournit pas, ou vous avez utilisé une configuration statique sans routes ni gateway4.
Mauvais renderer : la configuration semble correcte mais n’est pas appliquée.
Métriques : Netplan supporte les métriques de route ; si vous ne les définissez pas sur les systèmes multi‑NIC, vous laissez les valeurs par défaut au hasard.

Blague #2 : Modifier la config réseau via SSH est un excellent exercice de pleine conscience. On devient très présent quand l’invite cesse de répondre.

Pièges spécifiques à IPv6 pour « inaccessible »

Ubuntu 24.04 a généralement IPv6 activé par défaut. C’est bien. Le piège est l’IPv6 partiellement configuré : des adresses existent, mais le routage non, donc les applications qui préfèrent IPv6 échouent rapidement.

Tâche : Voir les routes IPv6 et si un défaut existe

cr0x@server:~$ ip -6 route show default
default via fe80::1 dev ens18 proto ra metric 100 pref medium

Ce que cela signifie : Vous avez une route par défaut IPv6 apprise via Router Advertisement (RA). Si elle manque, le trafic IPv6 peut être inaccessible.

Décision : Si vous avez besoin d’IPv6, assurez‑vous que les RA sont acceptées (accept_ra) et que le pare‑feu ne bloque pas RA/NDP. Si vous n’avez pas besoin d’IPv6, désactivez‑le explicitement par interface ou via sysctl — ne le laissez pas à moitié activé.

Tâche : Forcer IPv4 pour valider l’hypothèse

cr0x@server:~$ curl -4 -sS --connect-timeout 3 https://example.com
<html>...</html>

Ce que cela signifie : Le chemin IPv4 est OK ; IPv6 est la jambe cassée.

Décision : Corrigez le routage IPv6 ou ajustez la sélection d’adresse / désactivez IPv6 pour le chemin de service. Ne blâmez pas « Internet ».

Tâche : Vérifier l’état NDP du voisin pour la passerelle par défaut

cr0x@server:~$ ip -6 neigh show dev ens18
fe80::1 lladdr 00:11:22:33:44:55 router REACHABLE

Ce que cela signifie : L’adjacence L2 pour IPv6 est saine. Si l’inaccessibilité persiste, concentrez‑vous sur routes/règles ou l’amont.

Décision : Si le voisin est FAILED ou INCOMPLETE, dépannez VLANs, filtrage RA ou fonctionnalités de sécurité du switch.

Policy routing et tables multiples (les vrais problèmes)

Le policy routing est l’endroit où les réseaux simples deviennent « intéressants ». C’est aussi l’endroit où « Réseau inaccessible » est mal diagnostiqué comme un problème de câblage, parce que quelqu’un regarde seulement ip route (table main) et déclare que tout va bien.

Comment le policy routing crée de l’inaccessible

Imaginez :

Vous avez une interface VPN wg0 avec 10.10.0.5/16.
Une règle dit : « From 10.10.0.0/16, lookup table 100. »
La table 100 n’a que le sous‑réseau VPN connecté, pas de route par défaut.

Tout flux ayant la source 10.10.0.5 ne peut plus atteindre Internet. Le noyau interroge la table 100, ne trouve rien, et dit « Network is unreachable ». C’est un comportement correct. Votre conception est incomplète.

Tâche : Dumper toutes les priorités de règles (l’ordre compte)

cr0x@server:~$ ip -details rule
0:      from all lookup local
100:    from 10.10.0.0/16 lookup 100
32766:  from all lookup main
32767:  from all lookup default

Ce que cela signifie : Le noyau atteindra la priorité 100 avant main. Si elle correspond, main est sans objet.

Décision : Corrigez la règle ou complétez la table. Ne vous contentez pas « d’ajouter une route par défaut à main » en espérant que ça suffise.

Tâche : Montrer les types de route qui bloquent explicitement le trafic

cr0x@server:~$ ip route show type unreachable
unreachable 10.0.0.0/8 metric 1024

Ce que cela signifie : Le système refuse intentionnellement de router ce préfixe. Cela peut être un artefact de durcissement de sécurité, un client VPN « pour vous protéger », ou un pansement d’un incident ancien jamais retiré.

Décision : Identifiez qui l’a installé (connexion NM, netplan, scripts, agent de sécurité). Supprimez‑le à la source, pas manuellement, sauf en triage d’urgence.

Tâche : Vérifier la sélection par fwmark (si vous utilisez des marquages nftables/iptables)

cr0x@server:~$ ip rule | grep -n fwmark
12:200:  from all fwmark 0x1 lookup 200

Ce que cela signifie : Le trafic marqué utilise la table 200. Si la table 200 manque de route, les flux marqués sont inaccessibles tandis que les flux non marqués fonctionnent.

Décision : Confirmez vos règles de marquage de pare‑feu, et assurez‑vous que la table 200 a une route par défaut ou des préfixes appropriés.

Trois mini‑histoires du monde de l’entreprise (anonymisées)

Incident causé par une fausse hypothèse : « DHCP fournit toujours une passerelle »

Dans une entreprise moyenne, une équipe a déployé une nouvelle image Ubuntu 24.04 pour des agents de build. Ces machines vivaient sur un VLAN « outils » historiquement en adressage statique. Quelqu’un a migré le VLAN vers DHCP pour réduire le travail manuel, et tout le monde s’est réjoui parce que les tableurs ne sont pas de l’infrastructure.

L’image utilisait DHCP, a pris une adresse et a déclaré « connecté ». Mais les builds ont commencé à échouer dès qu’ils devaient récupérer des dépendances depuis Internet. L’erreur était immédiate : « Network is unreachable ». Les ingénieurs ont d’abord supposé que le proxy était en panne, puis accusé le DNS, puis l’équipe pare‑feu (toujours un favori).

Le problème réel était banal : le scope DHCP a fourni une IP et un masque, mais pas l’option routeur. La moitié du parc ne l’a jamais remarqué car ils étaient encore statiques ou avaient des routes en cache ; les nouveaux agents de build étaient les seuls assez « propres » pour échouer systématiquement.

La solution n’était pas héroïque. Ils l’ont confirmé dans les logs (« option routers: (none) »), ajouté l’option routeur au scope DHCP, et le problème a disparu. Après l’incident, la leçon est devenue un élément de checklist : les nouveaux sous‑réseaux doivent être validés pour IP, masque, routeur, DNS et MTU — pas seulement « DHCP marche ».

Optimisation qui a mal tourné : « Deux défauts pour la redondance »

Une autre équipe avait des serveurs doublement connectés : une interface sur le réseau de production, une sur le réseau de gestion. Quelqu’un a décidé d’être malin et a ajouté une route par défaut sur l’interface de gestion « au cas où la production tombe ». Redondance, non ?

Ça a marché pendant les heures calmes. Puis une fenêtre de maintenance a introduit une perte de paquets mineure sur l’uplink de production. Linux, rationnel et non romantique, a continué à sélectionner la route par défaut à métrique la plus basse — qui a basculé après un renouvellement DHCP. Certains serveurs ont commencé à envoyer du trafic de production via l’interface de gestion. Le trafic de retour ne correspondait pas. rp_filter a droppé des paquets. Les clients ont vu des défaillances intermittentes presque impossibles à reproduire en labo.

L’optimisation n’a pas créé de redondance. Elle a créé de la non‑déterminisme. Et le non‑déterminisme est juste de l’instabilité en costume.

La correction a été ennuyeuse mais correcte : une seule route par défaut, toujours ; routes explicites pour la gestion ; et métriques documentées et verrouillées dans la configuration. « Redondance » est devenue un vrai design de routage (basculement avec protocoles ou changements monitorés), pas une paire de défauts concurrents qui espèrent bien se comporter.

Pratique ennuyeuse mais correcte qui a sauvé la mise : « ip route get comme procédure standard »

Dans une entreprise avec beaucoup de Kubernetes, des nœuds rapportaient parfois « Network is unreachable » en tirant des images. L’instinct initial était de blâmer le registre ou le DNS. Mais l’équipe SRE avait une habitude : chaque plainte réseau commence par ip route get.

Cette habitude a payé. Sur un nœud affecté, ip route get montrait un egress via une interface créée par le CNI, avec une adresse source appartenant à un sous‑réseau de pod. Cela n’aurait jamais dû arriver pour le trafic de l’hôte. L’équipe a immédiatement pivoté vers les règles de policy routing et a trouvé une règle obsolète d’un ancien agent VPN qui matchait trop large.

Ils ont retiré l’agent, nettoyé la règle, puis ajouté un contrôle de type test unitaire à la provisioning des nœuds : s’assurer que l’egress par défaut de l’hôte utilise la NIC principale et la source attendue. Rien de glamour — juste une porte qui attrape la dérive avant qu’elle ne devienne une panne.

Ce n’était pas glorieux, mais ça a évité une longue chasse aux paquets et aux accusations. L’ennui est une fonctionnalité en opérations.

Faits intéressants et points d’histoire rapide

Linux « iproute2 » a remplacé « net‑tools » (comme route, ifconfig) parce que le routage moderne nécessite des règles policy, des tables multiples et une meilleure visibilité.
ip route get reflète la recherche FIB du noyau et inclut la sélection de source — quelque chose que les anciens outils révélaient à peine.
Les métriques de route ne sont pas un tiebreaker ; elles décident lorsque plusieurs routes correspondent. La plus petite métrique l’emporte, même si cela rend les humains tristes.
Linux prend en charge des types de route comme blackhole, unreachable et prohibit pour bloquer intentionnellement le trafic au niveau routage, pas au niveau pare‑feu.
Le policy routing via ip rule existe depuis des décennies, largement utilisé par les FAI et les systèmes multi‑homés bien avant que le « cloud networking » ne le remette en lumière.
Les routes par défaut IPv6 viennent souvent des Router Advertisements, pas du DHCP. Bloquer ICMPv6 peut casser silencieusement le routage, pas seulement le « ping ».
Le reverse path filtering (rp_filter) a été conçu pour atténuer le spoofing mais interagit mal avec le routage asymétrique sauf s’il est ajusté volontairement.
Les network namespaces signifient que chaque namespace a ses propres tables de routage. Corriger l’hôte ne corrige pas un namespace conteneur, et vice‑versa.

Listes de contrôle / plan étape par étape

Checklist A : Quand vous voyez « Réseau inaccessible » sur Ubuntu 24.04

Reproduisez avec une IP : ping -c 1 1.1.1.1.
Exécutez ip route get 1.1.1.1.
Si cela renvoie une erreur : inspectez ip rule, puis ip route (et les tables spécifiques).
Si cela renvoie une route : confirmez que dev et src sont ceux attendus.
Vérifiez les routes par défaut : ip route show default. Éliminez les ambiguïtés.
Vérifiez adresses/longueurs de préfixe : ip -br addr.
Vérifiez le voisin vers la passerelle : ip neigh show dev <dev>.
Confirmez quel renderer applique la config : systemctl is-active NetworkManager et systemctl is-active systemd-networkd.
Appliquez la correction dans la couche de configuration propriétaire (Netplan/NM/networkd), pas avec des commandes ponctuelles.
Retestez avec ip route get et une connexion réelle (curl -4/curl -6 selon le cas).

Checklist B : Corrections permanentes (choisissez votre outil et engagez‑vous)

Si vous utilisez Netplan + networkd : définissez routes statiques/passerelle dans le YAML Netplan, puis sudo netplan apply.
Si vous utilisez Netplan + NetworkManager : éditez le YAML Netplan ou les profils de connexion NM, mais ne mélangez pas des routes manuelles avec des profils persistants.
Si vous avez plusieurs uplinks : définissez explicitement les métriques de route et ajoutez des routes explicites pour les réseaux non‑par défaut.
Si vous utilisez des VPNs : vérifiez que les tables de policy routing contiennent une route par défaut si vous attendez un full‑tunnel, ou des routes restreintes si split‑tunnel.
Si vous exécutez des conteneurs : validez que le routage de l’hôte n’est pas affecté par erreur par CNI, Docker ou des agents de sécurité qui ajoutent règles/routes.

FAQ

1) Pourquoi « Réseau inaccessible » arrive alors que l’interface est UP ?

Parce que l’état du lien n’est pas l’état de routage. L’interface peut être UP avec une IP valide et pourtant ne pas avoir de route par défaut, avoir un mauvais netmask, ou des règles policy envoyant le trafic dans une table vide.

2) Quelle est la commande la plus rapide pour diagnostiquer cela ?

ip route get <destination-ip>. Si cela renvoie une erreur, la recherche de routage a échoué. Si cela renvoie une route, lisez dev et src et validez qu’ils ont du sens.

3) J’ai une route par défaut, pourquoi c’est toujours inaccessible ?

Soit une route plus spécifique l’écrase (y compris unreachable/blackhole), soit le policy routing envoie la recherche vers une table différente. Vérifiez ip rule et cherchez des routes pour le préfixe de destination.

4) Comment savoir si IPv6 est la raison pour laquelle mon nom d’hôte échoue ?

Forcez IPv4 : curl -4 ou ping -4. Si IPv4 fonctionne et que l’appel normal échoue rapidement, votre système peut sélectionner IPv6 sans route par défaut IPv6 valide.

5) Ajouter une route par défaut avec `ip route add default` est‑ce une correction valide ?

C’est valide en triage. Ce n’est pas une correction durable. La route disparaîtra au redémarrage et peut être écrasée par des renouvellements DHCP ou des redémarrages réseau. Rendre le changement persistant via Netplan/NetworkManager/networkd.

6) Quelle est la différence entre « Network is unreachable » et « Destination Host Unreachable » ?

« Network is unreachable » signifie typiquement que la recherche de route a échoué. « Destination Host Unreachable » signifie souvent qu’une route existe, mais que l’ARP/NDP ou le routage en aval a échoué, produisant un message ICMP unreachable.

7) Docker ou Kubernetes peuvent‑ils causer « Réseau inaccessible » sur l’hôte ?

Oui. Ils ajoutent des interfaces, des routes, et parfois des règles policy. La plupart du temps ils se comportent. Quand ce n’est pas le cas, vous verrez des entrées ip rule inattendues, des routes supplémentaires, ou une sélection de source pointant vers des réseaux CNI/Docker.

8) Pourquoi ça marche pour root mais pas pour un utilisateur de service (ou inversement) ?

Le policy routing peut matcher un UID (via ip rule uidrange) ou des fwmarks appliqués par cgroups/iptables/nftables. Vérifiez ip rule et si des règles spécifiques UID/marquage existent.

9) Et si la passerelle elle‑même est « inaccessible » ?

Cela signifie généralement que votre route connectée ne couvre pas l’IP de la passerelle (mauvais préfixe), ou que l’interface/l’adresse n’est pas configurée comme vous le pensez. Corrigez l’IP/préfixe d’abord ; le routage vient ensuite.

10) Dois‑je désactiver rp_filter pour résoudre cela ?

Seulement si vous comprenez votre histoire d’asymétrie de routage. Les problèmes liés à rp_filter se manifestent typiquement par des réponses droppées/timeouts plus que par des échecs de recherche de route. Ajustez‑le délibérément et documentez la raison.

Conclusion : étapes pratiques suivantes

« Réseau inaccessible » n’est pas une ambiance. C’est un verdict de routage. Traitez‑le comme tel.

La prochaine fois que vous le verrez sur Ubuntu 24.04, faites ceci :

Exécutez ip route get <dst> et croyez la sortie.
Vérifiez ip rule avant de vous extasier devant ip route et de déclarer victoire.
Corrigez la cause racine dans la couche de configuration propriétaire (Netplan/NetworkManager/systemd‑networkd), pas avec une ligne héroïque.
Sur des systèmes multi‑homés, rendez explicites les métriques de route et la propriété de la route par défaut. L’ambiguïté n’est pas de la redondance.
Si IPv6 est activé, configurez‑le correctement — ou désactivez‑le volontairement. L’IPv6 à moitié configuré est une source récurrente d’échecs rapides.

Faites cela, et « Réseau inaccessible » deviendra moins un mystère et plus un collègue utile : franc, précis, et parfois agaçant.