Découverte du MTU de chemin à travers un VPN : dimensionnement et la faille ICMP

Un tunnel termine sa poignée de main, les petites requêtes reviennent, et le premier gros transfert se bloque. Ce schéma désigne le MTU de chemin bien avant le débit. Chaque liaison sur la route plafonne la taille du paquet, et l'encapsulation dépense une partie de cette marge en en-têtes externes, si bien que le paquet interne doit être plus petit que ne le laisserait croire le chemin brut. La panne est silencieuse, et c'est ce qui la rend coûteuse à diagnostiquer.

Ce que le MTU de chemin mesure réellement

Le MTU de chemin est le plus petit MTU de liaison sur la route entre deux hôtes, pas le MTU imprimé sur votre interface locale. La valeur locale est le point de départ de l'estimation, et le chemin décide où elle doit finir. C'est pourquoi un tunnel identique peut fonctionner sur un réseau d'accès et se bloquer sur un autre : la route a changé, pas la configuration. Mesurer une fois et supposer partout est l'erreur qui maintient ce problème en vie.

Pour un tunnel, le nombre qui compte est le MTU interne, c'est-à-dire la marge du chemin externe moins tout ce que consomme l'encapsulation. WireGuard ajoute un en-tête IP externe et un en-tête UDP ; d'autres transports ajoutent les leurs. Réglez la taille interne trop haut et chaque paquet de taille maximale exigera une fragmentation qui pourrait ne jamais se produire.

Pourquoi un tunnel réduit le paquet utilisable

Si l'interface du tunnel conserve le MTU de la liaison physique, chaque gros paquet dépend de la volonté d'un équipement en aval de le fragmenter. IPv4 l'autorise en principe, mais un routeur auquel on a interdit la fragmentation renvoie une erreur à la place. Les routeurs IPv6 ne fragmentent jamais en transit, donc le même réglage se comporte différemment selon la famille d'adresses. Dans les deux cas, l'émetteur n'apprend rien avant qu'un élément ne lui rende compte.

La conséquence pratique est une taille qui convient à la poignée de main et non à la charge utile. Un TLS ClientHello ou une requête DNS est assez petit pour traverser un chemin réduit sans dommage, tandis qu'un transfert en masse ne l'est pas. Les symptômes se regroupent donc autour d'opérations précises plutôt que d'hôtes précis.

La découverte ne fonctionne que si le retour d'information arrive

La découverte IPv4 repose sur le bit « ne pas fragmenter » : un routeur qui ne peut pas transmettre le paquet renvoie ICMP fragmentation-needed avec le MTU du saut suivant, et l'émetteur abaisse son estimation. IPv6 utilise plutôt les messages Packet Too Big, parce que les routeurs ne fragmentent pas en transit. Les deux mécanismes supposent que le message retrouve son chemin vers l'émetteur, à travers le tunnel et au-delà de tout pare-feu sur le chemin de retour. Quand cette hypothèse échoue, l'émetteur réessaie sans cesse une taille que le chemin ne peut pas porter.

Un pare-feu qui autorise echo request et echo reply n'a pas forcément autorisé ces types d'erreur. ICMP est une famille, et les membres qui comptent ici sont les erreurs, pas la paire d'écho. Vérifiez la politique de trafic de contrôle aux deux extrémités du tunnel et sur le chemin entre elles, et suivez les recommandations prises en charge de la plateforme au lieu d'autoriser tous les types ICMP partout.

Le même filtrage peut se trouver à l'intérieur du tunnel. Si le chemin interne abandonne l'erreur mais que le chemin externe la transporte, l'émetteur peut s'adapter à une limite que le trafic encapsulé ne voit jamais réellement.

Sondez le chemin au lieu de deviner un nombre

Gardez fixes la destination, le réseau d'accès et le tunnel, puis ne faites varier que la taille du paquet. Une sonde « ne pas fragmenter » qui échoue avec un indice de MTU vous donne la limite du saut suivant ; répétez jusqu'à ce qu'une taille passe, et notez à la fois la taille et la famille d'adresses.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

Un ping qui passe ne prouve pas que les segments de taille maximale d'une application réelle passent, alors répétez le test avec le transfert qui a réellement échoué. Comparez la plus grande sonde qui fonctionne au MTU du tunnel que vous avez configuré, et gardez les deux nombres séparés dans vos notes. S'ils diffèrent d'environ un en-tête, vous avez trouvé la surcharge d'encapsulation, pas un défaut.

PLPMTUD, décrit dans le RFC 4821, sonde vers le haut et utilise les acquittements du transport au lieu de se fier aux erreurs délivrées. Il aide sur les chemins qui filtrent ICMP, mais la prise en charge varie selon la pile et l'application. Un flux TCP peut se rétablir seul tandis qu'une application UDP à taille de datagramme fixe continue d'échouer.

Choisissez une valeur et consignez le raisonnement

Abaisser le MTU du tunnel est à la fois un diagnostic et un correctif légitime une fois que vous connaissez le chemin. Ce n'est pas un substitut au fait de savoir quel chemin et quel mécanisme de retour étaient en cause, car une valeur réglée pour une liaison mobile sera inutilement petite sur une connexion fibre. Consignez la taille choisie, la sonde qui l'a justifiée et l'étape de retour arrière.

Le mécanisme IPv4 est décrit dans le RFC 1191 et les recommandations d'empaquetage IPv6 dans le RFC 8201 ; nommer les deux évite au prochain ingénieur de redériver l'hypothèse. Si le transfert se bloque encore à la taille choisie, cessez d'abaisser le nombre et regardez la couche suivante. Un chemin qui échoue à toutes les tailles n'est pas un problème de MTU.