Un MTU VPN plus faible est-il plus rapide ? Comparez les preuves réelles
Un MTU plus bas peut contourner une limite de chemin et coûter du débit quand même. Comparez la contrainte réelle, le coût des en-têtes et la charge avant de garder le changement.
Un tunnel abandonne les gros transferts mais laisse passer les ping, alors le conseil arrive vite : baissez le MTU. Le correctif marche parfois, puis il est appliqué à chaque profil sur chaque réseau. C’est le moment où une réparation ciblée devient une taxe permanente sur les performances. La comparaison à faire est entre la limite réelle du chemin et le coût de réduire chaque paquet en dessous d’elle.
Ce qui rétrécit réellement quand vous baissez le MTU
Chaque paquet porte des en-têtes avant de porter vos données. Sur un chemin Ethernet de 1500 octets, IPv4 et TCP consomment 40 octets et laissent 1460 pour la charge utile ; l’encapsulation ajoute par-dessus des en-têtes externes IP, UDP et tunnel, donc le budget interne de charge utile baisse encore. Baisser le MTU de l’interface réduit ce budget délibérément.
Le coût est proportionnel au nombre de paquets, pas au nombre d’octets. Le même fichier réparti sur plus de paquets demande plus d’interruptions, plus de décisions de routage et plus de traitement par paquet sur chaque équipement du chemin. Sur un routeur déjà proche de sa limite de paquets par seconde, c’est un vrai ralentissement et non une erreur d’arrondi. Le coût apparaît même quand le transfert réussit.
C’est pourquoi un MTU plus faible est un contournement d’une contrainte, pas une optimisation générale. Il achète de la fiabilité face à un chemin qui ne peut pas porter la trame plus grande et il facture une surcharge pour chaque paquet qui n’avait pas besoin de la réduction.
Quand un MTU plus faible est le bon correctif
Le symptôme classique est précis : la poignée de main TCP aboutit, de petites réponses arrivent, et un gros téléchargement se bloque ou se réinitialise. Un ping avec le bit ne-pas-fragmenter à 1472 octets échoue alors qu’un ping de 1400 octets réussit, ce qui désigne un chemin qui ne peut pas porter un paquet de taille pleine et ne délivre pas le message ICMP qui dirait à l’émetteur de réduire.
La découverte du MTU du chemin dépend de ces messages ICMP de fragmentation nécessaire. Quand un pare-feu les jette, l’émetteur réessaie sans cesse le gros paquet et la connexion semble se figer. Baisser le MTU côté tunnel évite la reprise, et c’est une réparation légitime pour ce réseau.
Les technologies d’accès imposent aussi leurs propres limites : PPPoE plafonne souvent à 1492, certains chemins mobiles et DSL sont plus bas, et les tunnels imbriqués retranchent la surcharge deux fois. Mesurez le chemin réel au lieu de copier un nombre d’un guide, et rappelez-vous qu’IPv6 exige au moins 1280 octets de MTU sur tout lien qui le transporte, comme le précise RFC 8200.
Comparez les trois contrôles avant d’en changer un
MTU, MSS et fragmentation sont des leviers différents à des couches différentes, et changer le mauvais laisse le symptôme en place.
| Control | Layer | What it changes | Where it misleads |
|---|---|---|---|
| Interface MTU | IP link | Largest frame the interface will send | Penalizes every protocol, not just the one that failed |
| TCP MSS clamp | TCP | Segment size advertised in the handshake | Leaves UDP and QUIC untouched |
| DF and fragmentation | IP | Whether a router may split a packet | Can break path MTU discovery and security assumptions |
| Tunnel overhead | Encapsulation | Inner MTU after outer headers | Mismatch shows up only for large inner packets |
Limiter le MSS est souvent la réparation la moins invasive, car elle n’affecte que TCP et laisse l’interface libre pour un autre trafic. Un MTU d’interface plus bas est plus large et plus simple à raisonner, c’est pourquoi il est courant sur les routeurs grand public, mais il facture à chaque protocole le problème d’un seul protocole.
Désactiver le comportement ne-pas-fragmenter masque le symptôme en autorisant la fragmentation, et cela aggrave généralement la latence tout en cassant la rétroaction qui aurait trouvé la bonne taille. Évitez-le comme correctif permanent.
Mesurez le compromis plutôt qu’un seul nombre
Trouvez la limite du chemin avec une sonde ne-pas-fragmenter, en commençant haut et en descendant jusqu’à ce que la réponse arrive :
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10Comparez ensuite la tâche réelle avec les deux réglages : le même transfert de fichier, le même point de terminaison et le même réseau. Notez le temps d’achèvement et les retransmissions, par exemple avec nstat -az TcpRetransSegs, et surveillez le processeur de l’appareil si le tunnel se termine sur un petit routeur. Un court test de débit synthétique peut manquer le blocage qui n’apparaît qu’après plusieurs mégaoctets.
Les compteurs de paquets augmenteront après une réduction parce que le même transfert utilise désormais plus de paquets. C’est attendu et ce n’est pas une preuve d’un débit plus élevé. Comparez les données applicatives terminées, le nombre de retransmissions et la réactivité, pas seulement le débit de paquets.
Déployez le changement par étapes et gardez-le encadré
Notez la valeur d’origine, changez un contrôle et répétez la mesure avant de la rendre permanente. Si les preuves ne montrent pas de bénéfice, restaurez la valeur précédente avec la même commande d’interface que celle utilisée pour la fixer :
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500Limitez le résultat au réseau qui en avait besoin. Un profil qui doit fonctionner sur un Wi-Fi d’hôtel, un point d’accès mobile et un LAN de bureau ne devrait pas hériter de la valeur la plus basse qu’exige l’un d’eux, sauf si le client ne peut pas détecter le chemin.
La bonne valeur est le plus grand MTU qui survit au chemin, pas le plus petit qui fait disparaître le symptôme. Documentez le chemin, le résultat de la sonde et le retour arrière, et révisez le réglage quand le réseau d’accès change.