MTU 1420 : pourquoi certains sites peuvent bloquer et comment corriger

La MTU est la taille maximale d'un paquet pouvant être envoyé sur un réseau sans fragmentation. La valeur habituelle sur Ethernet est de 1500 octets. Lorsque le trafic passe par un tunnel, ses propres en-têtes occupent une partie de l'espace, laissant moins de charge utile : une valeur typique est 1420.

En soi, ce n'est pas un problème. Les problèmes commencent lorsqu'un côté croit pouvoir envoyer 1500, mais qu'un segment à 1420 se trouve sur le chemin et que le message l'informant se perd.

À quoi ressemble le symptôme

• SSH se connecte, le message d'accueil arrive, mais ls dans un grand répertoire bloque la session.
• Une page commence à charger et se fige à mi-parcours.
• curl -I (en-têtes uniquement) fonctionne, mais un curl complet se bloque.
• apt update réussit, apt upgrade se bloque pendant le téléchargement.
• Les petites requêtes passent, les grandes réponses n'arrivent jamais.

Le signe commun est toujours le même : les petits paquets passent, les gros disparaissent sans erreur. La connexion ne tombe pas ; elle devient simplement silencieuse.

La raison est que le mécanisme de négociation de la taille des paquets repose sur les messages de service ICMP. Si quelque chose les filtre sur le chemin, l'émetteur n'apprend jamais que le paquet est trop grand et le renvoie encore et encore.

Vérification

Envoyez un paquet avec le bit don't-fragment activé et réduisez la taille jusqu'à ce qu'il passe :

ping -M do -s 1472 -c 2 1.1.1.1
ping -M do -s 1392 -c 2 1.1.1.1

La taille -s se voit ajouter 28 octets d'en-têtes : 1472 correspond à une MTU de 1500, et 1392 à une MTU de 1420. Si la première option échoue et que la seconde réussit, vous avez trouvé la limite.

La valeur actuelle de l'interface :

ip link show
ip route get 1.1.1.1

Comment corriger

Vérification ponctuelle :

ip link set dev eth0 mtu 1420

De façon permanente, via systemd-networkd — fichier /etc/systemd/network/10-eth0.network :

[Match]
Name=eth0

[Link]
MTUBytes=1420

systemctl restart systemd-networkd

Si NetworkManager gère le réseau :

nmcli connection modify "System eth0" 802-3-ethernet.mtu 1420
nmcli connection up "System eth0"

Une seconde technique, utile lorsque vous ne pouvez pas toucher à la MTU, consiste à limiter la taille du segment TCP à la frontière. Dans nftables :

tcp flags syn tcp option maxseg size set rt mtu

Quand cela vous concerne

Sur une machine Millida VDS elle-même, le réseau est correctement configuré, et vous n'avez généralement pas besoin de toucher à la MTU manuellement. Vous devez vous en occuper lorsque vous montez vous-même un tunnel : WireGuard, OpenVPN, GRE, un VPN vers le bureau ou une liaison entre machines. À l'intérieur d'un tunnel, la MTU est toujours plus petite, et vous devez la définir explicitement.

Pour WireGuard dans la section [Interface] :

MTU = 1420

Erreurs courantes

Ne touchez pas à la MTU avant d'avoir reproduit le symptôme avec la commande ping -M do. Sans cette vérification, vous modifiez une configuration fonctionnelle sur la base d'une supposition — et vous obtenez un nouveau problème à la place de l'ancien. Ne bloquez pas entièrement ICMP ; voir nftables.