MTU par route sous Linux : trois réglages de taille, une route
La MTU d'interface, la MTU de route et le plafond MSS agissent à des couches différentes. Attachez un budget à la route qui gagne la recherche, et gardez le changement réversible.
Trois réglages sur un client Linux se lisent tous comme « rendez les paquets plus petits », et ils agissent à des couches différentes. La MTU de l'interface plafonne chaque paquet que l'appareil envoie. La MTU d'une route plafonne les paquets qui empruntent cette route, ce qui est souvent ce que vous voulez vraiment pour une destination VPN. Le plafond TCP MSS change ce que négocient les deux extrémités, et il ne fait rien pour UDP.
Trois réglages qui ressemblent au même bouton
Mettez-les côte à côte avant de choisir, car choisir la mauvaise ligne explique la plupart des conseils qui ne fonctionnent pas :
| Control | Scope | What it cannot fix |
|---|---|---|
| Interface MTU | Every packet the device sends | Nothing, but it over-constrains unrelated traffic |
| Route MTU | Packets using that route | A send that the lookup never routes there |
| MSS clamp | TCP handshake on that path | UDP payload sizes and ICMP |
Baisser la MTU Ethernet pour toute la machine est la version brutale de ce correctif. Il fonctionne, et il pénalise aussi toute autre application de l'hôte, y compris celles dont les chemins étaient corrects. Une valeur par route exprime la même intention sans le coût collatéral.
La comparaison ne vaut que pour le trafic que l'hôte produit. Transférer un paquet pour un autre client implique son propre chemin et le budget extérieur du tunnel, et une métrique de route sur cet hôte ne franchit pas cette frontière.
Attachez le budget à la route qui gagne la recherche
Un enregistrement de route IPv4 illustratif ressemble à ceci :
ip -4 route get 10.60.0.20
ip -4 route add 10.60.0.0/16 dev tun-office src 10.90.0.2 mtu 1380Lisez l'enregistrement comme une description d'intention, pas comme une valeur à coller. Le préfixe, l'appareil et la source préférée doivent correspondre à la configuration réelle, et le nombre doit venir de preuves sur le chemin encapsulé, pas d'un billet de blog. La MTU de route plafonne le paquet IP interne, ce qui n'est pas la même chose qu'une charge TCP de 1380 octets ou qu'un paquet extérieur chiffré de 1380 octets.
Regardez où la recherche se résout réellement avant d'ajouter quoi que ce soit. Un hôte doté de règles de politique peut router une destination donnée par une table autre que main, et une métrique qui n'existe que dans main est invisible pour cette requête. Comparez ip -4 route show table all avec la réponse de ip route get, y compris le contexte de marque ou d'espace de noms quand les règles les utilisent. Si les deux ne concordent pas, la table qui a répondu est celle qui a besoin de la métrique, pas celle qui paraît la plus propre.
mtu n'est pas mtu lock
Par défaut le noyau peut encore mettre à jour la MTU du chemin à partir des retours ICMP, ce à quoi sert la découverte de MTU de chemin. Ajouter lock arrête cela. C'est une décision différente, pas une façon plus forte de conserver le même nombre, et pour IPv4 cela change le traitement documenté du bit « ne pas fragmenter ».
Verrouiller est raisonnable quand vous avez mesuré le chemin et voulez que la valeur reste en place quoi qu'il arrive. C'est un mauvais réglage par défaut quand le réseau envoie des retours de taille légitimes, car le noyau ne peut plus s'ajuster et la panne se déplace vers un autre symptôme.
Si ICMP est filtré quelque part sur le chemin, aucun réglage de route ne répare cela. Le correctif relève du filtre, et une MTU plus petite est un contournement qui cache la vraie panne jusqu'au prochain changement de chemin.
Les logiciels de tunnel ajoutent leurs propres réglages de taille
OpenVPN mssfix ajuste la taille des segments TCP pour son cas documenté de tunnel UDP. Il agit sur la conversation TCP, ce n'est donc pas une autre écriture de la MTU de route du système d'exploitation, et il ne peut pas aider un service UDP qui ignore la négociation.
N'empilez pas une MTU de route, un changement de MTU d'interface et un plafond MSS dans la même fenêtre de changement. Si le problème disparaît, vous ne saurez pas lequel comptait, et ceux que vous gardez brideront le trafic pendant des années sans raison dont quelqu'un se souvienne.
Rendez-le réversible, puis prouvez-le
Le véritable propriétaire de la route décide si le changement survit à une reconnexion. Un client VPN qui installe la route dynamiquement la reconstruira généralement sans votre métrique, et une ip route add manuelle passe alors pour un correctif qui a échoué un jour plus tard. Mettez la valeur dans la configuration du gestionnaire, et si vous avez besoin d'une expérience temporaire, notez d'abord la route d'origine.
Testez avec une nouvelle connexion qui effectue l'opération qui bloquait, puis confirmez que la route privée visée gagne toujours et que les destinations sans rapport n'ont pas changé. Reconnectez le tunnel et relisez la route, car une valeur qui disparaît à la reconnexion n'est pas un correctif.
Si les preuves ne soutiennent pas le changement, retirez la substitution via son gestionnaire et restaurez les attributs d'origine de la route plutôt que de supprimer la route. Notez ensuite ce que vous avez mesuré et sur quel chemin, pour que la personne suivante distingue une vraie amélioration d'une expérience laissée en marche.