Trou noir MTU : pourquoi les petites requêtes passent mais les envois se bloquent

Une page se charge, un petit appel API revient, puis un envoi de fichier reste bloqué jusqu’à ce que le client abandonne. Rien dans le journal du serveur ne l’explique, car les paquets ont été abandonnés au milieu du chemin sans qu’une réponse utile soit renvoyée. Ce schéma est un trou noir MTU : un lien plus étroit que ne le suppose l’émetteur, plus un refus silencieux de le dire. La taille qui échoue est reproductible, et c’est ce qui la rend diagnosticable.

Ce qui rend le trou noir

Chaque lien a une unité de transmission maximale, et un paquet plus grand que la limite du saut suivant doit être fragmenté ou rejeté avec un message ICMP qui le dit. La découverte du MTU du chemin dépend de l’arrivée de ce message et de son respect. Le filtrer ou l’ignorer laisse l’émetteur répéter un paquet qui ne peut jamais passer.

L’encapsulation rend cela courant autour des VPN, car un tunnel ajoute un en-tête externe à un paquet déjà dimensionné pour le lien physique. Le paquet interne est légal à 1500 octets et l’encapsulé ne l’est pas, il meurt donc à la frontière pendant que les petits paquets passent. Une poignée de main terminée et une page de connexion qui fonctionne ne prouvent que le fonctionnement des petits paquets. Le plus gros paquet que l’application tente d’envoyer est celui qui compte.

Trouvez la taille où cela casse

Cherchez par dichotomie la taille de la charge utile avec un test sans fragmentation, depuis un hôte d’un côté du tunnel vers un hôte de l’autre. La plus grande charge utile qui passe est votre MTU de chemin utilisable moins la surcharge d’en-tête.

ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.20

Une charge utile de 1472 octets passe sur un chemin Ethernet propre de 1500 octets une fois ajoutés les 28 octets des en-têtes IPv4 et ICMP. Lorsque le même test ne passe qu’avec une charge plus petite une fois le tunnel monté, la différence est la surcharge d’encapsulation, et la frontière du tunnel est là où le message de rejet aurait dû être généré. Notez les deux nombres, avant et après connexion, car cette paire est la preuve. Répétez le test pour IPv6 lorsque l’application l’utilise, car l’en-tête est plus grand et le seuil de défaillance se déplace.

Lisez les preuves avant de blâmer le tunnel

Les erreurs d’applications distantes, la congestion et la perte ordinaire bloquent aussi les envois, donc un transfert échoué n’identifie pas un trou noir. Ce qui les sépare, c’est la relation de taille : un succès reproductible à 1200 octets et un blocage reproductible à 1400 octets, dans le même sens, par le même point de terminaison.

Une capture aux deux extrémités montre les gros paquets partir et ne jamais arriver, sans rejet entre les deux. C’est le moment de regarder l’équipement de frontière plutôt que le serveur, qui répond à chaque requête qu’il reçoit réellement. La congestion bloque aussi, mais elle bloque des tailles différentes à des moments différents, ce qui est une autre signature.

Vérifiez la réparation sur les deux transports

La réparation prise en charge est de laisser la frontière signaler la vraie limite, ou d’y brider la taille maximale de segment de TCP pour qu’aucun segment trop grand ne soit tenté. Abaisser chaque MTU du réseau, ou désactiver le pare-feu, masque le symptôme et laisse une configuration dont personne ne pourra raisonner plus tard.

ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20

Vérifiez avec le même test de taille, puis avec l’application qui a échoué, et contrôlez un second protocole, car les applications UDP ne reçoivent jamais la correction de taille de segment de TCP. Conservez les valeurs d’origine dans le ticket, car une réparation qui ne peut pas être annulée est un second problème qui attend de se produire. Si le test de taille passe et que l’envoi se bloque encore, le trou noir n’était pas la cause, et l’enquête doit continuer plutôt que d’élargir le changement.