Mythes sur le MTU des VPN : pourquoi vos paquets rétrécissent et où passe la place

Quelqu'un vous dit que le VPN « perd des paquets à cause du MTU », vous réglez le tunnel sur 1400, et le transfert refonctionne. Ce résultat ressemble à un diagnostic. C'est généralement une coïncidence arithmétique : vous avez choisi un nombre assez petit pour passer sous une limite que vous n'avez jamais identifiée, et vous retrouverez la même limite sur le prochain réseau avec un budget différent.

Deux mythes causent l'essentiel de cela. Le premier veut que le MTU de l'interface du tunnel soit le MTU du chemin. Le second veut que l'encapsulation coûte « un en-tête » et que le PPPoE ne coûte rien qui vaille la peine d'être compté. Les deux sont faux d'une manière qui fait paraître arbitraire le nombre que vous choisissez alors qu'il est en fait déterminé.

Mythe un : le MTU du tunnel est le MTU du chemin

La valeur que vous réglez sur une interface de tunnel est une promesse locale sur le plus grand paquet interne que l'implémentation transmettra vers le bas. La capacité réelle du chemin est une propriété de chaque lien entre vous et l'extrémité distante, et elle peut changer quand une route change, quand une connexion mobile est transférée ou quand le trafic prend un autre peering. Un 1500 configuré vous dit ce que votre hôte va construire, pas ce que le réseau va transporter.

La découverte du MTU du chemin existe pour réconcilier les deux, et elle dépend d'un retour d'information. En IPv4, un routeur qui ne peut pas transmettre un paquet de taille pleine est censé envoyer un message ICMP « fragmentation needed », et l'émetteur abaisse son estimation. En IPv6, l'équivalent est un message Packet Too Big, et les routeurs ne fragmentent pas du tout en transit. Quand ce retour est filtré, l'émetteur continue de produire des paquets que le chemin ne peut pas porter, et rien ne lui dit pourquoi.

Mythe deux : l'encapsulation coûte un en-tête

Comptez les couches externes honnêtement. Un en-tête IP externe fait 20 octets en IPv4 ou 40 en IPv6. L'encapsulation UDP pour traverser le NAT ajoute 8. Le protocole du tunnel ajoute son propre en-tête, un vecteur d'initialisation ou un nonce, un remplissage jusqu'à la frontière de bloc ou d'alignement du chiffrement, une queue et une valeur de contrôle d'intégrité. Selon le protocole et le chiffrement, le total se situe confortablement dans les dizaines d'octets avant même que le paquet interne ne commence.

Soustrayez ensuite à nouveau les en-têtes du paquet interne lui-même. Un segment TCP dans le tunnel porte son propre en-tête IP de 20 octets et son en-tête TCP de 20 octets, et le MSS de TCP est dérivé du MTU, pas de la charge utile nominale du tunnel. C'est pourquoi ping avec une charge plus petite peut réussir tandis qu'un transfert de fichier se bloque : les outils testent des choses différentes, et un seul d'entre eux exerce un segment TCP de taille pleine.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

La première commande indique le MTU configuré du tunnel. Les deux sondes envoient une charge de 1472 octets, qui avec 28 octets d'en-têtes IPv4 et ICMP est un paquet de 1500 octets, puis une plus petite. Si la grande sonde échoue complètement et que la petite réussit, vous avez une panne liée à la taille et non un problème général de routage.

Mythe trois : le PPPoE vous donne encore 1500 propres

Une liaison d'accès PPPoE classique ne transporte pas un paquet IP de 1500 octets. L'en-tête PPPoE plus le champ de protocole PPP consomment 8 octets dans la trame Ethernet, ce qui laisse 1492 pour le paquet IP. C'est la limite traditionnelle décrite dans la RFC 2516. Si vous faites tourner un VPN sur une telle liaison, la surcharge du tunnel sort de ces 1492, pas de 1500.

La RFC 4638 définit un moyen de négocier une charge PPP plus grande lorsque le concentrateur d'accès et l'équipement du client le prennent en charge, ce qui explique que « cette connexion utilise PPPoE » ne prouve pas à lui seul un nombre précis. Un réglage local ne peut pas obliger un équipement intermédiaire à accepter un paquet pour lequel il n'a jamais été configuré, donc la question utile est ce que la liaison a réellement négocié, pas ce que dit l'étiquette.

Pourquoi la panne semble sélective

Que les petites requêtes réussissent et que les gros transferts se bloquent est la signature classique d'un trou noir de MTU de chemin. La poignée de main, la requête DNS et l'appel API tiennent tous ; le transfert massif produit des segments de taille pleine qui meurent sur un lien, et le message ICMP qui aurait dû signaler le problème n'arrive jamais. La connexion semble bonne et le téléchargement se bloque, ce qui pousse les gens à regarder le serveur au lieu du chemin.

Une seconde erreur, liée, consiste à confondre trois nombres : le MTU de l'interface, le MSS de TCP et le réglage de fragmentation ou de remplissage du protocole lui-même. Le pincement du MSS sur un routeur réécrit le MSS annoncé pour que l'émetteur construise des segments plus petits ; il ne change pas le MTU du tunnel et n'aide pas le trafic UDP. Donner le même nombre aux trois parce qu'ils semblent liés est la façon dont un changement bien intentionné casse une configuration qui fonctionne.

Quoi changer, et dans quel ordre

Commencez par des preuves. Confirmez avec les sondes ci-dessus que la panne dépend de la taille, puis trouvez la plus petite taille qui passe et la plus grande qui échoue. Vérifiez le MTU réel de la liaison d'accès avant d'accuser le tunnel ; une liaison PPPoE plafonne le budget avant même que votre VPN ne la touche. Notez les valeurs d'origine pour que le changement puisse être annulé.

Appliquez ensuite le plus petit ajustement que le client documente. Beaucoup de clients exposent un MTU de tunnel plus une option de correction du MSS, et l'option MSS est souvent le meilleur levier pour TCP car elle atteint l'émetteur sans réduire chaque paquet. Retestez la même destination et le même transfert, et notez les nombres sur lesquels vous vous êtes arrêté. Une valeur de tunnel qui fonctionne sur un réseau d'accès n'est pas une constante universelle, et le site suivant aura son propre budget.