Quel est exactement le problème MTU / MRU, de quelle manière est-il causé et comment le résoudre?

Dans les cas de connexions Internet suspendues, gelées, lentes et qui ne répondent pas, la cause est généralement déraisonnablement identifiée comme un "problème MTU / MRU" avec plusieurs "remèdes magiques" proposés à la hâte (généralement invalides ou inapplicables pour la situation) comme des commandes impliquant iptablesou ifconfiget d'autres " pince MTU aux sorts TSS ".

Ce que je veux savoir, c'est quel est exactement le problème MTU / MRU, pourquoi il affecte la vitesse de connexion et la latence, et comment il est guéri (méthodes connues et modernes), car j'aimerais aborder en connaissance de cause la résolution du problème, pas par magie.

C'est une question un peu compliquée, je vais donc commencer par les bases. Pardonnez-moi si vous savez déjà tout cela.

MTU est l'unité de transmission maximale, le plus grand paquet de données qu'une interface informatique enverra. Pour Ethernet, la valeur par défaut est de 1500 octets. Les trames Ethernet sont généralement autorisées jusqu'à 1522-1542 (selon ce que vous comptez) et l'espace supplémentaire est «réservé» pour les informations d'en-tête.

Diverses connexions peuvent avoir des capacités différentes. Il est assez courant de parcourir un lien sur Internet dont la MTU est légèrement inférieure à 1 500. Cela est généralement dû au lien utilisant des informations d'en-tête supplémentaires ou utilisant un support autre que Ethernet «standard» (la plupart d'Internet fonctionne réellement sur Connexions ATM / SoNet). Normalement, le trafic qui rencontre un tel lien est simplement divisé en plusieurs morceaux et envoyé.

Parce que cela est courant et était au moment où IP a été inventé, une partie de la responsabilité du protocole ICMP était de communiquer tout problème avec les MTU. Si un paquet, pour une raison quelconque, n'a pas pu être rompu et transmis, ICMP est utilisé pour communiquer le problème à l'ordinateur d'envoi. L'ordinateur d'envoi prend les mesures appropriées, divise les informations en petits morceaux et tout le monde est content. L'ensemble de ce processus est géré dans les coulisses. Dans un réseau fonctionnant correctement, il n'est jamais nécessaire de faire le ménage avec les paramètres MTU .

Le qualificatif de cette dernière phrase est le botteur. Il y a trois raisons courantes pour lesquelles le processus automatisé tombe en panne:

1. Implémentation cassée - Le logiciel à un moment donné ne fonctionne tout simplement pas comme il se doit. Il n'y a pas de lois obligeant les gens à suivre la norme Internet pertinente et il y a des entreprises qui enfreignent les normes, généralement pour être bon marché.
2. Implémentation désactivée administrativement - Il arrive que des personnes ayant de bonnes intentions cassent un logiciel parce qu'elles ne savent pas vraiment ce qu'elles font. J'ai personnellement vu des gens bloquer ICMP parce qu'ils pensent qu'il n'est utilisé que pour les paquets ICMP.0.0 (écho, la plupart des gens le savent par l' pingutilitaire).
3. D'autres raisons complètement en dehors de ce processus «normal». Généralement, cela signifie que la connexion est si perdante que seuls des paquets plus courts parviennent à traverser la connexion de manière fiable (ou sans un nombre massif de nouvelles tentatives). Certains premiers DSL et CableModems avaient des problèmes comme celui-ci. Et avant cela, l'accès à distance avait généralement des problèmes comme celui-ci lors de l'utilisation de lignes téléphoniques de très mauvaise qualité et de codages de ligne agressifs.

Alors, pourquoi est-ce courant: techniciens / entreprises paresseux. Il est presque universellement «plus facile» de handicaper la connexion avec un minuscule MTU que de résoudre l'un des problèmes décrits ci-dessus. Comme indiqué ci-dessus, personne ne devrait avoir à jouer avec MTU ces jours-ci (la seule exception à laquelle je peux penser d'activer les trames Jumbo, mais ce n'est vraiment pas ce dont nous discutons ici). Le remède correct dans tous les cas est de comprendre le problème sous-jacent et de le résoudre; cas classique de traiter la maladie et non le symptôme.

Comment MTU affecte-t-il une connexion? Couper les données en petits morceaux signifie que chaque pièce aura de meilleures chances d'arriver à destination, en particulier via des connexions très peu fiables. Étant des morceaux plus petits cependant, il y a plus de frais généraux par les données transmises. Cela signifie que la vitesse de connexion effective est réduite; sensiblement si le MTU est vraiment petit. La latence peut être affectée, bien que je m'attende à ce qu'elle soit mineure, en raison du traitement supplémentaire et de la surcharge de l'en-tête et du processus de fragmentation / réassemblage.

Mise à jour: - En ce qui concerne --clamp-mss-to-pmtu
personnellement, je n'ai jamais mucked avec MTU; J'avoue que je suis un peu perfectionniste et quand on me présente de vilains hacks comme celui-ci, je trouve toujours la racine du problème et j'ai pu le corriger. À cette fin, cette iptablesoption --clamp-mss-to-pmtune m'est pas familière. Apparemment, il est extrêmement courant et probablement très injustifié dans la plupart des situations d'utiliser ce hack. C'est toujours un hack pour compenser l'un des problèmes ci-dessus. Je cite la page de manuel Linux pour iptables (8):

Cette cible est utilisée pour vaincre les FAI ou serveurs criminellement malveillants qui bloquent les paquets «ICMP Fragmentation Needed» ou «ICMPv6 Packet Too Big».

Le langage relativement dur de la page de manuel devrait être une indication du mépris suscité par les FAI et les réseaux qui ne suivent pas les RFC (et ne font aucun effort pour essayer ou compenser).

S'agissant de l'utilisation de l'UDP dans les VPN, cela était le plus courant pour minimiser la surcharge du VPN et permettre aux points de terminaison existants de gérer les informations de session. Il n'y a aucun moyen pour le VPN de savoir comment la session doit être gérée, il est donc préférable de laisser cette tâche aux applications qui le savent.

De nombreux protocoles de tunneling VPN modernes sont construits à des niveaux inférieurs (avec encore moins de surcharge), tels que GRE et L2TP; ou tunnelé à des niveaux supérieurs (généralement pour des raisons de compatibilité avec des pare-feu restrictifs ou pour d'autres raisons), tels que SSTP ou SSH. Ceux-ci remplaceront progressivement l'UDP comme mécanisme de transport.

Mise à jour 2: - Diagnostic des problèmes MTU / ICMP
Vous pensez donc que vous avez un problème MTU / ICMP et vous voulez en être sûr. Ce processus comporte deux étapes de base. Les instructions sont pour une boîte Linux ou BSD, mais peuvent être adaptées à n'importe quel système d'exploitation.

1. Choisissez une cible Ping ICMP (par exemple, Google.com, Yahoo.com, Facebook.com, etc.). Essayez - les avec pinger la commande suivante: ping -c 2 -s 1472 -D google.com.
   • Cela devrait réussir. S'il ne réussit pas, il doit retourner "le paquet doit être fragmenté". Si l'un ou l'autre est vrai, arrêtez, votre connexion fonctionne très bien.
   • Si cela ne retourne rien ou donne un message "timeout", vous avez un problème.
2. Pour les connexions rompues uniquement: exécutez traceroute -F google.com 1472. Cela vous dira quel saut est cassé. Remarque: il est assez courant que CPE ne réponde pas aux demandes de traceroute, donc ne vous inquiétez pas si le premier saut ne répond pas.
   • Quel que soit le dernier saut à répondre, c'est le dernier qui fonctionne correctement pour vous.
   • Si aucun d'eux ne répond, c'est votre ligne CPE ou DSL (trouver ce qui peut être un peu délicat, mais ce n'est presque jamais CPE s'il est moderne). Remarque: Si votre connexion fonctionne correctement, traceroute se terminera avec succès.

Sur une note latérale: Quel FAI utilise PPTP ces jours-ci?! C'est une explosion du passé archaïque et inutile. Ils devraient au moins utiliser PPPoE; mais simplement autoriser le modem par MAC et Segment serait tellement plus facile (plus facile à la fois pour le FAI et le client).