Debian/Ubuntu « Connecté, mais pas d’internet » : correctifs de routage, passerelle et routage par politique

décembre 2, 2025 • février 3, 2026 • Lecture : 26 min • Views: 9

Cet article vous a aidé ?

Vous pouvez SSH sur la machine depuis le VLAN local. Vous pouvez pinguer la passerelle. L’icône Wi‑Fi jure que tout va bien. Mais dès que vous lancez apt update, ouvrez une page web ou appelez une API externe : silence radio.

Ce mode de panne est l’équivalent réseau d’être enfermé dans le bureau alors que votre badge ouvre encore la porte du hall. La machine est « connectée »… à quelque chose. Juste pas à Internet. Le coupable est généralement le routage : la passerelle par défaut est mauvaise, absente, ou surclassée par un routage par politique que vous aviez oublié d’avoir.

Le modèle mental : les paquets ne croient pas votre interface

« Connecté » signifie généralement : le lien est actif, vous avez une adresse IP, et quelque chose a répondu au trafic local de base. Cela ne signifie pas que vos paquets sortants ont une route par défaut fonctionnelle, que les réponses reviendront par le même chemin, ou que le DNS résout comme vos applications en ont besoin.

Sur Debian/Ubuntu, « pas d’internet » se ramène généralement à l’un de ces cas :

Pas de route par défaut utilisable (manquante, pointant vers la mauvaise passerelle, ou avec une métrique incorrecte).
Routage asymétrique (les paquets sortent par une interface, les réponses reviennent par une autre et sont abandonnées par rp_filter, le pare-feu ou le suivi d’état).
Routage par politique (ip rules et tables choisissent une route différente de celle que vous pensez).
Mensonges DNS (résolution vers des adresses non routables, portails captifs, zones split-horizon obsolètes).
Problèmes MTU/PMTUD (handshakes TLS bloqués, pings fonctionnent, TCP cale).
Effets secondaires VPN/tunnel (un split tunnel mal configuré est simplement une panne complète avec des étapes en plus).

Soyez impitoyable pour séparer les couches : liaison, IP, routage, DNS et application. La plupart du temps est perdu quand les gens traitent tout cela comme une seule vibration.

Une citation pour vous garder honnête : « L’espoir n’est pas une stratégie. » — Gen. Gordon R. Sullivan

Blague #1 : Si votre route par défaut manque, vos paquets s’écrivent essentiellement « Retour à l’expéditeur » et se dirigent vers le vide.

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

Premier : confirmez ce que « pas d’internet » signifie pour les paquets

Pouvez-vous atteindre la passerelle locale ? Si non, arrêtez. Vous ne déboguez pas « internet ». Vous déboguez l’adjacence L2/L3.
Pouvez-vous atteindre une IP publique par son numéro ? Si oui mais que le DNS échoue, c’est le DNS. Si non, c’est le routage/pare-feu/MTU.
Quelle route le noyau choisit-il réellement ? Ne devinez pas. Demandez avec ip route get.

Second : isolez routage vs routage par politique vs NAT

Vérifiez la route par défaut et les métriques (ip route).
Vérifiez les règles de politique (ip rule) et les tables référencées (ip route show table X).
Vérifiez le filtrage du chemin inverse si vous avez plusieurs interfaces (sysctl net.ipv4.conf.*.rp_filter).

Troisième : testez les cas « durs » qui vous trompent

MTU / PMTUD : si ICMP fonctionne mais HTTPS bloque, testez avec des pings « do not fragment » et des tailles plus petites.
Paramètres proxy par application : curl fonctionne, le navigateur non — ou l’inverse.
Routes VPN/WireGuard : AllowedIPs ou les routes poussées peuvent remplacer votre route par défaut.

Faits intéressants et contexte historique (édition routage)

Le routage par politique sous Linux n’est pas nouveau. Le design à tables multiples (iproute2) existe depuis la fin des années 1990, et il est encore mal compris quotidiennement.
La « route par défaut » n’est qu’une route. Dans le noyau c’est typiquement 0.0.0.0/0 ou default — pas de magie, juste le match le moins spécifique.
Linux choisit les routes par le plus long préfixe, puis par métrique. C’est pour cela qu’une route plus spécifique peut écraser votre défaut, même si vous ne le vouliez pas.
Le filtrage du chemin inverse (rp_filter) a été conçu contre l’usurpation. Il casse les hôtes multi-homed si vous ne l’ajustez pas. Les fonctions de sécurité font souvent cela : utiles jusqu’à ce que la réalité s’agrandisse.
systemd-resolved a popularisé les résolveurs stub sur 127.0.0.53. Quand le DNS échoue, les gens blâment « 127.0.0.53 » comme s’il les avait personnellement insultés. En général ça va ; c’est l’amont qui pose problème.
Netplan est un générateur, pas un démon. Il écrit la configuration pour NetworkManager ou systemd-networkd. Déboguez le renderer, pas l’esthétique YAML.
IPv6 peut « gagner » de façon inattendue. Beaucoup de clients préfèrent IPv6 ; si votre routage IPv6 est cassé, vous avez des échecs lents qui ressemblent à des pertes de paquets.
Les guerres de route par défaut arrivent sur les portables. Branchez Ethernet, laissez le Wi‑Fi, ajoutez un VPN — maintenant vous avez trois prétendants pour la « défaut ». Le noyau en choisira un. Votre cerveau choisira le mauvais.

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

Voici les tâches que j’exécute réellement quand une machine dit être connectée mais se comporte comme sur une île déserte. Chaque tâche inclut : une commande, ce que signifie la sortie, et la décision à prendre.

Task 1: Verify link state and interface names

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
ens18            UP             52:54:00:12:34:56 <BROADCAST,MULTICAST,UP,LOWER_UP>
wlp2s0           DOWN           10:fe:ed:aa:bb:cc <NO-CARRIER,BROADCAST,MULTICAST,UP>

Signification : ens18 est up et a du carrier. wlp2s0 est administrativement up mais sans carrier (non associée).

Décision : Concentrez-vous sur ens18. Ne dépannez pas le DNS du Wi‑Fi quand le Wi‑Fi n’est même pas connecté.

Task 2: Confirm IP addressing and scope

cr0x@server:~$ ip -br addr show
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens18            UP             10.20.30.41/24 fe80::5054:ff:fe12:3456/64

Signification : Vous avez IPv4 10.20.30.41/24. Pas d’IPv6 globale, seulement link-local.

Décision : Pour les tests d’internet, utilisez IPv4 en premier pour réduire les variables. Si IPv6 est attendu, vous avez un problème séparé (RA/DHCPv6).

Task 3: Check the default route (the usual villain)

cr0x@server:~$ ip route show
10.20.30.0/24 dev ens18 proto kernel scope link src 10.20.30.41

Signification : Pas de default via .... Vous pouvez parler au sous‑réseau local et c’est tout.

Décision : Réparez la fourniture de gateway (DHCP, config statique, netplan, NM). Ne touchez pas au DNS pour l’instant.

Task 4: Ask DHCP what it thinks it gave you

cr0x@server:~$ sudo journalctl -u systemd-networkd --since "10 min ago" | tail -n 20
...ens18: DHCPv4 address 10.20.30.41/24 via 10.20.30.1
...ens18: Configured gateway: 10.20.30.1
...ens18: Setting route: dst: 0.0.0.0/0, gw: 10.20.30.1

Signification : networkd dit avoir configuré une route par défaut via 10.20.30.1, mais ip route ne l’affichait pas.

Décision : Suspectez un autre gestionnaire qui l’a écrasée, ou un routage par politique qui l’a déplacée dans une table non-main.

Task 5: Show routes in all tables (not just main)

cr0x@server:~$ ip route show table all | sed -n '1,120p'
default via 10.20.30.1 dev ens18 table 100
10.20.30.0/24 dev ens18 proto kernel scope link src 10.20.30.41
local 10.20.30.41 dev ens18 table local proto kernel scope host src 10.20.30.41
broadcast 10.20.30.255 dev ens18 table local proto kernel scope link src 10.20.30.41

Signification : La route par défaut existe, mais elle est dans la table 100, pas dans la table main.

Décision : Vérifiez ip rule pour voir quand la table 100 est utilisée. Si aucune règle ne correspond à votre trafic, vous êtes en « connecté mais pas d’internet ».

Task 6: Inspect policy rules and priorities

cr0x@server:~$ ip rule show
0:      from all lookup local
1000:   from 10.20.30.0/24 lookup 100
32766:  from all lookup main
32767:  from all lookup default

Signification : Seul le trafic provenant de 10.20.30.0/24 doit utiliser la table 100. Ça semble correct — sauf si votre adresse source est différente (conteneurs, marquages, adresses secondaires).

Décision : Testez la sélection de route réelle avec ip route get pour une IP externe et avec un from explicite.

Task 7: Ask the kernel which route it will take

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

Signification : Le noyau a choisi ens18 et la source 10.20.30.41. Si vous voyez « unreachable » ici, c’est fini : le routage est cassé.

Décision : Si ip route get est sain mais que le ping échoue, vérifiez le pare-feu/NAT en amont. Si c’est insensé, corrigez le routage localement.

Task 8: Test gateway reachability (L3 adjacency)

cr0x@server:~$ ping -c 2 10.20.30.1
PING 10.20.30.1 (10.20.30.1) 56(84) bytes of data.
64 bytes from 10.20.30.1: icmp_seq=1 ttl=64 time=0.341 ms
64 bytes from 10.20.30.1: icmp_seq=2 ttl=64 time=0.305 ms

--- 10.20.30.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1013ms
rtt min/avg/max/mdev = 0.305/0.323/0.341/0.018 ms

Signification : Vous pouvez atteindre la passerelle. L2/L3 vers le premier saut est OK.

Décision : Si l’internet est toujours mort, votre route par défaut, NAT, ou le routage en amont est en cause — pas le câblage.

Task 9: Test internet by IP (remove DNS from the story)

cr0x@server:~$ ping -c 2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=12.4 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=12.2 ms

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 12.2/12.3/12.4/0.1 ms

Signification : La connectivité brute vers Internet fonctionne.

Décision : Si les navigateurs/apt échouent encore, c’est le DNS, le proxy, le MTU, ou des restrictions au niveau applicatif.

Task 10: Check DNS resolution path (systemd-resolved aware)

cr0x@server:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 10.20.30.53
       DNS Servers: 10.20.30.53 10.20.30.54

Signification : Vous utilisez systemd-resolved en mode stub, avec des serveurs DNS en amont dans votre LAN.

Décision : Si la résolution échoue, testez ces serveurs DNS directement et confirmez l’existence des routes vers eux. Vérifiez aussi les domaines split DNS si un VPN est actif.

Task 11: Verify name resolution and distinguish SERVFAIL vs timeout

cr0x@server:~$ resolvectl query deb.debian.org
deb.debian.org: 2a04:4e42:83::644
               2a04:4e42:400::644
               151.101.130.132
               151.101.194.132
               151.101.66.132
               151.101.2.132

-- Information acquired via protocol DNS in 27.1ms.
-- Data is authenticated: no

Signification : Le DNS fonctionne et renvoie des enregistrements AAAA et A. Si ceci bloquait, suspectez la portée DNS. Si les IP retournées sont erronées, suspectez du split-horizon ou une interception captive.

Décision : Si le DNS fonctionne mais que HTTP échoue, passez aux vérifications MTU, proxy ou pare-feu.

Task 12: Trace the actual path (quick and dirty)

cr0x@server:~$ traceroute -n 1.1.1.1 | sed -n '1,8p'
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  10.20.30.1  0.410 ms  0.361 ms  0.342 ms
 2  198.51.100.1  2.103 ms  2.034 ms  2.012 ms
 3  203.0.113.9  6.821 ms  6.774 ms  6.736 ms
 4  1.1.1.1  12.504 ms  12.412 ms  12.380 ms

Signification : Vous avez un chemin au‑delà de la passerelle. Si ça meurt au saut 1, votre passerelle manque d’amont/NAT ou bloque ICMP TTL exceeded. Si ça meurt plus loin, c’est le routage/pare‑feu en amont.

Décision : Si le saut 1 va bien mais le saut 2+ meurt, escaladez à l’équipe réseau ou réparez votre NAT/routeur amont.

Task 13: Detect MTU blackholes (the “TLS hangs” classic)

cr0x@server:~$ ping -c 2 -M do -s 1472 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1400

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1007ms

Signification : Votre MTU d’interface est 1400 (ou le chemin impose 1400). Envoyer des trames 1500 avec DF échoue localement.

Décision : Réglez l’MTU correctement sur l’interface ou le tunnel. Si un VPN est impliqué, l’MTU du tunnel est généralement la contrainte réelle.

Task 14: Check reverse path filter when multi-homed

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

Signification : rp_filter strict est activé. Sur des hôtes multi-homed avec routage asymétrique, cela peut abandonner des réponses valides.

Décision : Si vous avez réellement besoin de multi‑homing/routage par politique, mettez rp_filter à 2 (loose) sur les interfaces concernées, ou concevez des routes pour éviter l’asymétrie.

Task 15: Confirm what manager is controlling the interface

cr0x@server:~$ networkctl status ens18 | sed -n '1,30p'
● 2: ens18
                     Link File: /usr/lib/systemd/network/99-default.link
                  Network File: /run/systemd/network/10-netplan-ens18.network
                          Type: ether
                         State: routable (configured)
                  Online state: online
                       Address: 10.20.30.41
                       Gateway: 10.20.30.1
                           DNS: 10.20.30.53

Signification : systemd-networkd possède cette interface, et netplan a généré sa config dans /run/systemd/network.

Décision : Ne « corrigez » pas cela avec NetworkManager à moins de vouloir des configurations rivales. Faites la correction dans netplan ou networkd, puis appliquez.

Échecs de routage qui ressemblent à « pas d’internet »

1) Passerelle par défaut manquante (le plus courant, le moins dramatique)

Si ip route manque d’un default via, vous n’avez pas d’accès Internet. Point final. Vous pouvez encore atteindre des hôtes locaux on‑link, ce qui nourrit l’illusion que « le réseau fonctionne ». Il ne fonctionne pas ; il est incomplet.

Voies de correction :

DHCP attendu : assurez‑vous que le client DHCP tourne sur la bonne interface et n’est pas bloqué. Vérifiez les logs pour « no DHCPOFFERS received ».
Statique attendu : configurez la passerelle explicitement dans netplan, ifupdown ou NetworkManager, mais dans un seul d’entre eux.

2) Deux passerelles par défaut, une mauvaise métrique

Les portables adorent ça. Les serveurs peuvent aussi quand quelqu’un ajoute une interface « temporaire » et l’oublie. Si vous avez deux défaults, Linux choisira selon la métrique (la plus basse est préférée) et les préférences de protocole. Votre trafic peut sortir via une interface qui ne fait pas de NAT, ne peut pas atteindre l’amont, ou est en quarantaine.

Les métriques ne sont pas consultatives. Elles tranchent pour décider si vos paquets vont par l’internet fonctionnel ou par un VLAN de gestion sans route vers le monde.

3) Une route par défaut existe, mais dans la mauvaise table

C’est le piège du routage par politique : ip route semble correct dans la table 100, mais votre trafic utilise la table main. Ou vice versa. La machine est « connectée » dans le sens où elle a des routes quelque part. Mais elles ne sont pas utilisées pour le trafic qui vous intéresse.

4) Routage asymétrique + rp_filter = « ça ping parfois »

Le routage asymétrique n’est pas automatiquement faux. Il est problématique quand votre hôte, ou quelque chose en amont, exige la symétrie. Linux avec rp_filter=1 strict abandonnera les paquets si le contrôle du chemin inverse échoue. Les pare‑feux stateful et les périphériques NAT amont peuvent aussi punir l’asymétrie.

Les symptômes sont amusants : des SYN sortent, des SYN‑ACK reviennent par une interface différente et disparaissent. Certaines destinations fonctionnent, d’autres non. Les gens blâment « l’internet ». L’internet est innocent.

5) MTU et PMTUD : la panne furtive

Un ping ICMP à 56 octets marche. Le DNS marche. Mais HTTPS reste bloqué. SSH se connecte parfois mais les transferts de fichiers stagnent. C’est souvent la découverte du MTU du chemin qui échoue — surtout à travers des tunnels ou des jumbo frames mal configurées.

Les réseaux modernes filtrent souvent ICMP de façon trop agressive. Cela casse PMTUD. Alors de gros paquets sont mis en quarantaine et TCP passe son temps à apprendre l’impuissance.

Routage par politique : le videur silencieux à la porte

Si vous n’avez jamais eu qu’une seule interface et une seule passerelle, vous pourriez ignorer le routage par politique pour toujours. Le moment où vous ajoutez un VPN, une seconde carte, un bridge de conteneur avec des règles spéciales, ou « juste un sous‑réseau de plus », le routage par politique arrive — silencieusement — et commence à décider quelle table est consultée pour quels paquets.

Les trois éléments à garder clairs

Règles (ip rule) : correspondent au trafic par source, destination, fwmark, iif, uidrange, etc., et choisissent une table de routage.
Tables (ip route show table X) : contiennent des routes, y compris des défauts. La table main n’est qu’une d’elles.
Sélection de route (ip route get) : ce que le noyau fait réellement pour un paquet donné.

Ce qui foire dans le monde réel

La règle correspond à la mauvaise source. Vous ajoutez une règle « from 10.0.0.0/24 lookup 100 » en supposant que le serveur utilise toujours 10.0.0.10. Puis Docker ou une IP secondaire devient la source pour une partie du trafic. Maintenant la moitié du trafic consulte la table main (sans défaut), l’autre moitié consulte la table 100 (avec défaut). C’est une panne partielle déguisée en hasard.

Les règles sont réordonnées. Les priorités comptent. Une règle large à priorité 100 peut ombrager une règle spécifique à 1000. Lisez toujours les priorités comme « le plus petit nombre gagne d’abord ». Ce n’est pas une suggestion ; c’est le flux de contrôle.

Des marques sans documentation. Quelqu’un a utilisé iptables -t mangle pour marquer des paquets pour un routage spécial. Puis cette personne a quitté l’entreprise. Maintenant votre hôte a un second univers de routage indexé par un hexadecimale que personne ne se rappelle.

Une approche sensée pour le multi-homing

Si vous avez réellement besoin de deux uplinks (par exemple un réseau de gestion et un uplink internet production), faites du routage basé sur la source intentionnellement :

Une table par uplink avec une route par défaut et des routes on‑link.
Une règle par préfixe source sélectionnant sa table.
Métriques explicites dans la table main pour éviter des défauts accidentels.
rp_filter correctement ajusté (2 est courant pour le multi‑homing, mais comprenez le compromis sécurité).

Blague #2 : Le routage par politique, c’est comme la politique de bureau — si vous ne savez pas qu’il existe, il décide déjà de votre futur.

Netplan, systemd-networkd, NetworkManager : qui détient la vérité ?

Ubuntu (et parfois les dérivés Debian) peut impliquer trois couches de « configuration réseau » que les gens confondent :

Netplan : YAML qui génère la config pour un renderer. Il ne gère pas les interfaces à l’exécution.
systemd-networkd : un gestionnaire réseau pour serveurs ; configuré via des fichiers .network et souvent alimenté par netplan.
NetworkManager : courant sur desktops, portables, et certains serveurs ; peut gérer Wi‑Fi, VPN et la mobilité.

Choisissez un renderer par interface. Ne faites pas de split‑brain. Si NetworkManager gère ens18 pendant que systemd-networkd pense aussi le gérer, vous aurez des fluctuations de route qui ressemblent à un « internet intermittent ». Ce n’est pas intermittent ; c’est réécriture continue.

Comment savoir lequel est actif

systemd-networkd : networkctl status affiche « configured » et pointe vers un Network File.
NetworkManager : nmcli dev status montre l’état ; les routes apparaissent souvent avec proto dhcp mais ce n’est pas exclusif.

Netplan : les deux lignes qu’on oublie

Pour IPv4 statique, vous avez besoin d’une adresse et d’une route. Les noms varient selon la version ; la façon moderne la plus portable est de définir explicitement la route par défaut via. Les exemples sont corrects, mais en production vérifiez ce que netplan a généré dans /run/systemd/network et ce que le noyau a installé dans ip route.

Quand vous changez netplan, appliquez‑le d’une manière qui ne vous isole pas à distance. netplan try existe pour une raison : il vous donne un timer de rollback si vous perdez la connectivité.

Trois mini-récits d’entreprise (anonymisés, plausibles et agaçants)

Mini-récit 1 : La panne causée par une mauvaise hypothèse

L’incident a commencé comme une migration de routine : une flotte de VMs Ubuntu déplacée d’un cluster d’hyperviseurs à un autre. Mêmes VLANs, mêmes plages IP, mêmes groupes de sécurité. Tout le monde était calme. C’était la première erreur.

En quelques minutes, des nœuds applicatifs ont commencé à échouer aux checks de santé. Le monitoring local pouvait les atteindre. Le SSH fonctionnait depuis le bastion du même sous‑réseau. Mais les applications ne pouvaient pas joindre les endpoints de paiement externes. « Connecté, mais pas d’internet » à grande échelle est une humiliation particulière.

L’équipe a supposé que la gateway par défaut était fournie par DHCP, parce que c’était le cas dans l’ancien cluster. Dans le nouveau cluster, l’équipe réseau avait déplacé ce sous‑réseau en adressage statique avec DHCP ne fournissant que des IPs (oui, ça existe), et l’option gateway manquait. Les VMs démarraient avec une adresse mais sans route par défaut.

Le diagnostic fut rapide dès que quelqu’un arrêta de regarder les dashboards et exécuta ip route sur une machine cassée. Pas de route par défaut. La correction fut tout aussi ennuyeuse : mettre à jour le provisioning pour définir explicitement la gateway (netplan dans ce cas) et redéployer. La vraie correction fut culturelle : arrêter de supposer que « DHCP signifie que vous recevez une gateway ». En général oui — jusqu’à ce que non.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Un ingénieur soucieux de performance a voulu « nettoyer le routage » sur un hôte Debian multi-homed. La machine avait deux NICs : une pour la gestion, une pour le trafic production, plus une interface VPN utilisée pour des APIs partenaires. Il y avait des années de crasses de routage accumulées.

L’optimisation : activer le filtrage strict du chemin inverse globalement (net.ipv4.conf.all.rp_filter=1) et supprimer ce qui ressemblait à des « routes dupliquées ». Le but était de réduire le risque d’usurpation et rendre le routage déterministe.

Ça a marché en labo. Puis en production. Soudain, seulement certains appels externes échouaient, et seulement depuis certaines adresses sources. Les pannes ressemblaient à des timeouts aléatoires. Des SYN TCP sortaient par la production, mais des réponses revenaient parfois via le VPN à cause du routage par politique et de routes spécifiques aux partenaires. Avec rp_filter strict, ces réponses furent abandonnées comme « martiennes ». Le système n’était pas attaqué ; il était sous‑spécifié.

Le postmortem fut court et sans romantisme : rp_filter strict va pour les systèmes single‑homed. Sur les systèmes multi‑homed avec chemins asymétriques, c’est un piège à moins de concevoir autour. Ils ont remis rp_filter=2 sur les interfaces concernées et documenté la politique de routage au lieu de l’optimiser en mystère.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe plateforme de stockage gérait un environnement mixte : Ubuntu pour les nœuds compute, Debian pour certains services infra, le tout avec un script standardisé de « sanity réseau » intégré à leur réponse incidents.

C’était ennuyeux. Il imprimait l’état des interfaces, les routes par défaut, les règles de politique, le statut DNS, et un ip route get pour une IP externe connue. Il capturait aussi des extraits de journalctl pour le renderer réseau actif. Personne ne s’en vantait. C’est comme ça qu’on sait que c’était bon.

Un après‑midi, un sous‑ensemble d’hôtes perdit l’accès internet après une mise à jour du client VPN. L’UI affichait « connected ». Le script montra immédiatement le vrai changement : une nouvelle ip rule avec une priorité plus haute que prévu, forçant la plupart du trafic dans une table avec une route par défaut via l’interface VPN. Le VPN n’était pas censé être un full tunnel et n’autorisait pas l’e‑gress internet général.

Parce qu’ils avaient la sortie du script avant et après, l’équipe put pointer un delta concret dans la politique de routage plutôt que se disputer sur « le DNS semble lent ». Le rollback fut propre. La correction long terme fut d’épingler les règles du VPN pour ne cibler que les préfixes partenaires. La pratique ennuyeuse sauva des heures car elle réduisit le problème à des faits que le noyau ne pouvait nier.

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

Symptôme : Peut pinguer la passerelle, ne peut pas pinguer 1.1.1.1
Cause racine : Route par défaut manquante ou IP de gateway incorrecte
Correction : Ajouter/réparer default via <gateway> dans le gestionnaire correct (netplan/NM/networkd). Vérifier avec ip route get 1.1.1.1.
Symptôme : Ping 1.1.1.1 fonctionne, mais les noms ne se résolvent pas
Cause racine : Portée serveur DNS cassée, mauvais serveur DNS, ou split DNS VPN mal configuré
Correction : Vérifier resolvectl status, interroger avec resolvectl query, assurer l’existence des routes vers les serveurs DNS, corriger l’option 6 DHCP ou nameservers netplan.
Symptôme : DNS fonctionne, ping fonctionne, HTTPS bloque ou timeoute
Cause racine : MTU/PMTUD en blackhole (souvent tunnel/VPN), ou ICMP bloqué en amont
Correction : Identifier le MTU du chemin avec des pings DF ; définir l’MTU d’interface/tunnel adéquat ; éviter de bloquer les ICMP « fragmentation needed ».
Symptôme : Fonctionne sur Wi‑Fi, échoue sur Ethernet (ou vice versa)
Cause racine : Deux routes par défaut ; mauvaise métrique ; routage par politique choisit l’uplink inattendu
Correction : Supprimer le défaut non voulu, ajuster les métriques, ou ajouter des règles de politique explicites. Valider avec ip route et ip route get.
Symptôme : Seulement certaines destinations échouent ; d’autres OK ; pannes « aléatoires »
Cause racine : Routage asymétrique + rp_filter, ou filtrage sélectif en amont sur un chemin d’egress
Correction : Ajuster rp_filter pour le multi‑homing ; assurer la symétrie du chemin retour ou corriger les règles ; confirmer avec tcpdump sur les deux interfaces.
Symptôme : LAN local accessible ; internet mort après la connexion VPN
Cause racine : Le VPN a installé une route par défaut (full tunnel) ou une règle de politique de priorité supérieure
Correction : Ajuster la configuration split tunnel du VPN pour n’envoyer que les préfixes requis via le VPN ; vérifier les tables de routage et priorités ip rule.
Symptôme : « Ça marche en root mais pas en tant que service » (ou inversement)
Cause racine : Routage par UID, fwmarks depuis iptables/nft, ou namespaces réseau par service
Correction : Inspecter ip rule pour uidrange/fwmark ; vérifier le sandboxing du service ; confirmer avec ip route get ... uid ou nsenter dans le namespace.
Symptôme : La route existe mais le trafic ne sort toujours pas
Cause racine : Mauvaise IP source choisie ; manque de sélection src ; ARP flux ; adresses multiples
Correction : Épingler la source dans les routes ou règles ; vérifier avec ip route get ; contrôler ip addr pour IPs secondaires.

Listes de contrôle / plan pas à pas

Checklist A: Single-homed host (one NIC, one gateway)

Confirmer que l’interface est up et a du carrier : ip -br link.
Confirmer l’adresse IP et le masque : ip -br addr.
Confirmer qu’une route par défaut existe dans main : ip route.
Confirmer que vous pouvez atteindre la passerelle : ping -c 2 <gw>.
Confirmer que vous pouvez atteindre une IP publique : ping -c 2 1.1.1.1.
Confirmer les serveurs DNS et la résolution : resolvectl status et resolvectl query.
Si HTTPS échoue, tester le MTU : ping -M do -s 1472 1.1.1.1 et ajuster.

Checklist B: Multi-homed host (two NICs, maybe VPN)

Lister tous les défauts et métriques : ip route show | grep -E '^default'.
Afficher les règles de politique : ip rule. Si vous n’attendiez pas de règles, félicitations : vous en avez.
Afficher toutes les tables : ip route show table all. Cherchez des routes par défaut dans des tables non‑main.
Demandez au noyau le chemin choisi : ip route get 1.1.1.1 et ip route get 1.1.1.1 from <source-ip>.
Vérifier rp_filter : sysctl net.ipv4.conf.all.rp_filter. Si strict et multi‑homed, envisager d’assouplir par interface.
Si un VPN est impliqué, vérifier les routes qu’il a poussées/installées : ip route show avant/après la montée du VPN.
Valider le trafic retour avec tcpdump sur les deux interfaces si vous suspectez de l’asymétrie.

Checklist C: Make the fix without bricking remote access

Quand vous utilisez netplan sur Ubuntu, préférez sudo netplan try d’abord (console locale recommandée).
Quand vous changez des routes sur une machine distante, ajoutez les nouvelles routes avant de supprimer les anciennes.
Gardez un chemin hors bande persistant (console, iLO/IPMI, console série cloud). « Je vais juste SSH me reconnecter » n’est pas un plan.
Après les changements, validez avec ip route, ip rule, ip route get, et un test applicatif réel (curl vers un endpoint externe).

FAQ

1) Pourquoi le bureau indique « Connecté » alors que je n’ai pas d’internet ?

Parce que « connecté » signifie généralement lien + IP. Cela ne valide pas une route par défaut, le DNS, ou le NAT en amont. Le noyau ne se soucie pas des icônes.

2) Quelle est la commande la plus rapide pour prouver que c’est un problème de routage ?

ip route get 1.1.1.1. Si ça retourne « unreachable » ou choisit une interface/source bizarre, vous avez trouvé la catégorie du problème.

3) J’ai une route par défaut, mais toujours pas d’internet. Et maintenant ?

Vérifiez si les réponses reviennent par le même chemin (asymétrie) et si le routage par politique force le trafic dans une autre table. Testez aussi le MTU si HTTPS bloque.

4) Pourquoi `/etc/resolv.conf` affiche 127.0.0.53 ? Est‑ce cassé ?

Pas forcément. C’est le stub de systemd-resolved. Les vrais serveurs en amont sont dans resolvectl status. Corrigez l’amont ou le routage vers lui.

5) Comment plusieurs routes par défaut apparaissent‑elles ?

DHCP sur deux interfaces, Wi‑Fi plus Ethernet, clients VPN qui installent un défaut, ou config statique empilée sur DHCP. Linux en choisira une selon métriques et logique de règle/table.

6) Quelle est la différence entre le routage de la « main table » et le routage par politique ?

Le routage de la table main est la recherche par défaut. Le routage par politique ajoute des règles qui choisissent différentes tables selon des attributs du paquet (source, marque, interface d’entrée, UID). Si vous avez des règles, la table « main » peut ne pas importer pour le trafic qui vous intéresse.

7) Dois‑je désactiver rp_filter pour corriger ça ?

Ne le faites pas aveuglément. Sur les hôtes single‑homed, rp_filter strict est correct. Sur les hôtes multi‑homed, mettez‑le en loose (2) par interface si l’asymétrie est légitime. Mieux : concevez le routage pour être symétrique quand c’est possible.

8) Pourquoi ping marche mais apt/curl échoue ?

Ping est petit et simple. apt/curl touchent DNS, TCP, TLS, proxies, et souvent des paquets plus gros. Les problèmes MTU/PMTUD et DNS sont les raisons les plus courantes de ce décalage.

9) IPv6 peut‑il causer « pas d’internet » même si IPv4 va bien ?

Oui. Beaucoup de clients préfèrent IPv6 ; un routage IPv6 cassé peut mener à des échecs lents. Testez avec curl -4 vs curl -6 et confirmez les routes par défaut IPv6 et le statut RA/DHCPv6.

10) Je l’ai réparé avec un `ip route add default` manuel. Comment le rendre persistant ?

Mettez la configuration dans le gestionnaire réseau du système (netplan, NetworkManager, ifupdown, ou networkd). Les changements manuels ip route disparaissent au reboot ou au flap du lien — et ils reviendront vous hanter.

Prochaines étapes que vous pouvez réellement faire

Si vous ne retenez rien d’autre : cessez de faire confiance à « connecté » et commencez à interroger le noyau. Lancez ip route, ip rule, et ip route get. Ces trois commandes vous diront ce que l’hôte croit du monde.

Puis faites les corrections ennuyeuses, dans l’ordre :

Assurez‑vous qu’il existe exactement une route par défaut voulue pour la classe de trafic qui vous importe (ou plusieurs, mais avec métriques et règles explicites).
Rendez le routage par politique explicite, documenté et minimal. Si vous ne pouvez pas expliquer chaque ip rule, vous ne possédez pas votre routage.
Validez le DNS via resolvectl et testez par IP pour séparer les préoccupations.
Si les applications bloquent, traitez le MTU comme suspect principal jusqu’à preuve du contraire.
Persistez les changements dans le gestionnaire correct (netplan/NM/networkd) et évitez la configuration split‑brain.

Le réseau en production n’est pas difficile parce que les commandes sont compliquées. Il est difficile parce que les humains continuent d’empiler « juste une chose de plus » jusqu’à ce que l’hôte devienne un roman choose‑your‑own‑adventure. Votre travail est d’en faire à nouveau une liste de courses.