Couche 3 : IP, adressage et routage — le guide complet

Troisième étage. On a fait le câble — la couche 1. On a fait les adresses MAC et la couche 2.

La couche 2 a une limite structurelle, et elle est brutale : elle ne passe pas à l’échelle. Pour trouver quelqu’un, elle crie dans le couloir (broadcast). Ça marche à trente. À trois milliards, c’est une blague. Et les adresses MAC sont plates : 00:1A:2B:3C:4D:5E ne dit rien de l’endroit où se trouve la machine. Aucune structure, aucune hiérarchie, rien à agréger. Un routeur mondial devrait connaître toutes les cartes réseau de la planète, une par une.

La couche 3 résout ce problème d’une seule idée : une adresse qui dit où on est. C’est tout. Le reste en découle.

L’essentiel en 30 secondes

• Une IP n’est pas une adresse, c’est deux : une partie réseau + une partie hôte. Le masque est la frontière. Sans masque, une IP ne veut rien dire.
• Les classes A/B/C sont mortes en 1993. On fait du CIDR. Si on vous parle encore de classes, on vous parle de 1992.
• Un routeur choisit par longest prefix match : la route la plus spécifique gagne, toujours.
• Le TTL n’est pas un temps, c’est un compteur de sauts. C’est lui qui fait marcher traceroute.
• Bloquer tout ICMP casse votre réseau. Le type 3 code 4 est vital.
• Le NAT n’est pas une sécurité. Le pare-feu à états qui l’accompagne, si.
• 80 % des incidents « ça marche pas » sont un masque faux, une route retour absente, ou un MTU.

L’adresse IP : ce que tout le monde croit savoir

Une adresse IPv4 fait 32 bits. On l’écrit en quatre nombres décimaux de 0 à 255, séparés par des points — la fameuse dotted decimal. C’est un pur confort humain : la machine, elle, ne voit que 32 bits d’affilée.

192  .  168  .  1  .  10
11000000.10101000.00000001.00001010

Voilà le point que je veux marteler, parce que c’est la clé de tout ce qui suit :

Une adresse IP seule ne signifie rien. Elle n’est interprétable qu’accompagnée de son masque.

192.168.1.10 ne vous dit pas dans quel réseau vous êtes. Ni qui est votre voisin. Ni ce que vous pouvez joindre directement. Tant qu’on ne vous a pas donné le masque, vous ne savez rien.

C’est pour ça qu’on écrit toujours 192.168.1.10/24 et jamais 192.168.1.10 tout court. Le /24 n’est pas un ornement — c’est la moitié de l’information.

Le masque : une frontière, pas un nombre

Le masque coupe les 32 bits en deux :

Adresse : 11000000.10101000.00000001.00001010   192.168.1.10
Masque  : 11111111.11111111.11111111.00000000   255.255.255.0  (/24)
          └────── partie RÉSEAU ──────┘└ HÔTE ┘

Règle unique : les bits à 1 du masque désignent le réseau. Les bits à 0 désignent l’hôte. Et les 1 sont forcément contigus, en partant de la gauche. Un masque troué (255.0.255.0) n’existe pas — enfin, si, techniquement, mais c’est aussi illégal en pratique que de rouler à contresens.

Comme les 1 sont contigus, il suffit de les compter. D’où la notation CIDR : /24 veut dire « 24 bits à 1 », donc 255.255.255.0. Les deux notations disent exactement la même chose.

Pourquoi le « −2 » ? Dans chaque réseau, deux adresses sont confisquées :

• La première = l’adresse de réseau. Tous les bits hôte à 0. Elle désigne le réseau lui-même, pas une machine. 192.168.1.0/24.
• La dernière = le broadcast. Tous les bits hôte à 1. Elle désigne toutes les machines du réseau. 192.168.1.255/24.

Un /30 a donc 4 adresses et seulement 2 utilisables — d’où son usage historique pour les liaisons point-à-point entre routeurs : deux machines, deux adresses, zéro gâchis. Enfin, 50 % de gâchis.

Le /31 (RFC 3021) est l’exception qui confirme la règle : sur une liaison point-à-point, l’adresse de réseau et le broadcast n’ont aucun sens (il n’y a que deux machines, elles se connaissent). On les récupère donc : 2 adresses, 2 hôtes. C’est le détail qui fait plaisir en entretien.

Les classes A, B, C : à enterrer

Il faut en parler, parce que c’est encore enseigné, y compris en 2026, y compris dans des formations sérieuses.

Avant 1993, la partie réseau d’une IP était déduite du premier octet :

Le système était rigide et gaspillait l’espace de façon obscène : une entreprise de 300 machines devait prendre une classe B (65 534 adresses) parce qu’une classe C (254) ne suffisait pas. 65 000 adresses immobilisées pour 300 machines.

CIDR (RFC 1519, 1993) a tué les classes. On choisit le masque qu’on veut, indépendamment du premier octet. 10.0.0.0/24 est parfaitement légal, alors que le « 10 » est en « classe A ».

Ce qui reste vrai : les classes D (multicast) et E (réservé) sont toujours d’actualité. Les A, B, C ne sont plus qu’un souvenir. Mais elles survivent dans les masques par défaut que proposent encore certains outils quand vous tapez une IP — Windows en tête. Ce n’est pas une règle, c’est une suggestion paresseuse héritée de 1992. Ne la subissez pas.

Les plages qu’il faut connaître par cœur

Deux pièges classiques :

• 172.16.0.0/12 s’arrête à 172.31.255.255, pas à 172.16.255.255. Le /12 couvre 16 blocs /16. Beaucoup de gens ne réservent que 172.16.x.x et se plantent en pensant que 172.20.x.x est public. Il ne l’est pas.
• 169.254.x.x est un message d’erreur déguisé. Si une machine porte cette adresse, elle n’a pas eu de bail DHCP. Elle se l’est attribuée toute seule, faute de mieux. Ne cherchez pas plus loin : câble, VLAN, serveur DHCP, ip helper-address. C’est l’un des diagnostics les plus rapides du métier — une IP qui est son propre symptôme.

Le paquet IP : les champs qui servent vraiment

L’en-tête IPv4 fait 20 octets minimum. Une douzaine de champs. Quatre comptent réellement au quotidien.

┌──────────┬──────────┬────────────────────────────────┐
│ Version  │   IHL    │  DSCP/ECN  │   Longueur totale  │
├──────────┴──────────┼──────────┬─────────────────────┤
│   Identification    │  Flags   │  Fragment offset    │
├──────────┬──────────┼──────────┴─────────────────────┤
│   TTL    │ Protocol │      Header checksum           │
├──────────┴──────────┴────────────────────────────────┤
│              Adresse IP SOURCE (32 bits)             │
├──────────────────────────────────────────────────────┤
│           Adresse IP DESTINATION (32 bits)           │
└──────────────────────────────────────────────────────┘

TTL — le champ le plus malin de l’informatique

TTL = Time To Live. Le nom ment : ce n’est pas un temps. C’est un compteur de sauts.

La mécanique tient en deux lignes : chaque routeur traversé décrémente le TTL de 1. Si le TTL atteint 0, le routeur jette le paquet et renvoie à l’expéditeur un ICMP Time Exceeded (type 11).

Pourquoi ? Parce qu’une boucle de routage est toujours possible : R1 croit que c’est par R2, R2 croit que c’est par R1. Sans TTL, le paquet ferait l’aller-retour pour l’éternité, et le lien saturerait en quelques secondes. Le TTL est le disjoncteur : au pire, le paquet meurt après N sauts. Un réseau en boucle avec TTL est un réseau qui perd des paquets. Sans TTL, c’est un réseau qui s’effondre.

Les valeurs de départ trahissent l’OS — c’est du fingerprinting gratuit :

Vous pingez une machine et recevez un TTL de 122 ? Départ à 128, donc Windows, et 6 routeurs traversés. Vous venez d’apprendre l’OS et la distance sans rien envoyer d’autre qu’un ping.

Et le génie du truc : c’est exactement comme ça que fonctionne traceroute. On envoie un paquet avec TTL = 1. Le premier routeur le décrémente à 0, le jette, et se dénonce en renvoyant son Time Exceeded. On note son IP. On recommence avec TTL = 2 : le deuxième routeur se dénonce. Puis 3, 4, 5… Chaque routeur du chemin est forcé de lever la main, dans l’ordre. traceroute n’est pas un protocole — c’est un détournement élégant d’un mécanisme anti-boucle.

Protocol — qui est au-dessus

Un octet qui annonce le contenu. L’équivalent de l’EtherType de la couche 2, un étage plus haut.

Ces numéros servent tous les jours dans les ACL et les règles de pare-feu. Retenez 1, 6, 17. Le 50 quand vous ferez de l’IPsec — et vous vous souviendrez qu’ESP n’a pas de numéro de port, ce qui explique pourquoi il traverse mal le NAT. Mais c’est une autre histoire.

Fragmentation, MTU : le sujet qui pourrit les journées

Le MTU (Maximum Transmission Unit) est la taille maximale d’un paquet sur un lien. Sur Ethernet : 1500 octets. C’est une valeur de couche 2 qui contraint la couche 3 — une des rares fuites entre couches.

Un paquet trop gros pour le lien suivant a deux destins :

• Bit DF (Don’t Fragment) à 0 → le routeur fragmente. Le paquet est coupé en morceaux, réassemblés uniquement à destination finale.
• Bit DF à 1 → le routeur jette et renvoie un ICMP Destination Unreachable — Fragmentation Needed (type 3, code 4), en précisant le MTU qui passerait.

C’est ce second cas qui compte, parce que tout le monde met DF à 1 : TCP moderne fait de la PMTUD (Path MTU Discovery). Il envoie gros avec DF, attend qu’on lui dise « trop gros, essaie 1400 », et s’adapte.

Et voilà le drame. Un administrateur zélé bloque « tout ICMP » sur son pare-feu, parce que « ICMP c’est le ping et le ping c’est dangereux ». Le message type 3 code 4 n’arrive jamais à l’expéditeur. Celui-ci ne sait pas que ses paquets sont trop gros. Il continue d’en envoyer. Ils continuent d’être jetés. En silence.

Le symptôme est légendaire, et il ressemble à de la magie noire :

• le ping passe (petit paquet ✓)
• SSH se connecte, l’invite s’affiche (petits paquets ✓)
• SSH gèle dès qu’on tape ls -l sur un gros répertoire (gros paquet ✗)
• le site web charge le HTML mais jamais les images
• « ça marche depuis le wifi mais pas depuis le VPN »

Ça s’appelle un PMTUD black hole. Ça se diagnostique en deux commandes :

ping -M do -s 1472 8.8.8.8        # Linux : DF + 1472 octets = 1500 avec les en-têtes
ping -f -l 1472 8.8.8.8           # Windows : équivalent

On descend la taille jusqu’à ce que ça passe : on tient le MTU réel du chemin. Si 1472 échoue et 1400 passe, votre MTU utile est quelque part entre les deux — typiquement un VPN, un tunnel IPsec ou du PPPoE qui mange de la place.

La parade quand on ne maîtrise pas le chemin : le MSS clamping. Le routeur réécrit à la volée le MSS annoncé par TCP à l’établissement de la connexion, pour forcer les deux bouts à envoyer petit. C’est une rustine — mais c’est une rustine qui sauve des vies sur du VPN site-à-site.

Le routage : comment un routeur décide

Un routeur ne fait qu’une chose, mais il la fait des millions de fois par seconde : regarder l’IP de destination, consulter sa table, réexpédier. Point.

La table de routage

ip route show                    # Linux
route print                      # Windows
show ip route                    # Cisco

Sur une machine Linux ordinaire :

default via 192.168.1.1 dev eth0 proto dhcp metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10
10.8.0.0/24 via 192.168.1.254 dev eth0

Trois lignes, trois natures :

1. default = 0.0.0.0/0 = tout le reste. La route de dernier recours.
2. 192.168.1.0/24 dev eth0 = le réseau directement connecté. Pas de via : on est dessus, on livre en direct (via ARP, cf. l’article couche 2).
3. 10.8.0.0/24 via … = une route explicite vers un réseau distant.

Longest prefix match — LA règle

Un paquet pour 10.8.0.42 peut correspondre à plusieurs lignes à la fois. Laquelle gagne ?

La plus spécifique. Celle qui a le masque le plus long. Toujours.

Pas la première trouvée, pas la moins coûteuse, pas la plus récente : la plus longue. Un /24 bat un /16, qui bat un /8, qui bat le /0 par défaut.

C’est ce qui rend le routage hiérarchique possible : on annonce une grosse route générale, et on affine localement avec des routes plus spécifiques qui, mécaniquement, prennent le dessus. Aucune notion de priorité à gérer — la spécificité est la priorité.

Corollaire utile : 0.0.0.0/0 a un masque de longueur zéro. C’est la route la moins spécifique qui puisse exister. Elle ne gagne donc que si aucune autre ne correspond. C’est exactement ce qu’on veut d’un « tout le reste ».

Et la commande qui répond directement à la question, sans que vous ayez à lire la table :

ip route get 8.8.8.8
# 8.8.8.8 via 192.168.1.1 dev eth0 src 192.168.1.10 uid 1000

Elle vous donne le verdict du noyau : quelle route, quelle interface, quelle IP source. C’est la commande que j’utilise en premier quand quelque chose part au mauvais endroit. Elle tranche les débats en une seconde.

Métrique et distance administrative

Deux routes de même longueur vers la même destination ? Là seulement on départage :

• La distance administrative (concept Cisco) — à quel point on fait confiance à la source de l’info. Plus c’est bas, mieux c’est.
• La métrique — le coût, au sein d’un même protocole.

L’ordre a du sens : « je le vois de mes yeux » (0) bat « un humain me l’a dit » (1), qui bat « un protocole me l’a calculé » (110). La confiance décroît avec la distance à la source.

Statique ou dynamique ?

Routage statique — vous écrivez les routes à la main.

• ✅ Prévisible, zéro CPU, zéro protocole à sécuriser
• ❌ Aucune adaptation : un lien tombe, la route reste, le trafic part dans le vide

Routage dynamique — les routeurs se parlent.

En pratique, pour un TSSR : l’immense majorité des PME tourne en statique, et c’est très bien. Quelques routes, une par défaut, terminé. OSPF apparaît quand il y a plusieurs sites et de la redondance. BGP, quand il y a plusieurs opérateurs — et là, ce n’est plus vous.

La bonne question n’est pas « statique ou dynamique ? » mais « ai-je des chemins redondants ? ». Sans redondance, le dynamique n’apporte rien qu’une complexité et une surface d’attaque.

La route retour — l’erreur n°1

Celle que je vois le plus, tous niveaux confondus. Gravez-la :

Le routage ne se configure jamais dans un seul sens. Un paquet qui part doit pouvoir revenir — et il ne revient pas forcément par où il est venu.

Le scénario : vous ajoutez une route sur le routeur A vers le réseau B. Vous testez. Le ping ne passe pas. Vous vérifiez trois fois votre route. Elle est parfaite. Elle est parfaite. Le paquet arrive très bien à destination.

C’est le retour qui n’a pas de chemin. La machine cible reçoit votre ping, veut répondre, consulte sa table, ne trouve rien pour votre réseau, et balance la réponse vers sa passerelle par défaut — qui n’en veut pas.

Le réflexe : en cas de « ça part mais ça ne revient pas », arrêtez de regarder votre côté. tcpdump sur la machine cible : si vous voyez arriver les paquets, votre aller est bon à 100 %, et le problème est ailleurs — route retour, ou pare-feu local. Ce seul test coupe le problème en deux et fait gagner des heures.

Le cousin de ce piège : les deux passerelles par défaut sur une machine multi-interfaces. Deux 0.0.0.0/0, une seule qui sert, et un comportement apparemment aléatoire. Une machine n’a qu’une passerelle par défaut. Si vous en avez besoin de deux, ce que vous voulez ce sont des routes spécifiques plus une seule route par défaut.

ICMP : ce n’est pas « le ping »

Erreur de vocabulaire aux conséquences très concrètes. ICMP n’est pas le ping. Le ping est un usage d’ICMP. ICMP est le système de signalisation d’erreur de la couche 3 — la façon dont le réseau vous dit ce qui ne va pas.

Le type 3 est une famille entière, et c’est le code qui parle :

Ces codes sont un cadeau. « Destination unreachable » ne veut rien dire ; « destination unreachable, code 3 » veut dire « ton routage est parfait, ton service est mort ». Deux diagnostics opposés, un seul chiffre de différence. Lisez les codes.

Faut-il bloquer ICMP ?

Réponse courte : non. Réponse longue : non, mais.

L’argument « ICMP permet de découvrir mon réseau » est réel mais faible : un attaquant qui est déjà sur votre segment n’a aucun besoin d’ICMP pour vous cartographier — un scan TCP fait le travail, et l’ARP encore mieux (cf. couche 2). Vous vous privez d’un outil de diagnostic pour ralentir de trente secondes quelqu’un qui est déjà à l’intérieur.

Et surtout, bloquer tout ICMP casse des choses, sans message d’erreur, de façon différée, et personne ne fera le lien trois mois plus tard :

• Type 3 code 4 bloqué → PMTUD black hole. Le cauchemar décrit plus haut.
• Type 11 bloqué → plus de traceroute. Vous êtes aveugle sur vos propres chemins.
• Type 3 code 3 bloqué → les connexions vers un port fermé expirent au lieu d’être refusées immédiatement. Vos applications rament au lieu d’échouer proprement.

La position raisonnable : filtrer l’echo request (type 8) entrant depuis Internet si ça vous rassure — c’est le seul qui se défend. Laisser passer les types 3 et 11 dans tous les sens. Ce ne sont pas des requêtes, ce sont des messages d’erreur : les bloquer, c’est débrancher le voyant d’huile pour ne plus le voir s’allumer.

NAT : indispensable, et incompris

NAT = Network Address Translation. Un routeur réécrit les adresses IP dans les paquets qui le traversent.

Pourquoi ça existe

IPv4 a 4,3 milliards d’adresses. C’est fini depuis longtemps. Le NAT permet à 200 machines de partager une seule IP publique. C’est une rustine — une rustine tellement efficace qu’elle a repoussé l’adoption d’IPv6 de vingt ans.

Les trois formes

Le PAT est le cas réel à 99 %. Le routeur ne réécrit pas que l’IP : il change aussi le port source, et tient une table de correspondance.

Interne                     Externe (vu d'Internet)
192.168.1.10:51234    →     93.20.1.5:40001
192.168.1.11:51234    →     93.20.1.5:40002
192.168.1.12:33445    →     93.20.1.5:40003

Une réponse arrive sur le port 40002 → le routeur consulte sa table → c’est pour 192.168.1.11:51234. Le port devient le discriminant. Un seul IP publique, 65 000 conversations simultanées.

Notez la fuite de couche. Le NAT est présenté comme un mécanisme de couche 3, mais le PAT manipule les ports TCP/UDP, qui sont de la couche 4. Le NAT viole allègrement le modèle en couches. C’est d’ailleurs pour ça qu’il casse tant de protocoles : tout ce qui embarque une IP dans les données (SIP, FTP actif, IPsec ESP) se retrouve incohérent, et il faut des rustines sur la rustine (helpers ALG, NAT-T).

Le NAT n’est pas une sécurité

Il faut le dire net, parce que c’est une croyance solide, y compris chez des gens sérieux.

L’argument est : « mes machines sont en 192.168.x.x, elles sont injoignables depuis Internet, donc je suis protégé. »

Ce qui protège, ce n’est pas la traduction d’adresse — c’est la table d’états. Le routeur laisse entrer une réponse parce qu’elle correspond à une conversation que vous avez initiée. C’est du filtrage à états, et ça existe très bien sans NAT.

La preuve par l’usage :

• Un DNAT ou une redirection de port perce le NAT en une ligne de configuration.
• UPnP laisse n’importe quelle application ouvrir des ports toute seule, sans vous demander votre avis. Sur beaucoup de box, c’est actif par défaut.
• Le NAT ne filtre rien du tout en sortie. Un poste compromis établit sa connexion vers l’extérieur, et le NAT lui déroule le tapis rouge — c’est exactement ce que fait chaque reverse shell de la Terre.
• Le NAT ne voit pas ce qui se passe à l’intérieur de votre réseau. Zéro protection latérale.

La formulation juste : le NAT est un mécanisme d’économie d’adresses qui a, par effet de bord, un comportement de filtrage à états. Confondre l’effet de bord avec l’intention est ce qui fait dire « je n’ai pas besoin de pare-feu, j’ai un NAT ». C’est faux, et c’est exactement le raisonnement qu’on a vu à la couche 2 avec le filtrage MAC : prendre un mécanisme de fonctionnement pour une mesure de sécurité.

La sécurité de la couche 3

Comme la 2, la couche 3 a été conçue entre gens de confiance. Mêmes causes, mêmes effets.

IP spoofing

Le principe : l’IP source d’un paquet est un champ de texte. Rien ne la vérifie. Vous écrivez ce que vous voulez.

La limite : si vous mentez sur votre source, les réponses partent chez le vrai propriétaire de cette IP, pas chez vous. Le spoofing est donc inutile pour établir une conversation TCP (il faudrait deviner le numéro de séquence, ce qui n’est plus réaliste). Il reste redoutable pour tout ce qui est unidirectionnel : UDP, floods, et surtout amplification.

Le schéma d’amplification : j’envoie une petite requête DNS ou NTP en usurpant votre IP. Le serveur répond — et sa réponse, bien plus grosse que la question, part chez vous. Multiplié par des milliers de serveurs, vous prenez un DDoS que je n’ai pas eu à payer. Le facteur d’amplification atteint plusieurs dizaines. C’est le genre de trafic qu’on finit par apprendre à reconnaître dans les logs d’un pare-feu.

La parade : uRPF (unicast Reverse Path Forwarding). Le routeur reçoit un paquet, regarde son IP source, et se demande : « si je devais répondre à cette adresse, est-ce que je passerais par l’interface d’où ce paquet arrive ? » Si non, c’est incohérent — le paquet ment sur son origine — et il est jeté. Simple, élégant, et efficace.

ICMP Redirect

Le principe : ICMP type 5 dit « pour cette destination, passe plutôt par X, il est mieux placé ». Un routeur légitime l’utilise pour corriger un chemin sous-optimal.

L’abus : n’importe qui sur le segment peut en envoyer. « Pour Internet, passe par moi. » Résultat : MITM, encore une fois. Version couche 3 de l’ARP spoofing, avec la même racine — aucune authentification.

La parade : on n’en a pratiquement jamais besoin. Désactivez.

sysctl -w net.ipv4.conf.all.accept_redirects=0
sysctl -w net.ipv4.conf.all.send_redirects=0

Directed broadcast (Smurf)

Envoyer un paquet à 192.168.1.255 depuis l’extérieur faisait répondre toutes les machines du réseau. Avec du spoofing, c’est une amplification maison. C’est l’attaque Smurf, et elle a fait des dégâts dans les années 90.

Elle est morte parce que no ip directed-broadcast est le défaut sur tout équipement moderne. À vérifier tout de même sur du matériel ancien, et sur ce qu’on ressort d’un carton.

Les ACL : filtrer sans état

Une ACL (liste de contrôle d’accès) filtre sur IP source, IP destination, protocole, ports. C’est le filtrage de base d’un routeur.

Deux caractéristiques à connaître, parce qu’elles piègent :

1. Un deny any any implicite est à la fin de toute ACL. Ce qui n’est pas explicitement autorisé est refusé. Une ACL qui ne contient que des permit bloque quand même tout le reste. Beaucoup de gens l’apprennent en coupant la production.
2. Une ACL classique est sans état. Elle ne sait pas qu’une réponse est une réponse. Il faut donc écrire les règles dans les deux sens — et là, on retombe sur le piège du retour, sous une autre forme.

C’est précisément cette limite qui justifie le pare-feu à états, qui, lui, suit les conversations. Mais ça déborde sur la couche 4, et c’est le sujet du prochain article.

La boîte à outils

Ce qui tombe en mise en situation, et ce qui sert vraiment.

Voir sa configuration

ip -br addr show                  # compact, lisible, ma préférée
ip route show                     # la table de routage
ip route get 8.8.8.8              # ← quelle route sera VRAIMENT utilisée
ipconfig /all                     # Windows
route print                       # Windows
show ip route                     # Cisco
show ip interface brief           # Cisco — l'état de toutes les interfaces d'un coup

Tester la connectivité, dans l’ordre

ping 127.0.0.1              # 1. ma pile IP fonctionne-t-elle ?
ping <mon IP>               # 2. mon interface est-elle configurée ?
ping <ma passerelle>        # 3. mon réseau local marche-t-il ?
ping 8.8.8.8                # 4. mon routage sort-il ?
ping google.com             # 5. mon DNS marche-t-il ?

Cette séquence est la meilleure méthode de diagnostic réseau qui existe, et elle tient en cinq lignes. Elle isole la panne par élimination, de l’intérieur vers l’extérieur. L’endroit où ça casse est le diagnostic. Et le classique : les étapes 1 à 4 passent, la 5 échoue → ce n’est pas le réseau, c’est le DNS. Ça n’a jamais été le réseau. C’est toujours le DNS.

Suivre le chemin

traceroute 8.8.8.8          # Linux (UDP par défaut)
traceroute -I 8.8.8.8       # en ICMP, comme Windows
traceroute -T -p 443 …      # en TCP — passe là où l'UDP est filtré
tracert 8.8.8.8             # Windows (ICMP)
mtr 8.8.8.8                 # ← traceroute + ping en continu

mtr mérite d’être connu. Il fait tourner le traceroute en boucle et affiche le taux de perte par saut, en temps réel. C’est l’outil qui distingue « le lien est lent » de « le lien perd 3 % des paquets au 4ᵉ saut ». Sur un problème intermittent, un traceroute unique ne montre rien ; mtr laissé cinq minutes montre tout.

Un piège de lecture, cela dit : de la perte sur un saut intermédiaire ne veut pas dire que ce saut est en panne. Beaucoup de routeurs dépriorisent la génération d’ICMP quand ils sont chargés — ils répondent mal à mtr tout en routant parfaitement le vrai trafic. Ce qui compte, c’est la perte sur le dernier saut. Si la destination finale est à 0 %, les 40 % affichés au milieu sont un artefact. C’est l’erreur d’interprétation la plus courante avec cet outil.

Le MTU

ping -M do -s 1472 8.8.8.8       # Linux : DF, 1472+28 = 1500
ping -f -l 1472 8.8.8.8          # Windows
ip link show eth0 | grep mtu     # le MTU de mon interface

Wireshark / tcpdump

tcpdump -i eth0 icmp                    # voir les erreurs du réseau
tcpdump -i eth0 host 192.168.1.50       # tout ce qui concerne une machine
tcpdump -i eth0 net 10.0.0.0/8          # tout un réseau
tcpdump -i eth0 'icmp[icmptype] == 3'   # ← toutes les destinations injoignables

Filtres Wireshark :

ip.addr == 192.168.1.50
ip.ttl < 5                    # paquets en fin de vie — boucle ?
icmp.type == 3                # les erreurs
icmp.type == 3 && icmp.code == 4     # ← les problèmes de MTU

Le dernier est votre ami. Si vous en voyez, vous tenez votre PMTUD.

Les erreurs classiques

• Donner une IP sans son masque — l’information est incomplète, littéralement.
• Croire aux classes A/B/C — mortes en 1993. Le masque par défaut proposé par Windows est une suggestion, pas une loi.
• Penser que 172.16.0.0/12 s’arrête à 172.16.255.255 — il va jusqu’à 172.31.255.255.
• Ne pas reconnaître 169.254.x.x — c’est « le DHCP n’a pas répondu », pas une adresse.
• Configurer le routage dans un seul sens — le retour est la moitié du travail.
• Deux passerelles par défaut — une machine n’en a qu’une. Le reste, ce sont des routes spécifiques.
• Bloquer tout ICMP — et casser la PMTUD sans jamais faire le lien.
• Confondre NAT et pare-feu — c’est le filtrage à états qui protège, pas la traduction.
• Oublier le deny any implicite d’une ACL — et couper la production.
• Chevaucher les sous-réseaux en VPN site-à-site — deux sites en 192.168.1.0/24 ne se joindront jamais. C’est le premier réflexe à avoir avant même de monter le tunnel. Et c’est aussi pour ça que 192.168.1.0/24 en infra perso est un mauvais choix : c’est le réseau par défaut de la moitié des box de France, et vous le rencontrerez chez tous vos futurs clients.

En pratique : ce que je retiens

1. Une IP sans masque n’est pas une adresse. Le masque est la moitié de l’information.
2. Longest prefix match. La route la plus spécifique gagne, toujours, sans exception. La spécificité est la priorité.
3. Le TTL est un compteur de sauts, pas un temps. Il empêche les boucles, il trahit l’OS, et il fait tourner traceroute.
4. Bloquer tout ICMP est une faute. Types 3 et 11 doivent passer. Ce sont les messages d’erreur du réseau.
5. Le NAT n’est pas une sécurité. Comme le filtrage MAC en couche 2 : un mécanisme de fonctionnement pris pour une frontière.
6. Le retour, toujours le retour. tcpdump sur la cible coupe le problème en deux en dix secondes.
7. ip route get répond en une seconde à ce que la lecture d’une table de routage met dix minutes à trancher.
8. La séquence de ping (loopback → interface → passerelle → 8.8.8.8 → nom) isole 90 % des pannes sans réfléchir.

La couche 3 sait acheminer un paquet de bout en bout, à travers le monde. Mais elle ne garantit rien : ni l’arrivée, ni l’ordre, ni l’unicité. Un paquet IP peut être perdu, dupliqué, ou arriver dans le désordre — et IP s’en moque éperdument. Elle fait au mieux, elle ne promet rien.

Alors comment un fichier de 4 Go arrive-t-il intact ?

C’est la couche 4. Prochain article.