Les trames jumbo ne font pas transporter des paquets de 9000 octets par un chemin VPN

Vous avez activé des trames de 9000 octets sur le LAN et vous attendiez à ce que le VPN accélère. Il a ralenti, ou a cessé de faire passer les gros transferts. Les trames jumbo sont un accord de liaison local ; elles n'élargissent pas le chemin que traverse le tunnel.

Le budget utilisable est fixé par la plus petite limite du chemin, y compris l'encapsulation ajoutée par le tunnel.

Ce que les trames jumbo changent vraiment

Une MTU est une propriété d'une interface. L'élever sur un serveur et son commutateur signifie que ces deux-là peuvent échanger des trames plus grandes sans fragmentation. Cela ne dit rien du routeur au-delà du commutateur, du fournisseur d'accès ni de l'autre côté d'un tunnel. Ces appareils ont leurs propres limites, et un paquet qui dépasse l'une d'elles est jeté ou fragmenté selon des règles que vous n'avez pas fixées.

Accord local, conséquences globales. Voilà toute la confusion.

La taxe d'encapsulation

Un tunnel enveloppe votre paquet dans un autre. WireGuard sur IPv4 UDP ajoute environ 60 octets de surcharge ; le mode UDP d'OpenVPN est dans la même plage, et IPsec varie selon le mode et les algorithmes. Ces octets sortent du budget du chemin extérieur, pas de nulle part.

Ainsi, un lien extérieur de 1500 octets ne peut pas transporter un paquet intérieur de 1500 octets une fois l'en-tête de tunnel ajouté.

Le calcul vaut la peine d'être fait une fois. Sur un chemin de 1500 octets, une interface WireGuard veut une MTU d'environ 1420 pour que le paquet encapsulé tienne. Réglez l'interface intérieure sur 9000 et chaque gros paquet aura besoin d'une fragmentation que le tunnel ne peut pas faire, ou sera jeté.

Trouvez le plus petit lien du chemin

Parcourez la route et trouvez la MTU la plus basse. Le LAN est généralement 1500 ou 9000, le WAN généralement 1500, et un lien mobile ou PPP peut être plus bas encore. Soustrayez ensuite la surcharge du tunnel. Si le résultat est inférieur à la MTU de l'interface intérieure, vous avez votre réponse. La découverte de MTU du chemin peut le trouver automatiquement, mais seulement si les messages ICMP dont elle dépend sont autorisés à passer.

L'ICMP filtré est la raison classique pour laquelle un gros transfert se bloque alors que les petites requêtes fonctionnent bien.

Testez la dépendance à la taille sans élargir le changement

Utilisez un transfert représentatif et conservez les valeurs d'origine pour pouvoir les remettre. ping -M do -s 1472 teste un paquet de 1500 octets avec le bit DF activé ; réduisez la taille jusqu'à ce qu'il passe. Si seuls les gros paquets échouent, vous avez un problème de taille et non de routage.

Méfiez-vous de l'offload côté hôte quand vous lisez des captures. L'offload de segmentation peut montrer des trames bien plus grandes que ce qui a réellement traversé le câble, ce qui fait paraître cassé un chemin qui fonctionne et correct un chemin cassé.

Quand une grande MTU est le bon choix

Un réseau privé maîtrisé peut légitimement faire tourner des trames plus grandes de bout en bout, à condition que chaque appareil du chemin soit d'accord et que la surcharge du tunnel soit prise en compte. C'est une conception coordonnée avec une valeur documentée par lien, pas un gros nombre tapé dans un client.

Pour une sortie publique ordinaire, supposez 1500 ou moins et laissez le tunnel choisir une MTU intérieure sûre. RFC 8201 couvre la découverte de MTU du chemin pour le cas IPv6 et constitue une référence utile sur la façon dont le retour d'information est censé fonctionner.