ICMP, ping, traceroute et la MTU

Pourquoi

Le ticket arrive un lundi matin : « depuis le passage par le nouveau VPN, on se connecte en SSH à sig-app-1, on tape ls, ça marche, on tape journalctl -u signalements, et le terminal se fige ». Le même jour, une autre équipe signale que curl https://signalements.exemple.fr/sante répond, mais que le téléchargement d'un export de signalements reste bloqué à zéro octet. Ping fonctionne. Les pare-feu « laissent passer le port ». Personne ne comprend.

Ces deux symptômes ont souvent la même cause : un paquet trop gros pour le chemin, et un message d'erreur qui aurait dû le signaler mais a été bloqué en route. Ce message, c'est ICMP, le protocole avec lequel le réseau parle aux machines : « destination injoignable », « TTL expiré », « paquet trop gros ». Beaucoup d'administrateurs le bloquent par réflexe, « parce que ping, c'est dangereux ». Cette leçon explique pourquoi c'est une erreur, et ce que ping, traceroute et la MTU révèlent du chemin.

Les concepts

ICMP, la voix du réseau

IP ne garantit rien : un paquet peut être perdu, détruit, refusé. Pour qu'un émetteur ait une chance de savoir pourquoi, la RFC 792 définit dès 1981 l'ICMP (Internet Control Message Protocol). Un message ICMP voyage dans un paquet IP (numéro de protocole 1), et la plupart contiennent le début du paquet qui a causé le problème (son en-tête IP et les 8 premiers octets de ce qui suit), ce qui permet à l'émetteur de savoir quelle connexion est concernée.

Les messages que vous rencontrerez, d'après la RFC 792 :

Le type 3 a plusieurs codes, qui disent pourquoi la remise est impossible :

Le code 4 est le héros discret de cette leçon. Une règle de la RFC 792 évite les boucles : aucun message d'erreur ICMP n'est envoyé à propos d'un message d'erreur ICMP.

En IPv6, le rôle est tenu par ICMPv6, avec des numéros différents (Destination Unreachable = 1, Packet Too Big = 2, Time Exceeded = 3, écho = 128 et 129) et des responsabilités en plus : la découverte des voisins, qui remplace ARP, passe par ICMPv6. En IPv6, bloquer ICMP casse le réseau local lui-même (leçon 8).

ping : ce qu'il prouve

ping envoie des demandes d'écho et mesure le temps de réponse (le RTT, round-trip time, aller-retour). Un ping réussi prouve trois choses : la destination est joignable au niveau IP, elle accepte de répondre aux échos, et le chemin fonctionne dans les deux sens pour de petits paquets.

Il ne prouve pas que le service fonctionne : ping sig-app-1 peut répondre pendant que Gunicorn est arrêté. Il ne prouve pas que le port 8000 est ouvert, ni que les gros paquets passent.

Un ping échoué prouve encore moins. Beaucoup de machines et de pare-feu ne répondent pas aux échos par choix : les instances derrière un groupe de sécurité qui n'autorise pas ICMP, certains répartiteurs de charge, la plupart des pare-feu d'entreprise. « Ça ne pingue pas » ne veut pas dire « c'est en panne ». Pour tester un service, on teste le service : curl, nc -zv hôte port (leçon 12).

TTL et traceroute

La leçon 5 a montré que chaque routeur décrémente le TTL et, quand il tombe à zéro, détruit le paquet et renvoie un ICMP Time Exceeded. traceroute détourne ce garde-fou en instrument de mesure :

1. il envoie un paquet avec un TTL de 1 : le premier routeur le détruit et répond Time Exceeded, ce qui révèle son adresse ;
2. puis un TTL de 2 : le deuxième routeur se dévoile ;
3. et ainsi de suite, jusqu'à ce que la destination elle-même réponde.

    sequenceDiagram
  participant P as Poste
  participant R1 as Box
  participant R2 as Routeur opérateur
  participant D as 203.0.113.10
  P->>R1: sonde TTL=1
  R1-->>P: ICMP Time Exceeded
  P->>R1: sonde TTL=2
  R1->>R2: TTL=1
  R2-->>P: ICMP Time Exceeded
  P->>R1: sonde TTL=3
  R1->>R2: TTL=2
  R2->>D: TTL=1
  D-->>P: réponse de la destination
  

Le traceroute de Linux envoie par défaut, d'après sa page de manuel, des datagrammes UDP vers des ports « improbables », à partir de 33434 et en ajoutant un à chaque sonde, trois sondes par saut, jusqu'à 30 sauts. Quand la sonde atteint la destination, celle-ci n'a rien qui écoute sur ce port et répond ICMP Port Unreachable (type 3, code 3) : c'est ainsi que traceroute sait qu'il est arrivé. Deux autres méthodes contournent les pare-feu qui bloquent ces ports :

• -I utilise des demandes d'écho ICMP, comme ping ;
• -T envoie des segments TCP SYN, par défaut vers le port 80, ce qui passe là où seul le web est autorisé ; l'outil tcptraceroute en est l'équivalent.

Dans la sortie, une étoile (*) signifie qu'aucune réponse n'est arrivée dans le délai pour cette sonde. Trois étoiles sur une ligne, puis des réponses aux lignes suivantes : ce routeur ne répond pas aux sondes (ou limite ses réponses ICMP), mais il transmet le trafic, sinon les sauts suivants seraient muets eux aussi. Des annotations après le temps signalent une erreur : !H hôte injoignable, !N réseau injoignable, !P protocole injoignable, !X communication interdite, !F fragmentation nécessaire.

tracepath, du paquet iputils, fait la même chose sans privilège et découvre en plus la MTU du chemin. mtr combine traceroute et ping en continu, et montre les pertes par saut ; on l'installe à part.

La MTU

Chaque lien a une taille maximale de paquet qu'il peut transporter en une trame : la MTU (Maximum Transmission Unit). Sur Ethernet, elle vaut 1 500 octets de charge utile, c'est-à-dire le paquet IP complet, en-tête compris. Un paquet IPv4 de 1 500 octets contient 20 octets d'en-tête IP ; s'il porte un segment TCP, 20 octets d'en-tête TCP (sans options) ; il reste 1 460 octets de données. Pour un ping, l'en-tête ICMP fait 8 octets : la plus grande charge utile d'un écho qui tient en 1 500 octets est 1 500 − 20 − 8 = 1 472 octets.

Les tailles à connaître :

Le calcul de WireGuard se lit dans le script wg-quick lui-même : il prend la MTU de la route vers le pair (1 500 par défaut) et lui retire 80 octets, ce qui couvre l'en-tête de WireGuard (32 octets), l'UDP (8) et le cas le plus défavorable d'un en-tête IPv6 extérieur (40).

La MSS (Maximum Segment Size) est la notion voisine côté TCP : la quantité maximale de données dans un segment, en-têtes exclus. Chaque côté annonce la sienne dans l'option MSS de son SYN, calculée à partir de la MTU de son interface (1 500 − 40 = 1 460 sur Ethernet en IPv4). La RFC 9293 précise que cette option n'est envoyée que dans les segments SYN, et qu'en son absence, un émetteur doit supposer 536 octets en IPv4 et 1 220 en IPv6.

Quand le paquet est trop gros : la fragmentation

Que se passe-t-il quand un routeur doit faire passer un paquet de 1 500 octets sur un lien de MTU 1 420 ? En IPv4, deux réponses, selon le bit DF (Don't Fragment) de l'en-tête :

• DF à 0 : le routeur fragmente. Il découpe la charge utile en morceaux, chacun emballé dans un en-tête IP qui reprend l'identifiant du paquet d'origine, le décalage du morceau (fragment offset, en unités de 8 octets) et le bit MF (More Fragments) à 1 sauf pour le dernier. La destination réassemble. La RFC 791 décrit ce mécanisme, qui fonctionne mais coûte cher : la perte d'un seul fragment fait perdre tout le paquet, les pare-feu ont du mal à filtrer des fragments sans en-tête de transport, et le réassemblage a servi de nombreuses attaques.
• DF à 1 : le routeur refuse, détruit le paquet et renvoie à l'émetteur un ICMP Destination Unreachable, code 4, « fragmentation nécessaire mais DF positionné ». Depuis la RFC 1191, ce message contient la MTU du lien suivant.

En IPv6, les routeurs ne fragmentent jamais : seule la source peut fragmenter, et un paquet trop gros provoque toujours un ICMPv6 Packet Too Big.

La découverte du MTU du chemin

Le chemin entre deux machines traverse des liens de MTU différentes. La plus petite d'entre elles est la MTU du chemin (PMTU, Path MTU). La RFC 1191 décrit comment la découvrir sans fragmenter :

1. la source suppose d'abord que la MTU du chemin est celle de sa propre interface, et envoie tout avec DF à 1 ;
2. si un routeur ne peut pas transmettre, il renvoie l'ICMP code 4 avec sa MTU ;
3. la source réduit son estimation pour cette destination, et renvoie des paquets plus petits ;
4. de temps en temps (pas avant cinq minutes après une réduction, dit la RFC), elle réessaie plus gros, au cas où le chemin aurait changé.

Linux applique ce mécanisme par défaut : TCP envoie ses segments avec DF, et garde une MTU par destination dans son cache de routes. On la voit dans ip route get <destination>, qui affiche alors mtu et un délai d'expiration, une fois une réduction apprise. Le réglage net.ipv4.route.min_pmtu (552 par défaut) fixe un plancher en dessous duquel le noyau refuse de descendre.

Le trou noir PMTU

Tout repose sur l'ICMP code 4. S'il ne revient pas, la source continue d'envoyer des paquets trop gros, qui sont détruits en silence. C'est un trou noir PMTU (PMTU black hole). La RFC 8899 en cite les deux causes habituelles : la limitation du débit des messages ICMP par les routeurs, et surtout le filtrage d'ICMP par un pare-feu.

Le symptôme est caractéristique, et explique le ticket du début :

• la connexion s'établit : les segments SYN, SYN-ACK et ACK sont petits ;
• les petits échanges passent : ls, une requête GET /sante et sa courte réponse ;
• le premier gros paquet disparaît : la sortie d'un journalctl, un certificat TLS (souvent plusieurs kilooctets), le corps d'un export. TCP le retransmet, à la même taille, jusqu'à abandonner. Le terminal se fige, le téléchargement reste à zéro.

Et ping fonctionne, puisqu'il envoie par défaut 84 octets.

Deux familles de remèdes existent :

• réparer la signalisation : autoriser ICMP Destination Unreachable (et ICMPv6 Packet Too Big) dans les pare-feu. La RFC 4890 est sans ambiguïté pour IPv6 : les messages Packet Too Big ne doivent pas être jetés, sans quoi des parties d'Internet deviennent inaccessibles ;
• se passer de la signalisation : la découverte au niveau de la couche transport (PLPMTUD, RFC 4821 pour TCP, généralisée par la RFC 8899 à UDP, SCTP et QUIC) sonde le chemin avec des paquets de tailles croissantes et observe lesquels sont acquittés. Linux l'active pour TCP avec net.ipv4.tcp_mtu_probing : la documentation du noyau décrit la valeur 1 (désactivé par défaut, activé quand un trou noir est détecté) et 2 (toujours actif). Ubuntu garde 0.

Et une rustine très répandue, au bord des tunnels : le MSS clamping. Un routeur ou un pare-feu qui voit passer un SYN réécrit l'option MSS pour la ramener à une valeur qui tient dans le tunnel. Les deux extrémités n'enverront jamais de segments plus gros, quel que soit le sort d'ICMP. Le wiki de nftables en donne la règle type :

nft add rule ip filter forward tcp flags syn tcp option maxseg size set rt mtu

rt mtu prend la MTU de la route de sortie ; une valeur fixe (set 1452, l'exemple du wiki pour PPPoE : 1 500 − 20 − 20 − 8) convient aussi. Le MSS clamping ne fait rien pour UDP ni pour QUIC.

En pratique

Les sorties de cette section sont réelles, produites sur Ubuntu 24.04 avec iputils 20240117. Elles visent l'interface de bouclage, 127.0.0.1, pour être reproductibles sans dépendre de votre réseau ; refaites ensuite les mêmes commandes vers votre passerelle.

Lire un ping

$ ping -c 3 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.082 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.053 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.099 ms

--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2076ms
rtt min/avg/max/mdev = 0.053/0.078/0.099/0.019 ms

• 56(84) bytes of data : 56 octets de données, 84 octets de paquet IP (56 + 8 d'en-tête ICMP + 20 d'en-tête IP).
• 64 bytes from : la taille du message ICMP reçu, en-tête ICMP compris.
• icmp_seq : le numéro de séquence ; un trou dans la séquence signale une perte, un ordre inversé un réordonnancement.
• ttl=64 : le TTL du paquet reçu. 64 est la valeur de départ de Linux : aucun routeur traversé.
• time : l'aller-retour. Sur le bouclage, quelques dizaines de microsecondes ; sur un réseau local, une fraction de milliseconde ; entre Paris et Amsterdam, une dizaine de millisecondes.
• La dernière ligne : minimum, moyenne, maximum et écart moyen (mdev, une mesure de la gigue).

Les options utiles :

• -c 3 : trois échos puis s'arrêter (sans -c, ping continue jusqu'à Ctrl+C). Dans un script, toujours -c.
• -W 2 : attendre au plus deux secondes une réponse.
• -i 0.2 : un écho toutes les 200 ms ; la page de manuel précise que seul root peut descendre sous 2 ms.
• -s 1472 : la taille des données.
• -M do : positionner le bit DF et interdire la fragmentation locale (want fragmenterait localement, dont n'active pas DF).
• -n : ne pas résoudre les adresses en noms, pour une sortie plus rapide et sans dépendre du DNS.

ping fonctionne sans sudo sur Ubuntu parce que le binaire porte la capacité cap_net_raw (getcap /usr/bin/ping), qui lui permet d'ouvrir une socket brute.

Mesurer la MTU avec DF

Avec DF positionné, le noyau refuse d'émettre un paquet plus gros que la MTU qu'il connaît pour la route :

$ ip link show lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
$ ping -c 1 -M do -s 65507 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 65507(65535) bytes of data.
65515 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.226 ms

--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.226/0.226/0.226/0.000 ms
$ ping -c 1 -M do -s 65508 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 65508(65536) bytes of data.
ping: local error: message too long, mtu=65535

--- 127.0.0.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

L'interface de bouclage annonce une MTU de 65 536, mais le plus gros écho qui passe fait 65 507 octets de données, soit un paquet IP de 65 535 octets. La raison est dans l'en-tête IPv4 : le champ Total Length fait 16 bits, et ne peut donc pas dépasser 65 535. Le noyau le dit (mtu=65535), et refuse localement (local error) : le paquet n'est jamais parti. C'est le même mécanisme qui, sur un tunnel, refusera un paquet de 1 500 octets quand la MTU apprise est de 1 420.

Sur un lien Ethernet ordinaire, le test classique consiste à envoyer 1 472 octets de données (1 500 − 20 − 8) avec DF vers une machine distante : s'il passe, la MTU du chemin est au moins de 1 500 ; sinon, on réduit jusqu'à trouver la limite. Vers sig-app-1 à travers un tunnel WireGuard, -s 1392 (1 420 − 28) devrait être la plus grande taille qui passe.

Sans -M do, une grande taille est fragmentée par l'émetteur et réassemblée à l'arrivée, sans erreur :

$ ping -c 1 -s 2000 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 2000(2028) bytes of data.
2008 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.053 ms

(Sur le bouclage, 2 028 octets tiennent dans la MTU, et rien n'est fragmenté ; vers une machine Ethernet, ce même ping partirait en deux fragments.)

tracepath : le chemin et sa MTU

$ tracepath -n 127.0.0.1
 1:  127.0.0.1                                             0.143ms reached
     Resume: pmtu 65535 hops 1 back 1

Sur le bouclage, un seul « saut », la destination elle-même (reached). La ligne Resume donne la MTU du chemin découverte (pmtu 65535), le nombre de sauts à l'aller et au retour (déduit du TTL des réponses). Vers une machine distante, chaque ligne montre un routeur, et tracepath signale les changements de MTU en route (pmtu 1420 après l'entrée dans un tunnel, par exemple). C'est l'outil le plus rapide pour repérer un rétrécissement de MTU sans sudo.

traceroute, sur un vrai chemin

Vers l'adresse publique du répartiteur de Signalements, depuis le poste de Camille, les trois méthodes s'écrivent ainsi (-n évite la résolution de noms) :

$ traceroute -n 203.0.113.10          # UDP, ports 33434 et suivants
$ traceroute -n -I 203.0.113.10       # demandes d'écho ICMP
$ sudo traceroute -n -T -p 443 203.0.113.10   # TCP SYN vers le port 443

On attend une première ligne avec la box (192.168.1.1), quelques routeurs du fournisseur d'accès et des opérateurs, puis l'entrée chez Scaleway. Selon la politique du répartiteur, la dernière ligne peut rester en étoiles avec les méthodes UDP et ICMP, et n'aboutir qu'avec -T -p 443, puisque c'est le seul port qu'il sert. La méthode TCP demande des privilèges sur la plupart des systèmes.

Vous n'irez pas plus loin que le répartiteur : sig-app-1 est dans un réseau privé, derrière une terminaison de connexion. Un traceroute ne traverse pas un mandataire (proxy) ou un répartiteur qui termine TCP.

Sous le capot

Ce que la source fait d'un ICMP code 4. Quand un tel message arrive, le noyau lit les 8 premiers octets de l'en-tête de transport qu'il contient pour retrouver la socket concernée, met à jour la MTU de la route vers cette destination dans son cache, et TCP réduit sa taille de segment. Les retransmissions suivantes partent plus petites. Tout cela prend un aller-retour, invisible pour l'application. C'est la raison pour laquelle l'ICMP doit revenir jusqu'à la source : un pare-feu en sortie de réseau qui le jette suffit à créer le trou noir.

La limitation de débit d'ICMP. Les routeurs et les hôtes limitent le nombre de messages ICMP qu'ils émettent (sous Linux, net.ipv4.icmp_ratelimit, une valeur en millisecondes), pour ne pas devenir eux-mêmes une source d'inondation. Conséquence : dans un traceroute, un routeur qui affiche des étoiles intermittentes ou des temps élevés n'est pas forcément surchargé ; il répond peut-être simplement aux sondes avec une faible priorité, alors qu'il transmet le vrai trafic à pleine vitesse. Un temps élevé sur un saut intermédiaire, et normal aux sauts suivants, ne signale pas de problème.

Les fragments et les pare-feu. Seul le premier fragment d'un paquet porte l'en-tête TCP ou UDP, donc les ports. Un pare-feu qui filtre par port doit soit réassembler les fragments (ce que fait le suivi de connexions de Linux, nf_conntrack, avant le filtrage), soit les laisser passer à l'aveugle, soit les jeter. Beaucoup les jettent, ce qui casse les protocoles UDP qui envoient de gros datagrammes (DNS avec DNSSEC, certains VPN).

Pourquoi 1 500 octets ? La valeur vient des premières normes Ethernet, au tournant des années 1980 : un compromis entre l'efficacité (de gros paquets) et la mémoire coûteuse des cartes de l'époque. Elle est restée, parce que tout Internet s'est construit en la supposant. C'est pour cela que chaque tunnel, chaque en-tête ajouté par un réseau virtuel, se paie en octets retirés à l'application.

Pièges courants

Bloquer tout ICMP « par sécurité ». C'est la cause la plus fréquente de trous noirs PMTU, et cela rend aussi traceroute et le diagnostic aveugles. Autorisez au minimum, en entrée, les Destination Unreachable (surtout le code 4) et Time Exceeded liés à vos connexions, ce que font automatiquement les pare-feu à état pour le trafic relatif à une connexion établie ; et, en IPv6, suivez la RFC 4890.

Conclure « en panne » d'un ping sans réponse. Le groupe de sécurité peut ne pas autoriser ICMP, la machine peut ignorer les échos. Testez le service (curl, nc -zv), ou un autre hôte du même réseau, avant de conclure.

Conclure « réseau OK » d'un ping qui répond. Un ping de 84 octets passe là où un segment de 1 500 octets disparaît. Pour suspecter la MTU, pingez gros avec DF : ping -M do -s 1472.

Oublier la MTU en montant un tunnel. Un VPN, un réseau de conteneurs en VXLAN, un réseau virtuel de Kubernetes ajoutent des en-têtes. Si l'interface interne garde une MTU de 1 500, chaque gros paquet doit être fragmenté ou provoque une erreur. Réglez la MTU des interfaces internes (wg-quick le fait pour WireGuard), ou le MSS clamping.

Lire un temps élevé au milieu d'un traceroute comme un goulet. Si les sauts suivants ont des temps normaux, ce routeur répond lentement aux sondes, sans ralentir le trafic. Seule une augmentation qui persiste jusqu'à la destination indique un problème sur le chemin.

Croire que les jumbo frames s'activent d'un côté. Une MTU de 9 000 sur une instance dont le réseau ne la supporte pas produit exactement un trou noir. Toutes les machines d'un même segment, et les commutateurs, doivent être d'accord.

Sécurité

ICMP a eu ses attaques, qui sont réglées depuis longtemps. Le ping of death (un écho fragmenté qui dépassait 65 535 octets au réassemblage) a été corrigé dans les systèmes dans les années 1990. Les attaques par réflexion vers une adresse de diffusion (smurf) sont neutralisées par les routeurs qui ne transmettent plus les diffusions dirigées. Filtrer finement ICMP a du sens ; le bloquer en entier n'en a pas.

Ce qu'il est raisonnable de filtrer. Sur un serveur exposé : refuser les Redirect (leçon 5), éventuellement les échos venant d'Internet si la politique le demande (en sachant que cela gêne surtout le diagnostic, pas un attaquant, qui dispose d'autres moyens de découvrir vos machines). Laisser passer les erreurs (Destination Unreachable, Time Exceeded, Packet Too Big) liées aux connexions en cours.

ICMP comme canal caché. Le champ de données d'un écho peut transporter n'importe quoi : des outils s'en servent pour faire sortir des données d'un réseau qui n'autorise que le ping. La détection repose sur le volume et la taille anormale des échos, pas sur l'interdiction d'ICMP.

Les informations révélées. traceroute dévoile la topologie d'un réseau, et le TTL des réponses donne une indication sur le système d'exploitation (64 pour Linux, 128 pour Windows). Les réseaux d'entreprise masquent souvent leurs routeurs internes ; c'est un choix de discrétion, à peser contre la facilité de diagnostic.

En production

Dans le cloud, les MTU ne sont pas toujours 1 500. Les réseaux virtuels des fournisseurs encapsulent le trafic des clients ; selon les fournisseurs et les types de réseau, la MTU proposée aux instances peut être différente, plus grande (trames géantes à l'intérieur d'un VPC) ou plus petite. Lisez la MTU de l'interface (ip link) plutôt que de la supposer, et vérifiez la documentation réseau du fournisseur avant d'activer des trames géantes.

Les réseaux de conteneurs empilent les en-têtes. Un cluster Kubernetes dont les nœuds sont dans un réseau privé de MTU 1 500, avec un réseau de pods en VXLAN, doit donner aux pods une MTU de 1 450 au plus. Les CNI modernes le calculent eux-mêmes ; une erreur de configuration se manifeste exactement comme un trou noir PMTU, entre pods de nœuds différents seulement.

Au bord des VPN, le MSS clamping est la règle. Les passerelles VPN et les routeurs PPPoE l'appliquent presque toujours, parce qu'on ne contrôle pas les pare-feu d'Internet. Si vous montez votre propre passerelle Linux, ajoutez la règle nftables vue plus haut dans la chaîne de transmission, dans les deux sens.

Surveillez les retransmissions, pas seulement les pings. Un trou noir PMTU ne fait pas tomber les sondes de supervision par ping ; il fait grimper les retransmissions TCP (nstat -az TcpRetransSegs, ou les métriques du nœud dans votre supervision) et les délais des transferts. Une supervision applicative (une vraie requête HTTP qui télécharge plusieurs kilooctets) le détecte, un ping non.

Exercices

1. Les messages (niveau 100). Pour chaque situation, donnez le message ICMP attendu (type et, si besoin, code) : (a) un traceroute atteint un routeur au troisième saut ; (b) une sonde UDP de traceroute arrive sur la destination finale ; (c) un paquet de 1 500 octets avec DF doit traverser un lien de MTU 1 420 ; (d) un pare-feu refuse explicitement une connexion et le signale.

2. Les tailles (niveau 100). Un tunnel a une MTU de 1 420. Quelle est (a) la plus grande charge utile d'un ping -M do qui passe ; (b) la MSS que TCP devrait annoncer en IPv4 ; (c) la même MSS en IPv6 ?

3. Le ticket du lundi (niveau 200). Reprenez les symptômes du début de la leçon : connexion SSH établie, ls qui répond, journalctl qui fige le terminal ; ping fonctionne. Proposez trois commandes pour confirmer l'hypothèse d'un trou noir PMTU, puis deux corrections, en disant laquelle vous préférez.

4. Lire un traceroute (niveau 200). Un traceroute -n vers une destination donne : saut 1 à 1 ms ; saut 2 à 9 ms ; saut 3 : * * * ; saut 4 à 11 ms ; saut 5 à 180 ms ; sauts 6 à 8 entre 12 et 14 ms ; le saut 8 est la destination. Que concluez-vous des sauts 3 et 5 ?

5. Tunnel et Kubernetes (niveau 200). Les nœuds d'un cluster sont dans un réseau privé de MTU 1 500. Le réseau des pods utilise VXLAN. Quelle MTU donner aux interfaces des pods ? Que se passe-t-il si on les laisse à 1 500, et pourquoi le problème n'apparaît-il qu'entre pods de nœuds différents ?

Récapitulatif

• ICMP est la voix du réseau : écho (ping), Destination Unreachable et ses codes (port injoignable, fragmentation nécessaire), Time Exceeded. Aucune erreur ICMP n'est émise à propos d'une erreur ICMP.
• Un ping réussi prouve la joignabilité IP pour de petits paquets ; un ping échoué ne prouve presque rien. On teste un service par le service.
• traceroute fait expirer le TTL saut par saut ; sous Linux, sondes UDP par défaut, -I ICMP, -T TCP. Une étoile isolée ou un temps élevé au milieu ne signalent pas une panne.
• La MTU limite la taille d'un paquet sur un lien (1 500 sur Ethernet) ; la MSS limite les données d'un segment TCP (1 460). Chaque tunnel en retire : 80 octets pour wg-quick, 50 pour VXLAN.
• IPv4 peut fragmenter si DF vaut 0 ; avec DF, un routeur renvoie un ICMP code 4 avec sa MTU, base de la découverte du MTU du chemin. IPv6 ne fragmente jamais en route.
• Sans cet ICMP, c'est le trou noir PMTU : connexion établie, petits échanges qui passent, gros paquets perdus. Remèdes : laisser passer ICMP, MSS clamping, sondage au niveau transport (PLPMTUD).
• Ne bloquez jamais tout ICMP, et suivez la RFC 4890 en IPv6.

Pour aller plus loin

• La RFC 1191, courte et très claire, qui explique la découverte du MTU du chemin et ses pièges.
• La RFC 4890, pour une politique de filtrage d'ICMPv6 argumentée, message par message.
• Les pages de manuel ping(8), tracepath(8) et traceroute(1), pour toutes les options.
• La leçon suivante, sur la traduction d'adresses, qui change les adresses des paquets en route et explique pourquoi la box de Camille peut partager une seule adresse publique.