Pourquoi une incompatibilité de MTU provoque-t-elle une connectivité partielle du serveur domestique ?

Un décalage de MTU cause une connectivité partielle du serveur domestique lorsque les petits paquets peuvent traverser le chemin mais pas les paquets plus grands. Les réponses DNS, les poignées de main TCP, les pings et les appels API courts peuvent réussir, créant l'impression que la route est saine. La connexion se bloque ensuite lorsque TLS, une réponse web, un téléchargement ou un transfert de fichier produit un paquet IP plus grand que ce qu'un lien peut transporter.

Un chemin correct rapporte cette limite de taille afin que l'émetteur puisse réduire ses paquets. L'échec partiel apparaît lorsqu'un tunnel, un pont virtuel, un routeur ou un lien ISP a un MTU plus petit et que le retour d'information n'atteint jamais l'émetteur — ou lorsque différentes couches annoncent des tailles qui ne reflètent pas leur chemin encapsulé réel. Le résultat est une accessibilité sans livraison fiable des données.

La réponse courte : la taille du paquet fait partie de la connectivité

Le MTU est le plus grand paquet IP qu'une interface peut envoyer en une seule transmission de couche liaison. Les points de terminaison se soucient de la plus petite valeur utilisable sur l'ensemble du chemin, pas seulement du paramètre de 1500 octets affiché sur le port Ethernet d'un serveur domestique. Les en-têtes VPN et de superposition consomment de l'espace, donc un paquet qui tient sur le LAN peut être trop grand après encapsulation.

L'échec est partiel car les protocoles commencent par de petits paquets de contrôle. Une poignée de main TCP en trois étapes peut se compléter, et un navigateur peut se connecter, avant que l'une ou l'autre des parties n'envoie un segment de données de taille complète. Si les paquets surdimensionnés disparaissent tandis que les accusés de réception et les retransmissions plus petites passent encore, la session semble active mais progresse peu ou pas.

MTU, MSS et la découverte du MTU du chemin sont liés mais différents

Le MTU de l'interface limite le paquet IP sur une interface. La taille maximale du segment TCP, ou MSS, indique la quantité de charge utile TCP qu'un point de terminaison souhaite dans chaque segment ; elle laisse de la place pour les en-têtes IP et TCP. Le clampage MSS peut réduire cette charge utile annoncée sur un routeur, mais cela affecte les négociations TCP plutôt que chaque paquet UDP ou ICMP.

La découverte du MTU du chemin, ou PMTUD, permet à un émetteur de connaître le plus petit MTU le long d'un itinéraire. Pour IPv4, la RFC 1191 définit un processus dans lequel un routeur incapable de transmettre un paquet avec le bit Ne Pas Fragmenter activé renvoie un retour ICMP fragmentation-needed. L'émetteur peut alors réduire la valeur du chemin et retransmettre.

Les routeurs IPv6 ne fragmentent pas les paquets en transit. La RFC 8201 spécifie qu'un nœud IPv6 utilise des messages ICMPv6 Packet Too Big pour apprendre un MTU de chemin plus petit. Bloquer ce trafic de contrôle ne renforce pas le chemin des données ; cela empêche le point d'extrémité de s'adapter à une limite réelle.

Où un chemin de serveur domestique commence à perdre des paquets plus gros

Un tunnel réduit la charge utile utilisable

WireGuard, IPsec, PPPoE, VLANs et autres encapsulations ajoutent des en-têtes autour du paquet original. Un paquet interne de 1500 octets ne peut pas tenir inchangé dans un lien externe de 1500 octets une fois ces en-têtes présents. Une interface de tunnel annonce normalement un MTU plus bas, mais une substitution manuelle ou un appareil intermédiaire peut laisser les points d'extrémité avec une valeur optimiste.

Le décalage peut affecter l'accès distant alors que le service local reste parfait. Un téléphone en Wi-Fi atteint le serveur via Ethernet ordinaire, tandis que le même téléphone sur un VPN utilise le chemin de tunnel plus petit. Parce que le routage, l'authentification et les petites requêtes fonctionnent toujours, le symptôme peut ressembler à un problème d'application ou de certificat.

Les chemins imbriqués aggravent le problème. Un paquet conteneur peut traverser une paire Ethernet virtuelle et un pont, entrer dans un adaptateur VM, puis dans un VPN. Le MTU restrictif appartient à l'itinéraire complet, tandis que chaque interface visible peut rapporter une valeur plausible pour sa propre couche.

Le retour ICMP est filtré ou perdu

Si le routeur limitant abandonne un paquet surdimensionné et que son erreur atteint la source, le PMTUD peut se rétablir. Si un pare-feu rejette tous les ICMP ou ICMPv6 sans distinction, l'expéditeur continue d'utiliser une taille que le chemin ne peut supporter. Cloudflare décrit cette défaillance moderne comme un trou noir MTU du chemin : les gros paquets sont perdus silencieusement tandis que l'application attend.

Le routage asymétrique peut produire le même résultat même lorsqu'aucun pare-feu ne bloque délibérément le message. Le paquet de données peut emprunter un chemin tandis que l'erreur ICMP en prend un autre ; le routage par politique, le NAT ou un filtre fournisseur peuvent empêcher que le message de retour soit associé à l'expéditeur original. La capture de paquets doit donc inspecter à la fois les directions des données et des retours.

Les retransmissions TCP répétées sont un indice, pas une preuve. La congestion et la perte sans fil déclenchent aussi des retransmissions. Les problèmes de MTU deviennent plus probables lorsque les échecs commencent près d'une taille de charge utile répétable, que les petites sondes réussissent, et que réduire le MTU de l'interface ou le MSS annoncé restaure immédiatement la progression.

Les réseaux virtuels annoncent une taille incorrecte

Les ponts de conteneurs et les commutateurs VM peuvent hériter ou avoir par défaut un MTU plus grand que la couche sous-jacente. Le conteneur construit alors un paquet valide pour son interface virtuelle mais trop grand après que l'hôte l'a envoyé via un VPN, un overlay cloud ou un lien PPPoE. Les fonctions de déchargement peuvent faire paraître les captures plus grandes que les paquets réels, donc le lieu de capture est important.

Un cas Docker documenté a suivi exactement ce problème enfant : une petite requête LDAP a réussi, mais la réponse a disparu car le MTU du VPN était de 1400 alors que Docker utilisait 1500. Le réseau hôte semblait résoudre le problème car il supprimait la couche virtuelle non correspondante, pas parce que l'application avait changé.

Ne pas déduire le comportement du câble à partir d'une seule capture montrant de gros segments TCP. La segmentation générique déchargée peut présenter de gros tampons au système d'exploitation et les diviser ensuite. Capturez côté réception, désactivez temporairement les déchargements pour le diagnostic, ou corrélez les compteurs d'interface avec des tests de taille de paquet contrôlés avant de conclure qu'un appareil a transmis une trame impossible.

Les paramètres en amont et du tunnel déterminent la limite réelle

Le serveur domestique n'est pas toujours à l'origine de l'incompatibilité. PPPoE, un mécanisme de transition ISP, un tunnel d'accès distant ou un routeur en amont peuvent introduire le lien le plus étroit. Tracez la route exacte client-service et notez chaque frontière d'encapsulation au lieu de ne changer que la carte réseau physique.

Autorisez les messages de contrôle nécessaires au PMTUD. Pour IPv4, cela inclut le message pertinent de destination inaccessible nécessitant une fragmentation ; pour IPv6, cela inclut Packet Too Big. Appliquez une politique de pare-feu stricte par type de message et état au lieu de bloquer tout ICMP. Un serveur ne peut pas apprendre une contrainte de chemin que le réseau refuse de signaler.

Évitez de dépendre de la fragmentation comme solution normale. La RFC 8900 explique que la fragmentation IP introduit une fragilité opérationnelle. Aligner le MTU, préserver le PMTUD ou faire en sorte que le transport sonde en toute sécurité est plus robuste que de supposer que chaque middlebox transmettra et réassemblera les fragments.

Si un routeur ne peut pas être modifié, le clampage MSS peut être une solution TCP pratique au niveau du tunnel ou de la frontière de transfert. Réglez-le à partir du chemin réel plutôt que de copier un nombre universel. Cela ne réparera pas les datagrammes UDP surdimensionnés, et une valeur inutilement basse ajoute une surcharge de paquets et d'en-têtes, donc confirmez l'amélioration avec des captures et des tests d'application.

Les paramètres du serveur, de la VM et du conteneur doivent être cohérents

Inventoriez le MTU sur la carte réseau physique, le bond, le VLAN, le pont, l'adaptateur VM, le réseau du conteneur et le tunnel. Les valeurs n'ont pas besoin d'être numériquement identiques lorsqu'une couche prend correctement en compte l'encapsulation, mais aucune couche interne ne doit produire des paquets que la couche suivante ne peut pas transporter ou signale comme trop grands.

Pour Docker, définissez un MTU approprié lors de la création du réseau ou via la configuration du démon, puis recréez les réseaux et conteneurs affectés si nécessaire. L'exemple de dépannage de Civo montre comment un MTU Docker qui ignore la couche sous-jacente peut provoquer des problèmes de connectivité inattendus. Vérifiez ensuite l'interface active ; modifier la configuration seule ne prouve pas que le réseau en cours a changé.

Gardez l’optimisation des performances séparée de la réparation. L’explication de ZimaSpace sur la taille de la fenêtre TCP sur les liens longue distance concerne la quantité de données pouvant rester en transit, tandis que la MTU contrôle la taille des paquets. Augmenter les tampons ne peut pas faire passer un paquet surdimensionné à travers un lien plus petit.

Vérifications pour identifier l’étape défaillante

Trouvez le plus gros paquet qui passe systématiquement

Utilisez les options ping adaptées à la plateforme pour définir la taille de la charge utile et interdire la fragmentation lorsque c’est possible, en n’oubliant pas d’ajouter les octets des en-têtes IP et ICMP lors de la comparaison avec la MTU d’une interface. Testez plusieurs tailles depuis le même chemin client qui montre l’échec. Un seuil reproductible est plus informatif qu’un ping par défaut réussi.

Répétez le test sur le LAN, via le VPN, et depuis l’intérieur du conteneur ou de la machine virtuelle. Si le seuil change à une frontière, cette couche devient le principal suspect. Certains réseaux limitent ou bloquent le trafic d’écho, donc confirmez le résultat avec des requêtes d’application TCP ou un outil dédié au path-MTU.

Inspectez les interfaces, les routes et l’encapsulation

Enregistrez la route sélectionnée et l’interface de sortie pour la destination affectée. Inspectez les valeurs MTU sur chaque interface virtuelle et physique traversée par le paquet, ainsi que la configuration réseau du tunnel et du conteneur. Ne supposez pas que la route par défaut est utilisée lorsque le routage par politique ou le tunneling fractionné est actif.

Calculez la surcharge d’en-tête pour la pile de tunnel réelle, y compris la version IP externe et le transport. La MTU interne sûre doit laisser de la place pour ces en-têtes sur le chemin externe. Si le tunnel utilise une route changeante, choisissez une valeur qui fonctionne sur ses sous-couches prises en charge ou conservez un mécanisme de découverte fonctionnel.

Capturez les données et les retours ICMP des deux côtés

Capturez près de l’émetteur et après le lien étroit suspecté. Recherchez un gros paquet répété sans accusé de réception, un message ICMP fragmentation-needed, ou un message ICMPv6 Packet Too Big. Si l’erreur apparaît en aval mais n’atteint jamais l’émetteur, concentrez-vous sur le routage de retour et la politique de pare-feu.

Pour TCP, inspectez les options MSS dans les paquets SYN et SYN-ACK et comparez-les avec les segments de données observés. Une MSS plus basse peut empêcher l’émetteur de créer des paquets TCP surdimensionnés, mais cela ne révèle pas si l’UDP reste défaillant. Utilisez la capture pour valider la réparation plutôt que de considérer une règle de pare-feu chargée comme un succès.

Ajustez la MTU ou limitez la MSS, puis retestez

Privilégiez la correction du MTU à l'interface qui connaît le sous-jacent le plus petit. Recréez les réseaux virtuels lorsque leur MTU est fixé à la création. Si cela est impossible, bridez le MSS TCP à la limite de transfert ou de tunnel et autorisez le retour ICMP nécessaire. Effectuez un changement à la fois pour que le résultat reste attribuable.

Retestez le flux de travail original, pas seulement le ping. Complétez la négociation TLS, chargez une réponse plus grande qu'un paquet, téléchargez et envoyez un fichier, et maintenez la connexion active assez longtemps pour observer les retransmissions. La connectivité partielle est résolue uniquement lorsque les applications qui l'ont révélée transfèrent les données de manière fiable dans les deux sens.

Quand la connectivité partielle devient un problème sérieux

Considérez le problème comme urgent lorsqu'il affecte les sauvegardes, restaurations, administration à distance, synchronisation ou authentification. Ces flux peuvent passer des vérifications préliminaires et échouer seulement après le début du transfert de données significatives, laissant des copies incomplètes ou des délais d'attente que les opérateurs interprètent à tort comme des défauts de stockage ou d'identifiants.

Priorisez-le également lorsque le comportement IPv6 diffère d'IPv4, qu'un chemin VPN uniquement échoue ou que le trafic des conteneurs diffère de celui de l'hôte. Ces contrastes révèlent quelle route ou encapsulation modifie la taille de paquet utilisable. Plus la limite est déterministe, moins il est utile de continuer à relancer l'application sans réparer le chemin réseau.

FAQ

Pourquoi puis-je pinguer le serveur domestique alors que son site web ne se charge pas ?

Les paquets ping par défaut sont petits, tout comme les échanges DNS et les négociations TCP. Le site web peut se bloquer uniquement lorsque TLS ou HTTP envoie un paquet au-dessus de la limite du chemin. Testez des sondes plus grandes sans fragmentation et capturez la connexion web échouée au lieu de considérer une seule réponse ping comme preuve que toutes les tailles de paquets fonctionnent.

Chaque interface doit-elle utiliser un MTU de 1500 ?

Non. Ethernet utilise souvent 1500, mais les tunnels et autres encapsulations nécessitent de la place pour les en-têtes externes. Ce qui importe, c'est que chaque couche annonce une taille que la couche suivante peut transporter ou reçoive un retour fonctionnel qui lui permet de s'adapter au plus petit MTU sur le chemin.

Le bridage MSS est-il la même chose que la correction du MTU ?

Non. Le bridage MSS modifie la taille de la charge utile TCP annoncée lors de l'établissement de la connexion, ce qui peut maintenir les paquets TCP en dessous d'une limite connue. Il ne modifie pas le MTU de l'interface et ne contraint pas directement le trafic UDP ou autre trafic IP.

L'alignement MTU et le PMTUD fonctionnel concernent le chemin lui-même. Le bridage est utile lorsqu'un dispositif de transfert ou un tunnel ne peut pas autrement communiquer la contrainte, mais il doit être mesuré, placé à la bonne limite et suivi de tests pour chaque protocole affecté.