MTU, MSS et fragmentation des paquets
Des pages qui se chargent à moitié, un VPN qui accepte le ping mais pas les transferts : les problèmes de MTU sont parmi les plus déroutants. Voici comment les comprendre, les tester et les corriger.
Chaque lien réseau impose une taille maximale aux paquets qu'il transporte. Lorsque cette limite est mal prise en compte — typiquement à cause d'un tunnel VPN ou d'un pare-feu qui bloque ICMP — on obtient des pannes partielles très déroutantes : le ping fonctionne, la connexion SSH s'ouvre, mais les transferts volumineux se figent.
Objectif : distinguer MTU et MSS, comprendre la fragmentation et la découverte de MTU, et savoir diagnostiquer puis corriger un « trou noir » MTU.
MTU et MSS : deux notions différentes
- La MTU (Maximum Transmission Unit) est la taille maximale d'un paquet IP (en-tête IP compris) qu'une interface peut émettre sans fragmentation. Elle vaut 1 500 octets sur Ethernet standard.
- Le MSS (Maximum Segment Size) est la taille maximale des données TCP dans un segment, en-têtes IP et TCP exclus. Chaque extrémité annonce son MSS lors de la poignée de main TCP (option MSS dans le SYN).
Sans options IP ni TCP :
MSS IPv4 = MTU − 20 (en-tête IPv4) − 20 (en-tête TCP) = 1 460 octets
MSS IPv6 = MTU − 40 (en-tête IPv6) − 20 (en-tête TCP) = 1 440 octets
| Contexte | MTU typique | Raison |
|---|---|---|
| Ethernet standard | 1 500 | Charge utile maximale d'une trame 802.3 |
| PPPoE (accès fibre ou ADSL de nombreux opérateurs) | 1 492 | 8 octets d'en-tête PPPoE |
| Tunnel GRE sur IPv4 | 1 476 | 24 octets d'encapsulation |
| IPsec ESP en mode tunnel | variable, souvent autour de 1 400 | Dépend des algorithmes, du mode et du NAT-T |
| WireGuard | 1 420 par défaut | Calculé pour fonctionner sur IPv4 et IPv6 avec une MTU sous-jacente de 1 500 |
| Trames jumbo (centre de données, stockage) | 9 000 environ | Doit être configuré sur tout le chemin |
La fragmentation IPv4
Lorsqu'un paquet IPv4 est plus grand que la MTU du lien de sortie, un routeur peut le fragmenter : il le découpe en plusieurs fragments, chacun avec son en-tête IP, que l'hôte de destination réassemble.
La fragmentation pose plusieurs problèmes :
- Coût : traitement supplémentaire sur le routeur et chez le destinataire.
- Fragilité : la perte d'un seul fragment impose la retransmission du paquet entier.
- Filtrage : seuls le premier fragment contient les ports TCP ou UDP, ce qui complique la tâche des pare-feu ; certains réseaux rejettent les fragments.
C'est pourquoi la plupart des piles TCP modernes positionnent le bit DF (Don't Fragment) et s'appuient sur la découverte de la MTU du chemin.
La découverte de la MTU du chemin (PMTUD)
Avec le bit DF positionné, un routeur qui ne peut pas transmettre un paquet trop grand le détruit et renvoie à l'émetteur un message ICMP type 3, code 4 (Fragmentation Needed and DF set) indiquant la MTU du lien suivant. L'émetteur réduit alors la taille de ses paquets. Ce mécanisme est défini par la RFC 1191 pour IPv4.
En IPv6, les routeurs ne fragmentent jamais : seul l'émetteur peut fragmenter, et il doit découvrir la MTU du chemin grâce aux messages ICMPv6 Packet Too Big (RFC 8201). La MTU minimale garantie sur tout lien IPv6 est de 1 280 octets.
Le trou noir MTU
Le problème survient lorsque les messages ICMP nécessaires à la PMTUD sont bloqués, souvent par un pare-feu configuré pour « bloquer tout ICMP ». L'émetteur n'est jamais informé que ses paquets sont trop grands :
- la poignée de main TCP réussit (petits paquets) ;
- les petites requêtes fonctionnent ;
- dès que des paquets pleins sont envoyés, ils disparaissent silencieusement ;
- la connexion se fige, puis expire.
Symptômes typiques : sites web qui se chargent partiellement, transferts de fichiers bloqués à 0 %, connexion SSH qui gèle à l'affichage d'une longue sortie, messagerie qui reçoit les petits messages mais pas les pièces jointes, problèmes apparaissant uniquement à travers un VPN.
Tester la MTU d'un chemin
On envoie des pings de taille croissante avec le bit DF positionné. La taille indiquée correspond aux données ICMP : il faut ajouter 28 octets (20 d'en-tête IP + 8 d'en-tête ICMP) pour obtenir la taille du paquet.
Linux
ping -c 2 -M do -s 1472 203.0.113.10 # 1472 + 28 = 1500 octets
ping -c 2 -M do -s 1400 203.0.113.10
tracepath -n 203.0.113.10 # affiche la PMTU découverte saut par saut
Windows
ping -f -l 1472 203.0.113.10
ping -f -l 1400 203.0.113.10
netsh interface ipv4 show subinterfaces # MTU configurée par interface
Interpréter
- « Message too long » / « Packet needs to be fragmented but DF set » : un équipement a renvoyé l'ICMP attendu ; la PMTUD fonctionne et l'on connaît la limite.
- Aucune réponse au-delà d'une certaine taille, alors que les petites tailles passent : un équipement détruit les paquets trop grands sans prévenir. C'est la signature d'un trou noir MTU.
Procédez par dichotomie pour trouver la taille maximale qui passe.
Corriger le problème
1. Rétablir la PMTUD
La meilleure correction consiste à autoriser les messages ICMP nécessaires : type 3 code 4 en IPv4, Packet Too Big (type 2) en ICMPv6. Bloquer tout ICMP n'apporte aucun bénéfice de sécurité significatif et casse le réseau.
2. Ajuster le MSS (MSS clamping)
Sur l'équipement qui crée le tunnel (routeur, pare-feu), on réécrit l'option MSS des segments SYN qui le traversent, afin que les hôtes n'envoient jamais de segments trop grands.
Exemple sur une interface tunnel Cisco IOS (laboratoire) :
interface Tunnel0
ip mtu 1400
ip tcp adjust-mss 1360
Exemple avec nftables sous Linux :
sudo nft add rule inet filter forward tcp flags syn tcp option maxseg size set rt mtu
Le MSS clamping ne concerne que TCP ; le trafic UDP volumineux (certains VPN, DNS avec grosses réponses) reste concerné par la MTU.
3. Réduire la MTU de l'interface
En dernier recours, ou pour une interface de tunnel, on peut abaisser la MTU :
sudo ip link set dev wg0 mtu 1380 # Linux, temporaire
netsh interface ipv4 set subinterface "Ethernet" mtu=1400 store=persistent
4. PMTUD par paquets (PLPMTUD)
Certaines piles implémentent la découverte de MTU par sondage (RFC 4821 pour TCP, RFC 8899 pour les protocoles datagrammes), qui ne dépend pas des messages ICMP. Linux propose par exemple le paramètre net.ipv4.tcp_mtu_probing.
Trames jumbo : précautions
Les trames jumbo réduisent la charge processeur pour les gros transferts (stockage iSCSI, réplication, réseaux de stockage). Elles exigent que tous les équipements du domaine de couche 2 — cartes, commutateurs, hyperviseurs — soient configurés avec la même MTU. Un seul maillon à 1 500 crée un trou noir. Testez systématiquement avec ping -M do -s 8972 (8 972 + 28 = 9 000).
Erreurs courantes
- Bloquer tout ICMP sur le pare-feu.
- Confondre MTU et MSS, ou oublier les 28 octets lors des tests ping.
- Activer les trames jumbo sur une partie du chemin seulement.
- Oublier l'encapsulation des VPN lors du dimensionnement.
- Appliquer un MSS clamping identique pour IPv4 et IPv6 sans tenir compte des 20 octets d'en-tête supplémentaires d'IPv6.
Implications de sécurité
La fragmentation a historiquement servi à contourner des filtres ou à provoquer des dénis de service (fragments chevauchants, réassemblages coûteux). Les systèmes modernes s'en protègent, et les pare-feu réassemblent ou normalisent les fragments. La règle de bonne pratique reste la même : filtrer finement ICMP plutôt que de le bloquer, conformément aux recommandations de la RFC 4890 pour ICMPv6.
Conclusion
Quand « le ping passe mais pas le reste », pensez MTU. Testez avec des pings de taille croissante et le bit DF, autorisez les messages ICMP indispensables, et appliquez un MSS clamping sur les tunnels. Ces trois gestes résolvent la grande majorité des cas, notamment avec les VPN.
