Décision de chemin, routes statiques et routage système

Chaque paquet qui quitte une machine fait l’objet d’une décision : par quelle interface sortir, et à quel voisin le confier. Cette décision est prise par la table de routage, sur le poste de travail comme sur le routeur de cœur de réseau, selon les mêmes règles. Cette fiche explique comment la table est lue, comment écrire des routes statiques qui fonctionnent dans les deux sens, et comment les cas avancés (tables multiples, routage politique, plusieurs fournisseurs) produisent des chemins asymétriques ou contournent les pare-feu.

→ Lire l’explication complète de la marmotte

Lire une décision de routage

Les champs d’une route

Une route associe une destination, exprimée sous forme de préfixe (un bloc d’adresses comme 10.20.0.0/16), à un moyen de l’atteindre. Ce moyen combine un prochain saut (next-hop), l’adresse du voisin à qui confier le paquet, et une interface de sortie. Une métrique départage plusieurs routes vers le même préfixe : la plus faible gagne. Sur les routeurs, une notion supplémentaire, la distance administrative chez Cisco ou la préférence chez d’autres constructeurs, départage les sources de routes : une route statique l’emporte par défaut sur une route apprise par OSPF (Open Shortest Path First), qui l’emporte elle-même sur une route RIP (Routing Information Protocol).

Une route sans prochain saut désigne un réseau directement connecté : la destination se trouve sur le même segment, le système résout l’adresse MAC du destinataire lui-même. Une route avec prochain saut demande de résoudre l’adresse MAC du voisin, puis de lui remettre le paquet tel quel, adresse IP de destination intacte. Le prochain saut doit donc être joignable sur un réseau connecté, faute de quoi la route est inutilisable.

Le préfixe le plus spécifique gagne

La règle fondamentale est celle du préfixe le plus long (longest prefix match) : parmi toutes les routes dont le préfixe contient l’adresse de destination, le système retient celle dont le masque est le plus long, c’est-à-dire la plus précise. La métrique n’intervient qu’entre routes de même longueur. Soit la table suivante :

0.0.0.0/0        via 192.168.1.1     (route par défaut)
10.0.0.0/8       via 192.168.1.250
10.20.0.0/16     via 192.168.1.251
10.20.30.0/24    via 192.168.1.252

Un paquet vers 10.20.30.5 correspond aux quatre lignes ; le /24 gagne. Vers 10.20.99.1, le /16 gagne. Vers 10.99.0.1, le /8. Vers 8.8.8.8, seule la route par défaut convient. Cette règle explique qu’une route très spécifique ajoutée « pour tester » détourne silencieusement une partie du trafic, quelle que soit la qualité de la route générale.

La route par défaut

La route par défaut est la route la moins spécifique possible : 0.0.0.0/0 en IPv4, ::/0 en IPv6. Elle correspond à toutes les adresses et ne sert donc que si rien d’autre ne correspond. Sur un poste, elle pointe vers la passerelle du réseau local ; sur un routeur d’accès, vers le fournisseur. En IPv6, elle est souvent apprise automatiquement par les annonces de routeur et pointe vers une adresse locale au lien, en fe80::, ce qui surprend la première fois et rassure ensuite, puisque cette adresse ne change pas quand le préfixe du fournisseur change.

Une machine sans route par défaut n’est pas en panne : elle ne joint simplement que les réseaux qu’on lui a décrits. C’est d’ailleurs la configuration souhaitable pour bien des serveurs internes qui n’ont aucune raison de parler à Internet.

Table locale et table d’un routeur

Le poste de travail et le routeur appliquent le même algorithme. La différence tient au volume et à l’origine des routes : quelques lignes apprises par DHCP (Dynamic Host Configuration Protocol) ou les annonces IPv6 sur un poste, des milliers apprises par des protocoles de routage sur un routeur, et près d’un million de préfixes IPv4 pour un routeur qui reçoit la table Internet complète par BGP (Border Gateway Protocol). Sur Linux, la commande ip route get montre la décision effective pour une destination, ce qui vaut mieux que de relire la table de tête :

$ ip route get 10.20.30.5
10.20.30.5 via 192.168.1.252 dev eth0 src 192.168.1.77 uid 1000

La réponse donne le prochain saut, l’interface et l’adresse source choisie. Sous Windows, route print et Find-NetRoute -RemoteIPAddress jouent un rôle comparable ; sur un routeur Cisco, show ip route 10.20.30.5.

Construire des routes statiques

Écrire la route

Une route statique est écrite à la main. Elle convient aux topologies simples ou aux cas où un protocole dynamique serait disproportionné : joindre une DMZ (zone démilitarisée) derrière un pare-feu, un réseau distant derrière une passerelle VPN (Virtual Private Network), un réseau virtuel chez un fournisseur cloud. Sur Linux :

# DMZ 172.16.10.0/24 derrière le pare-feu interne
ip route add 172.16.10.0/24 via 192.168.1.254 dev eth0

# réseau du site distant derrière la passerelle VPN
ip route add 10.50.0.0/16 via 192.168.1.253

# réseau cloud joint par une interface de tunnel
ip route add 10.100.0.0/16 dev wg0

Sur un routeur Cisco, la syntaxe équivalente est ip route 172.16.10.0 255.255.255.0 192.168.1.254. La commande ip route add ne survit pas au redémarrage : la persistance dépend de l’outil de gestion réseau de la distribution (fichiers de NetworkManager, de systemd-networkd, de netplan ou /etc/network/interfaces). Sous Windows, l’option -p de route add rend la route persistante. Une route qui disparaît au redémarrage a au moins le mérite de ne pas devenir permanente par négligence ; c’est d’ailleurs à peu près le seul.

Penser systématiquement au retour

Une communication suit deux trajets. Ajouter une route de A vers B n’a d’effet que si B sait répondre vers A. Le cas typique : un administrateur ajoute sur son poste une route vers le réseau d’administration 10.99.0.0/24 via un routeur interne. Les paquets arrivent, mais les équipements d’administration ont pour passerelle par défaut un autre routeur, qui ne connaît pas le réseau du poste ou l’envoie vers Internet. Le ping reste muet, la capture sur la cible montre les requêtes arriver et les réponses partir dans la mauvaise direction. Toute route se conçoit donc par paire : aller et retour, et le retour se vérifie depuis la destination.

Documenter intention et durée de vie

Une route statique n’explique jamais pourquoi elle existe. Chaque route mérite une ligne de documentation : préfixe, prochain saut, raison, demandeur, date de création, date de retrait prévue si elle est temporaire. Beaucoup d’équipements acceptent un commentaire ou un nom sur la route elle-même ; à défaut, le référentiel décrit dans Gestion réseau, supervision et référentiels d’exploitation en tient lieu. Une route sans auteur ni intention connue finit toujours par être conservée « par prudence », jusqu’au jour où elle sert à un intrus.

Cas avancés

Plusieurs tables et routage politique

Le routage classique ne regarde que la destination. Le routage politique (policy-based routing) choisit la route selon d’autres critères : adresse source, interface d’entrée, marquage, port. Sur Linux, il repose sur plusieurs tables et sur des règles qui désignent la table à consulter :

$ ip rule
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

# le trafic issu du réseau invités sort par le second fournisseur
ip route add default via 203.0.113.1 dev wan2 table 100
ip rule add from 192.168.50.0/24 lookup 100 priority 1000

Les règles sont évaluées par priorité croissante. Ce routage selon la source (source-based routing) est indispensable dès qu’une machine possède deux accès vers l’extérieur, car une réponse doit repartir par l’accès qui a reçu la requête. Il ne faut pas le confondre avec l’option de routage à la source d’IPv4 (Loose et Strict Source Route), par laquelle l’émetteur imposait le chemin dans le paquet : cette option est filtrée presque partout, et son équivalent IPv6, l’en-tête de routage de type 0, a été déprécié par la RFC 5095 pour des raisons de sécurité.

VRF

Une VRF (Virtual Routing and Forwarding) crée plusieurs tables de routage indépendantes sur un même équipement, chacune associée à ses interfaces. Deux VRF peuvent contenir le même préfixe sans conflit, ce qui permet à un opérateur d’héberger des clients aux adressages qui se chevauchent, ou à une entreprise d’isoler le réseau d’administration du trafic de production. Sur Linux, ip link add mgmt type vrf table 10 crée une VRF à laquelle on rattache ensuite des interfaces. Une VRF sépare des tables de routage, au niveau 3 ; un VLAN sépare des domaines de diffusion, au niveau 2. On les combine souvent, ils ne se remplacent pas.

Multi-homing et chemin asymétrique

Le multi-homing consiste à se raccorder à plusieurs fournisseurs ou plusieurs liens. Il améliore la disponibilité, mais multiplie les chemins possibles. Un chemin est asymétrique quand l’aller et le retour ne passent pas par les mêmes équipements. Pour le routage pur, ce n’est pas un problème : Internet est massivement asymétrique. Pour un pare-feu à états, qui suit les connexions, c’en est un. Il voit passer le SYN d’une connexion TCP mais jamais le SYN-ACK, parti par l’autre pare-feu, et rejette les paquets suivants comme n’appartenant à aucune connexion connue.

Chemin asymétrique. À l'aller, le poste passe par le pare-feu A pour atteindre le serveur : le pare-feu A voit le SYN. Au retour, le serveur répond par le pare-feu B : celui-ci voit un SYN-ACK sans avoir vu de SYN, et le rejette. Aucun des deux pare-feu ne voit la connexion entière.

Les remèdes sont connus : symétriser par le routage, synchroniser l’état entre les deux pare-feu d’une même grappe, ou traduire l’adresse source pour forcer le retour. Côté Linux, le filtrage du chemin inverse (net.ipv4.conf.*.rp_filter, décrit par la RFC 3704 en mode strict ou lâche) rejette en mode strict les paquets arrivés par une interface qui ne serait pas celle utilisée pour répondre à leur source ; il protège contre l’usurpation d’adresse mais casse les asymétries légitimes.

Les routes qui contournent les contrôles

Un pare-feu ne contrôle que ce qui le traverse. Une route ajoutée sur un serveur pour joindre directement un réseau voisin par une seconde interface, une route plus spécifique annoncée par un équipement mal configuré, un tunnel VPN monté sur un poste qui rend un réseau tiers joignable : chacune ouvre un chemin parallèle, sans règle ni journal. Repérer ces routes demande de comparer les tables réelles avec le schéma prévu, en cherchant en priorité les préfixes plus spécifiques que prévu, les prochains sauts inattendus et les machines à plusieurs interfaces dont net.ipv4.ip_forward vaut 1.

Exemples et ateliers

Lire `ip route` et `ip -6 route`

$ ip route
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.77 metric 100
10.50.0.0/16 via 192.168.1.253 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.77 metric 100

$ ip -6 route
2001:db8:10::/64 dev eth0 proto ra metric 100 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::1 dev eth0 proto ra metric 100 pref medium

La première ligne IPv4 est la route par défaut apprise par DHCP (proto dhcp). La deuxième est une route statique sans mention d’origine (proto boot implicite). La troisième est le réseau connecté, créé par le noyau (proto kernel, scope link) au moment où l’adresse a été configurée. Côté IPv6, le préfixe et la route par défaut viennent des annonces de routeur (proto ra), et le prochain saut est une adresse locale au lien.

Trouver une route de retour absente

Symptôme : depuis 10.50.0.10 (site distant), le serveur 192.168.1.20 ne répond pas, alors que la route aller existe. Méthode : capture sur le serveur (tcpdump -ni eth0 host 10.50.0.10), qui montre les requêtes entrantes. Puis ip route get 10.50.0.10 sur le serveur, qui répond via 192.168.1.1, la passerelle Internet, au lieu de 192.168.1.253, la passerelle VPN. Correction : ajouter la route sur le serveur, ou mieux, sur la passerelle par défaut, qui redirigera ou routera vers la passerelle VPN. Le second choix centralise la décision au lieu de la disperser sur chaque serveur.

Dessiner une asymétrie entre deux pare-feu

Deux sites, chacun avec son pare-feu et son accès Internet, reliés par un lien interne. Un poste du site A joint un serveur du site B : l’aller sort par le pare-feu A et Internet, le retour emprunte le lien interne parce que le serveur B préfère cette route pour le réseau de A. Le dessin des deux trajets, avec les équipements traversés de chaque côté, fait apparaître immédiatement quel pare-feu ne voit qu’un sens. L’exercice vaut pour tout réseau multisite : deux flèches par flux, jamais une.

Pièges classiques

Le premier piège est d’ajouter une route sans vérifier le retour. Le test se fait depuis les deux extrémités, avec ip route get de chaque côté, et non en constatant que « le ping part ».

Le deuxième piège est de confondre routage et autorisation. Une route rend une destination joignable ; elle n’accorde aucun droit. Tout ce que la route rend accessible doit être explicitement autorisé ou refusé par le filtrage, comme l’explique Filtrage, segmentation, NAC et Zero Trust.

Le troisième piège est de laisser une route temporaire devenir permanente. Une route posée pendant une migration ou un dépannage survit à l’événement qui la justifiait, faute de date de retrait. Un audit régulier des routes statiques, comparées à leur documentation, est le seul remède connu à la mémoire sélective des équipes.

À ne pas confondre

Route par défaut et passerelle unique : une machine peut avoir une route par défaut et plusieurs passerelles pour des réseaux précis, ou plusieurs routes par défaut avec des métriques différentes. La route par défaut ne signifie pas « le seul chemin », mais « le chemin quand rien d’autre ne convient ».

VRF et VLAN : la VRF isole des tables de routage au niveau 3, le VLAN isole des domaines de diffusion au niveau 2 ; voir VLAN, trunks et boucles pour le second.

Multi-homing et équilibrage applicatif : se raccorder à deux fournisseurs ne répartit pas les requêtes entre plusieurs serveurs. Le premier traite la disponibilité des liens, le second celle des services, et l’un ne dispense pas de l’autre. Le multi-homing à l’échelle d’Internet est détaillé dans BGP, Internet et anycast.

🐝 Ce qui arrive si on s’en passe

Sans décision de routage maîtrisée ni routes documentées, la politique de filtrage n’a plus qu’une valeur déclarative : le pare-feu applique ses règles au trafic qui passe par lui, et strictement rien à celui qu’une route oubliée fait passer à côté. Une route ajoutée pour un dépannage devient un chemin permanent que personne ne sait justifier, ni retirer sans craindre de casser quelque chose. En cas d’incident, les journaux du pare-feu ne racontent qu’une partie de l’histoire, et l’absence d’alerte ne prouve plus rien : elle peut simplement signifier que le trafic a pris l’autre route.

🦫 Explication de la marmotte 🍫

Chaque machine et chaque routeur possède une table de routage : une liste de règles qui disent par où envoyer un paquet selon sa destination. Chaque règle indique un préfixe, c’est-à-dire un bloc d’adresses, le prochain équipement à qui confier le paquet, l’interface de sortie et une métrique qui départage les choix. Quand un paquet part, le système cherche toutes les règles qui correspondent à son adresse et retient la plus précise, celle dont le bloc d’adresses est le plus petit. Si aucune ne convient, il utilise la route par défaut. Les routes statiques sont écrites à la main par un administrateur, par exemple vers une zone exposée, un tunnel chiffré ou un réseau hébergé chez un fournisseur. Une communication a toujours deux sens : si la route de retour manque, les réponses se perdent. Quand l’aller et le retour empruntent des chemins différents, le chemin est dit asymétrique, et un pare-feu qui ne voit qu’un seul sens peut rejeter le trafic ou le laisser sans contrôle. Une route mal pensée peut aussi faire passer le trafic à côté d’un pare-feu. Des mécanismes avancés permettent de choisir la route selon l’origine du paquet, de séparer plusieurs tables sur un même routeur ou de se relier à plusieurs fournisseurs. Router n’est pas autoriser : une route rend une destination joignable sans donner aucun droit. Chaque route doit donc être documentée avec son intention et sa durée de vie.

Pages voisines

La citent

Décision de chemin, routes statiques et routage système

Elle cite

: les deux pages se citent l’une l’autre.

Décision de chemin, routes statiques et routage système

Décision de chemin, routes statiques et routage système

Lire une décision de routage

Les champs d’une route

Le préfixe le plus spécifique gagne

La route par défaut

Table locale et table d’un routeur

Construire des routes statiques

Écrire la route

Penser systématiquement au retour

Documenter intention et durée de vie

Cas avancés

Plusieurs tables et routage politique

VRF

Multi-homing et chemin asymétrique

Les routes qui contournent les contrôles

Exemples et ateliers

Lire ip route et ip -6 route

Trouver une route de retour absente

Dessiner une asymétrie entre deux pare-feu

Pièges classiques

À ne pas confondre

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines

Lire `ip route` et `ip -6 route`