MTU trop grand : le bug réseau qui laisse passer les pings et bloque tout le reste

L'essentiel

• Symptôme caractéristique : les petits échanges passent, les gros se figent. Ping et DNS fonctionnent, les transferts bloquent.
• Un tunnel ajoute des en-têtes : le paquet dépasse la limite du lien et doit être fragmenté ou rejeté.
• La découverte automatique de la taille maximale repose sur des messages ICMP que de nombreux pare-feux bloquent — le paquet disparaît alors sans erreur.
• Le test décisif : un ping de taille croissante avec interdiction de fragmenter, qui donne la taille exacte du plus grand paquet acceptable.
• Corrigez au bon endroit : ajuster le MTU du tunnel vaut mieux que rapiécer la taille des segments TCP.

Le tableau est toujours à peu près le même. Le VPN est monté, le ping répond, le DNS résout. Mais la page web charge à moitié, la session SSH se fige juste après la bannière, et le transfert de fichier reste bloqué à 4 % indéfiniment.

On soupçonne le pare-feu, le routage, le fournisseur d'accès. C'est presque toujours le MTU.

La signature à reconnaître

Un problème de MTU se distingue d'une panne réseau ordinaire par son asymétrie : les petits échanges passent, les gros échouent.

• Le ping fonctionne — il envoie de tout petits paquets.
• Le DNS fonctionne — les requêtes tiennent dans un paquet.
• La connexion SSH s'établit, puis se fige dès qu'il faut afficher quelque chose de volumineux.
• Une page web charge le texte, jamais les images.
• Un transfert démarre et s'arrête à un pourcentage qui ne bouge plus.

Ce mélange de succès et de blocages selon la taille est très spécifique. Quand vous le voyez, testez le MTU en premier — cela vous épargnera des heures passées à relire des règles de pare-feu innocentes.

Pourquoi les tunnels déclenchent ce problème

Le MTU est la taille maximale d'un paquet sur un lien. Sur de l'Ethernet classique, c'est 1500 octets.

Un tunnel encapsule : il enveloppe chaque paquet dans ses propres en-têtes avant de l'expédier. Un paquet de 1500 octets, parfaitement légal sur votre réseau local, en fait davantage une fois habillé. Il dépasse alors la limite du lien qu'il doit emprunter.

Deux issues possibles : le fragmenter, ou le rejeter. Et si le paquet porte le drapeau interdisant la fragmentation — ce que fait TCP en permanence — il ne reste que le rejet.

Le rejet silencieux

Il existe pourtant un mécanisme prévu pour cela : quand un équipement rejette un paquet trop grand qui interdit la fragmentation, il renvoie un message ICMP indiquant la taille acceptable. L'émetteur ajuste, et tout rentre dans l'ordre.

Sauf que beaucoup de pare-feux bloquent l'ICMP, par une prudence mal placée qui consiste à tout interdire sans distinguer les messages utiles.

Le message n'arrive jamais. L'émetteur ne sait pas que ses paquets meurent en route. Il les réémet à l'identique, indéfiniment. La connexion ne renvoie aucune erreur : elle se fige, simplement.

Le test qui tranche en trois minutes

La méthode est directe : envoyer des pings de taille croissante en interdisant la fragmentation, et repérer où ça s'arrête.

Vous augmentez la charge utile jusqu'à ce que les réponses cessent. La dernière valeur qui passe, plus 28 octets d'en-têtes (20 pour IP, 8 pour ICMP), donne le MTU réellement utilisable sur le chemin.

Procédez par dichotomie : essayez 1472, puis selon le résultat 1400 ou 1440, et resserrez. Trois ou quatre essais suffisent.

Un détail qui a son importance : testez vers la destination réelle, pas vers la passerelle. Le MTU est une propriété du chemin complet, et le maillon le plus contraignant peut se trouver n'importe où.

Corriger au bon endroit

Une fois la valeur connue, deux corrections sont possibles — et elles ne sont pas équivalentes.

Ajuster le MTU de l'interface du tunnel est la correction propre. Vous déclarez à l'interface qu'elle ne doit pas émettre de paquets dépassant la taille mesurée, en tenant compte des en-têtes d'encapsulation. Tout le trafic en bénéficie, TCP comme UDP.

Ajuster la taille des segments TCP est un correctif de rattrapage : l'équipement réécrit à la volée la taille annoncée lors de l'établissement des connexions, forçant les deux extrémités à rester sous la limite. C'est utile quand vous ne maîtrisez pas les machines clientes.

Mais cette seconde méthode a une limite nette : elle ne concerne que TCP. Tout ce qui passe en UDP — DNS volumineux, visioconférence, certains VPN — reste cassé. Elle traite le symptôme le plus visible, pas la cause.

La bonne pratique : corriger le MTU de l'interface, et n'utiliser l'ajustement TCP qu'en complément lorsqu'un chemin échappe à votre contrôle.

Les trames étendues, l'autre source d'ennuis

Le problème inverse existe. On active les trames étendues sur un réseau de stockage pour améliorer le débit, en portant le MTU à 9000 octets. Le gain est réel — à condition que tous les équipements du chemin soient configurés à l'identique.

Un seul commutateur resté à 1500, et vous obtenez exactement les mêmes symptômes : les petits échanges passent, les gros disparaissent. Avec une difficulté supplémentaire : comme le problème est né d'une optimisation censée améliorer les choses, on cherche rarement de ce côté.

Si vous activez les trames étendues, faites-le partout ou nulle part, et vérifiez ensuite avec le test de ping. C'est trois minutes qui évitent trois jours.