Incompatibilité MTU/MSS sur Debian 13 : pourquoi les gros fichiers se bloquent et comment corriger proprement

Ce qui se passe réellement (sans fioritures)

MTU est la Maximum Transmission Unit : la taille maximale d’un paquet IP qu’un lien peut transporter sans fragmentation. Ethernet est généralement à 1500 octets.
PPPoE force souvent 1492. Les tunnels (WireGuard, VXLAN, GRE, IPsec) soustraient des octets d’en‑tête et réduisent l’MTU effectif.

MSS est la Maximum Segment Size : la taille maximale de la charge utile TCP (sans compter les en‑têtes IP/TCP) qu’un hôte mettra dans un segment TCP.
MSS est négociée pendant la poignée de main TCP via les options dans SYN et SYN-ACK. Si votre path MTU est 1500, alors la MSS TCP sera typiquement
1460 (1500 moins 20 octets d’en‑tête IPv4 moins 20 octets d’en‑tête TCP). En IPv6, la MSS est typiquement autour de 1440 à cause d’un en‑tête de base plus grand.

Le schéma du blocage : pourquoi « petit fonctionne, grand échoue »

Voici le schéma central :

• Les requêtes petites et les sessions interactives gardent les paquets en dessous du véritable path MTU. Elles fonctionnent.
• Les transferts en masse remplissent le tuyau, envoient des segments TCP pleine taille, et finissent par atteindre un paquet qui dépasse le path MTU réel. Ces paquets sont abandonnés.
• Si l’émetteur n’apprend jamais le MTU correct (ou l’ignore), il continue de retransmettre les mêmes segments trop grands. Vous avez alors un « trou noir ».
• Le débit TCP s’effondre. Parfois le transfert semble « suspendu », parfois il tourne à 3 KB/s, parfois il time‑out.

Le mécanisme qui devrait vous sauver est Path MTU Discovery (PMTUD). En IPv4, l’émetteur fixe le bit DF (Do Not Fragment). Lorsqu’un routeur ne peut pas transmettre
un paquet parce qu’il est trop grand, il doit renvoyer un message ICMP « Fragmentation Needed » avec l’MTU du saut suivant. L’émetteur réduit sa taille et réessaie.

Dans un monde parfait, PMTUD est ennuyeux et invisible. Dans le monde réel, ICMP est filtré (« pour la sécurité ») par des pare‑feux qui ont été revus pour la dernière fois quand
on envoyait encore des demandes de changement par fax. L’émetteur ne reçoit jamais l’indice « fragmentation needed », et vous obtenez un trou noir PMTUD.

Debian 13 n’est pas spécial ici — mais les choix par défaut modernes peuvent rendre ce problème plus fréquent :
plus de VPN, plus d’overlays, plus de mises en réseau conteneurisée, plus d’IPv6, plus de bords cloud, plus de middleboxes « aidants ». Vous superposez des en‑têtes comme une lasagne,
puis vous vous étonnez qu’une hypothèse de 1500 octets cesse de tenir.

MTU vs MSS : lequel est « faux » ?

L’incompatibilité MTU est une propriété du lien/du chemin. L’incompatibilité MSS est un comportement TCP côté hôte qui peut être ajusté pour s’adapter au chemin.
Si le path MTU est plus petit que ce que vous pensez, vous pouvez corriger le chemin (idéal) ou clamp(er) la MSS pour que TCP n’émette jamais de paquets trop grands pour le chemin (pragmatique).

Si vous gérez tout le réseau, corrigez l’MTU à la source : rendez le chemin cohérent, fixez les MTU corrects sur les tunnels, assurez‑vous que PMTUD fonctionne.
Si vous ne contrôlez qu’un côté (fréquent en entreprise), le clamp MSS à la périphérie est souvent la solution propre « que l’on peut déployer aujourd’hui ».

Une idée paraphrasée de Werner Vogels (fiabilité/exploitation) : « Tout échoue ; concevez pour que les échecs soient routiniers et se rétablissent automatiquement. »
Les problèmes MTU sont exactement ce type d’échec : routiniers, prévisibles et résolubles grâce à des garde‑fous.

Blague #1 : PMTUD, c’est comme les ragots de bureau — si quelqu’un bloque ICMP, personne n’apprend la nouvelle importante et tout le monde continue de prendre la même mauvaise décision.

Faits et historique qui rendent le comportement compréhensible

Quelques faits concrets expliquent pourquoi ce problème revient, même chez des équipes expérimentées :

1. MTU Ethernet 1500 octets est devenu un standard de facto parce qu’il trouvait un compromis entre efficacité et limites matérielles dans les premiers réseaux locaux ; ce n’est pas sacré, juste courant.
2. MTU classique PPPoE : 1492 car il ajoute 8 octets d’overhead au‑dessus du framing Ethernet, réduisant ce que l’IP peut transporter.
3. Les routeurs IPv6 ne fragmentent pas les paquets en transit. Si vous dépassez le path MTU, vous dépendez d’ICMPv6 « Packet Too Big » pour corriger, sinon vous noyez le flux.
4. La fragmentation IPv4 existe mais on l’évite largement parce que le trafic fragmenté augmente l’amplification des pertes et complique la sécurité/le monitoring.
5. Les trous noirs PMTUD étaient suffisamment fréquents pour que les implémentations TCP ajoutent des heuristiques comme Packetization Layer PMTUD (PLPMTUD), essayant d’inférer le MTU sans dépendre d’ICMP.
6. Le clamp MSS s’est popularisé via des équipements de bord en scénarios ISP/VPN car il fonctionne même quand ICMP est filtré ; c’est une solution de contournement devenue un geste standard.
7. Les jumbo frames (MTU 9000) peuvent améliorer le débit sur des réseaux de stockage, mais seulement si chaque saut les supporte — un seul saut à 1500 MTU en fait une usine à pannes silencieuses.
8. VXLAN et overlays similaires ajoutent ~50 octets d’overhead (souvent plus selon l’underlay), donc un underlay à 1500 implique ~1450 utilisables dans l’overlay.
9. L’MTU effectif de WireGuard dépend du transport et du routage ; « 1420 » est une valeur par défaut courante parce qu’elle évite la fragmentation sur des chemins Internet typiques, mais ce n’est pas universel.

Ce ne sont pas des anecdotes. Ce sont les raisons pour lesquelles votre réseau qui « marchait l’an dernier » commence à échouer après un déploiement VPN, une migration cloud ou une mise à jour de pare‑feu.

Feuille de diagnostic rapide (premier/deuxième/troisième)

L’objectif est de répondre rapidement à une question : Êst‑ce que nous perdons de gros paquets parce que le path MTU réel est plus petit que ce que l’émetteur croit ?
Voici l’ordre qui sauve le plus de temps en production.

Premier : confirmez que le symptôme dépend de la taille, pas d’une perte générique

• Essayez un petit téléchargement et un grand téléchargement depuis le même endpoint.
• Utilisez un ping DF (IPv4) ou un grand ping (IPv6) pour trouver la plus grande taille qui passe.
• Surveillez les retransmissions et le comportement en « trou noir » avec ss et tcpdump.

Deuxième : identifiez où l’MTU change (tunnels, overlays, PPPoE, bords cloud)

• Vérifiez les MTU des interfaces : NIC physique, VLAN, bridge, VPN, veth de conteneur, tunnel.
• Vérifiez les routes pour des indices MTU.
• Confirmez l’encapsulation réellement utilisée (WireGuard ? IPsec ? VXLAN ? GRE ?).

Troisième : décidez du périmètre de correction le plus propre

• Si vous pouvez corriger le chemin, faites‑le (MTU cohérent de bout en bout ; autorisez les messages ICMP de PMTUD).
• Si vous ne pouvez pas, clampez la MSS TCP à la bordure la plus proche de l’émetteur pour les flux affectés.
• Vérifiez avec un test reproductible et capturez la preuve (avant/après).

Cette feuille est volontairement ennuyeuse. Ennuyeux, c’est bien. Ennuyeux signifie que vous arrêtez de faire du « set MTU 1400 partout » en mode cargo‑cult et que vous commencez à faire un changement correct.

Tâches pratiques : commandes, sorties attendues et décisions

Ci‑dessous des tâches pratiques que vous pouvez exécuter sur Debian 13 (ou n’importe quel système Debian‑like moderne) pendant que vous êtes sur le pont d’incident. Chaque tâche inclut :
une commande, ce que la sortie signifie et la décision à prendre ensuite.

Task 1: Check interface MTUs quickly

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp3s0           UP             3c:ec:ef:12:34:56 <BROADCAST,MULTICAST,UP,LOWER_UP>
wg0              UNKNOWN        9a:bc:de:f0:12:34 <POINTOPOINT,NOARP,UP,LOWER_UP>
br0              UP             02:42:ac:11:00:01 <BROADCAST,MULTICAST,UP,LOWER_UP>

cr0x@server:~$ ip link show dev enp3s0 | grep -i mtu
mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000

Signification : Vous recherchez des différences suspectes : NIC physique à 1500, mais un tunnel/overlay qui attend 1420 ; ou un bridge à 1500 alors qu’une interface membre est plus petite.

Décision : Si une interface « supérieure » (bridge/tunnel) a un MTU plus grand que ce que le chemin encapsulé peut transporter, vous avez trouvé le suspect principal.

Task 2: Inspect routes for MTU hints

cr0x@server:~$ ip route get 1.1.1.1
1.1.1.1 via 192.0.2.1 dev enp3s0 src 192.0.2.10 uid 1000
    cache

Signification : Linux peut stocker un MTU par route, mais il ne l’affichera pas toujours sauf s’il est défini. Utile pour vérifier quelle interface est utilisée.

Décision : Si le trafic sort via une interface tunnel ou un VRF inattendu, arrêtez‑vous. Diagnostiquez d’abord ce chemin.

Task 3: Confirm the stall is size-dependent with curl

cr0x@server:~$ curl -o /dev/null -s -w "time=%{time_total} size=%{size_download}\n" https://repo.example.net/small.bin
time=0.18 size=1048576

cr0x@server:~$ curl -o /dev/null -v https://repo.example.net/large.iso
* Connected to repo.example.net (203.0.113.20) port 443
> GET /large.iso HTTP/1.1
> Host: repo.example.net
...
< HTTP/1.1 200 OK
...
  0 4096M    0 1024k    0     0   890k      0  1:18:33  0:00:01  1:18:32  0:00:00
  0 4096M    0 1024k    0     0      0      0 --:--:--  0:00:10 --:--:--     0

Signification : Le grand transfert commence, puis le débit s’effondre. C’est un « quelques paquets passent, puis trou noir » classique.

Décision : Passez aux tests PMTUD et aux captures de paquets. Ne perdez pas de temps sur le DNS, les certificats CA ou « peut‑être que le serveur est lent ».

Task 4: IPv4 PMTUD test using DF ping (find max payload)

cr0x@server:~$ ping -M do -s 1472 -c 2 203.0.113.20
PING 203.0.113.20 (203.0.113.20) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1492
ping: local error: message too long, mtu=1492

--- 203.0.113.20 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1007ms

Signification : Votre hôte sait déjà (ou une interface impose) MTU=1492 quelque part en sortie. Une charge utile 1472 implique un MTU 1500 ; ça échoue et indique 1492.

Décision : Retestez avec -s 1464 (1492-28) et voyez si ça passe. Si oui, vous êtes en territoire PPPoE ou tunnel.

Task 5: Binary search the path MTU (IPv4)

cr0x@server:~$ ping -M do -s 1464 -c 2 203.0.113.20
PING 203.0.113.20 (203.0.113.20) 1464(1492) bytes of data.
1472 bytes from 203.0.113.20: icmp_seq=1 ttl=51 time=22.1 ms
1472 bytes from 203.0.113.20: icmp_seq=2 ttl=51 time=22.0 ms

--- 203.0.113.20 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

Signification : Le path MTU de bout en bout est au plus 1492 (pour IPv4 sur ce chemin).

Décision : Si vos hôtes émetteurs utilisent MTU 1500 et ne s’adaptent pas, clampez la MSS ou ajustez l’MTU pour refléter cette réalité.

Task 6: IPv6 PMTU sanity test

cr0x@server:~$ ping -6 -s 1452 -c 2 2001:db8:100::20
PING 2001:db8:100::20(2001:db8:100::20) 1452 data bytes
From 2001:db8:200::1 icmp_seq=1 Packet too big: mtu=1420
From 2001:db8:200::1 icmp_seq=2 Packet too big: mtu=1420

--- 2001:db8:100::20 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1002ms

Signification : IPv6 vous indique le path MTU (1420). C’est le meilleur scénario : ICMPv6 n’est pas bloqué et PMTUD fonctionne.

Décision : Alignez MTU de tunnel/interface et/ou clamppez la MSS pour IPv6 aussi. Ne « corrigez IPv4 seulement » en pensant que c’est fini.

Task 7: Observe TCP retransmits on the client during the stall

cr0x@server:~$ ss -ti dst 203.0.113.20:443
ESTAB 0 0 192.0.2.10:52144 203.0.113.20:https
	 cubic wscale:7,7 rto:1000 rtt:24.1/4.2 ato:40 mss:1460 pmtu:1500 rcvmss:536 advmss:1460 cwnd:10 bytes_sent:1048576 bytes_acked:1048576 bytes_retrans:65536 retrans:12

Signification : Les retransmissions montent. MSS est 1460 et PMTU indique 1500, mais vos tests précédents suggéraient un MTU plus petit. Ce décalage raconte l’histoire.

Décision : Prouvez si les ICMP « frag needed » manquent, ou si un MTU de tunnel est mal configuré. Passez à tcpdump.

Task 8: Capture PMTUD-related ICMP while reproducing

cr0x@server:~$ sudo tcpdump -ni enp3s0 '(icmp and (icmp[0]=3 and icmp[1]=4)) or (tcp and host 203.0.113.20 and port 443)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:01:10.112233 IP 192.0.2.10.52144 > 203.0.113.20.443: Flags [P.], seq 1:1449, ack 1, win 501, length 1448
12:01:10.212244 IP 192.0.2.10.52144 > 203.0.113.20.443: Flags [P.], seq 1449:2897, ack 1, win 501, length 1448
12:01:11.312255 IP 192.0.2.10.52144 > 203.0.113.20.443: Flags [P.], seq 1449:2897, ack 1, win 501, length 1448
12:01:12.412266 IP 192.0.2.10.52144 > 203.0.113.20.443: Flags [P.], seq 1449:2897, ack 1, win 501, length 1448

Signification : Vous voyez la retransmission répétée du même segment, mais aucun ICMP type 3/code 4 en retour. C’est la signature d’un trou noir PMTUD.

Décision : Autorisez les ICMP nécessaires en retour, ou clampez la MSS pour ne jamais envoyer de segments trop grands dès le départ.

Task 9: Check if a local firewall is blocking PMTUD ICMP

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
		ct state established,related accept
		iif "lo" accept
		tcp dport { 22 } accept
	}
	chain forward {
		type filter hook forward priority filter; policy drop;
	}
	chain output {
		type filter hook output priority filter; policy accept;
	}
}

Signification : La politique input drop par défaut, mais accepte established,related. Les erreurs ICMP sont généralement « related » à un flux existant ; c’est bon, mais pas garanti selon les réglages conntrack et le type ICMP.

Décision : Si vous voyez des drops explicites pour ICMP ou ICMPv6, corrigez‑les d’abord. PMTUD dépend de ces messages.

Task 10: Confirm tunnel overhead and MTU on WireGuard

cr0x@server:~$ ip link show dev wg0 | grep -i mtu
mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000

cr0x@server:~$ sudo wg show wg0
interface: wg0
  public key: 3rY...redacted
  listening port: 51820

peer: q8S...redacted
  endpoint: 198.51.100.77:51820
  allowed ips: 10.10.0.0/16
  latest handshake: 1 minute, 2 seconds ago
  transfer: 1.32 GiB received, 2.01 GiB sent

Signification : wg0 est déjà à 1420. Si les interfaces internes sont à 1500 et routent vers wg0, vous pouvez toujours émettre des paquets trop grands à l’intérieur d’un namespace/bridge
avant d’atteindre la frontière du tunnel.

Décision : Assurez‑vous que l’interface d’émission pour le trafic tunnelisé ait un MTU ≤ MTU de wg0 (ou clamppez la MSS pour le trafic entrant dans wg0).

Task 11: Check bridge/veth MTUs for container hosts

cr0x@server:~$ ip -d link show br0 | sed -n '1,25p'
7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether 02:42:ac:11:00:01 brd ff:ff:ff:ff:ff:ff
    bridge forward_delay 1500 hello_time 200 max_age 2000 stp_state 0 priority 32768

cr0x@server:~$ ip -br link | grep veth | head
veth9f2a2c3       UP             9a:3c:1d:aa:bb:cc <BROADCAST,MULTICAST,UP,LOWER_UP>
veth6a1b7d8       UP             4e:55:66:77:88:99 <BROADCAST,MULTICAST,UP,LOWER_UP>

Signification : br0 est à 1500. Si le underlay est à ~1450 à cause de l’overlay, vos pods/containers peuvent générer des paquets 1500 qui seront ensuite abandonnés.

Décision : Dans les environnements overlay, fixez le MTU des pods/bridges de façon appropriée (ou clampez la MSS à la sortie du nœud).

Task 12: Verify negotiated MSS in an actual connection (tcpdump SYN options)

cr0x@server:~$ sudo tcpdump -ni enp3s0 -c 6 'tcp port 443 and host 203.0.113.20 and (tcp[tcpflags] & (tcp-syn|tcp-ack) != 0)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:05:01.000111 IP 192.0.2.10.52210 > 203.0.113.20.443: Flags [S], seq 111111111, win 64240, options [mss 1460,sackOK,TS val 123 ecr 0,nop,wscale 7], length 0
12:05:01.020222 IP 203.0.113.20.443 > 192.0.2.10.52210: Flags [S.], seq 222222222, ack 111111112, win 65160, options [mss 1440,sackOK,TS val 456 ecr 123,nop,wscale 8], length 0

Signification : Votre hôte a proposé MSS 1460. Le serveur a répondu 1440. Si le vrai path MTU est plus petit (par exemple 1492 ou 1420),
vous voulez que la MSS reflète cela (1460 est trop grand pour 1492 ? En fait 1460 tient dans 1500 ; pour 1492, MSS devrait être 1452).

Décision : Si vous ne pouvez pas faire confiance à PMTUD, clampez la MSS à une valeur sûre basée sur le path MTU mesuré (et faites‑le pour v4 et v6 si nécessaire).

Task 13: Check kernel PMTU/MTU probing behavior

cr0x@server:~$ sysctl net.ipv4.tcp_mtu_probing net.ipv4.ip_no_pmtu_disc
net.ipv4.tcp_mtu_probing = 0
net.ipv4.ip_no_pmtu_disc = 0

Signification : tcp_mtu_probing=0 signifie que le kernel ne probe pas activement des MTU plus petits lorsqu’il est en trou noir ; ip_no_pmtu_disc=0 signifie que PMTUD est activé.

Décision : Ne « réparez » pas ça en désactivant PMTUD globalement. Envisagez d’activer MTU probing sélectivement si vous ne pouvez pas corriger rapidement le réseau, mais considérez‑le comme un filet de secours.

Task 14: Validate that ICMP is permitted through your firewall (IPv4 + IPv6)

cr0x@server:~$ sudo nft list chain inet filter input
table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
		ct state established,related accept
		iif "lo" accept
		ip protocol icmp accept
		ip6 nexthdr ipv6-icmp accept
		tcp dport 22 accept
	}
}

Signification : C’est la configuration « arrêtez d’être malin » : autorisez ICMP et ICMPv6 entrant, au moins pour les erreurs et les messages PMTUD, idéalement avec des limites raisonnables.

Décision : Si ICMP n’est pas autorisé, corrigez‑le. Si vous ne pouvez pas (pare‑feu d’entreprise en amont), le clamp MSS devient votre solution fiable.

Task 15: Implement MSS clamping with nftables (IPv4/IPv6) and verify counters

cr0x@server:~$ sudo nft add table inet mssclamp
cr0x@server:~$ sudo nft 'add chain inet mssclamp forward { type filter hook forward priority mangle; policy accept; }'
cr0x@server:~$ sudo nft add rule inet mssclamp forward tcp flags syn tcp option maxseg size set rt mtu
cr0x@server:~$ sudo nft add rule inet mssclamp forward ip6 nexthdr tcp tcp flags syn tcp option maxseg size set rt mtu

cr0x@server:~$ sudo nft -a list chain inet mssclamp forward
table inet mssclamp {
	chain forward {
		type filter hook forward priority mangle; policy accept;
		tcp flags syn tcp option maxseg size set rt mtu # handle 2
		ip6 nexthdr tcp tcp flags syn tcp option maxseg size set rt mtu # handle 3
	}
}

Signification : Cela clamp(e) la MSS sur les paquets SYN en fonction du MTU de la route automatiquement. C’est généralement plus propre que de coder en dur un nombre, car cela s’adapte par route.

Décision : Utilisez un clamp MSS basé sur la route sur les passerelles/routeurs. Sur des hôtes isolés, vous pouvez clamp(er) dans output si l’hôte initie lui‑même les flux.

Task 16: If you must hardcode, clamp to a known safe MSS

cr0x@server:~$ sudo nft add rule inet mssclamp forward ip protocol tcp tcp flags syn tcp option maxseg size set 1360
cr0x@server:~$ sudo nft add rule inet mssclamp forward ip6 nexthdr tcp tcp flags syn tcp option maxseg size set 1360

Signification : MSS 1360 est souvent sûre pour « Internet + tunnels + inconnus », mais c’est une solution rugueuse. Elle sacrifie de la performance pour la fiabilité.

Décision : Préférez un clamp basé sur la route. Ne codez en dur que lorsque vous ne pouvez pas obtenir d’informations MTU par route cohérentes.

Task 17: Make MTU changes persistent on Debian (systemd-networkd example)

cr0x@server:~$ sudo sed -n '1,120p' /etc/systemd/network/10-enp3s0.network
[Match]
Name=enp3s0

[Network]
DHCP=yes

[Link]
MTUBytes=1492

cr0x@server:~$ sudo systemctl restart systemd-networkd
cr0x@server:~$ ip link show dev enp3s0 | grep -i mtu
mtu 1492 qdisc mq state UP mode DEFAULT group default qlen 1000

Signification : Vous alignez le MTU de l’hôte sur l’exigence réelle du chemin (classique avec PPPoE ou un tunnel connu).

Décision : Si seules certaines destinations sont affectées (certains chemins, pas tous), ne baissez pas le MTU global sur toutes les interfaces. Utilisez un MTU par route ou le clamp MSS à la bordure.

Task 18: Validate the fix with a repeatable transfer test

cr0x@server:~$ curl -o /dev/null -s -w "time=%{time_total} speed=%{speed_download}\n" https://repo.example.net/large.iso
time=43.22 speed=101234567

Signification : Le transfert se termine et le débit est stable. Le symptôme de blocage a disparu.

Décision : Capturez un court tcpdump « après » et engagez le changement avec une note d’incident claire : ce qui a échoué, ce que vous avez changé, comment vous l’avez prouvé.

Blague #2 : Les problèmes MTU sont le seul type de souci réseau où « rendre les paquets plus petits » est à la fois un mauvais conseil et, agaçantement, parfois la bonne solution.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une équipe a déployé un nouveau VPN site‑à‑site entre deux bureaux. Le nouvel appareil « supportait les jumbo frames », et quelqu’un a décidé que puisque le LAN utilisait déjà MTU 9000 pour le stockage, le VPN devait l’égaler. Cohérence, non ?

La bascule s’est bien passée pendant la première heure. Le monitoring affichait des pings propres et une latence normale. SSH fonctionnait. Les gens se sont réjouis discrètement parce que personne ne fait confiance à la célébration bruyante. Puis la sauvegarde nocturne a démarré, et le job s’est figé à quelques pourcents. Le logiciel de sauvegarde a logué des retries et des « connection reset ». L’équipe stockage jurait que ce n’était pas eux. L’équipe réseau jurait que le tunnel était monté. Les deux avaient raison et pourtant tort.

Le problème : l’interface VPN était réglée à 9000, mais la liaison ISP au milieu ne l’était pas. PMTUD aurait dû gérer ça, sauf que le pare‑feu en amont filtrait les messages ICMP fragmentation‑needed. L’émetteur continuait d’envoyer d’énormes paquets qui disparaissaient silencieusement. Le plan de contrôle passait, le plan de données mourait.

La correction fut presque insultante : fixer le MTU du VPN à une valeur qui rentre dans le chemin réel (ou clampper la MSS à l’entrée du tunnel), et autoriser les bons types ICMP.
La cause racine n’était pas « le VPN est instable ». C’était « nous avons supposé que l’Internet respecterait notre MTU LAN ». L’Internet se fiche de vos hypothèses.

Ce qui a changé culturellement était plus important que la correction technique : ils ont ajouté une étape de validation MTU/PMTU à chaque déploiement de tunnel, et ont arrêté de considérer ICMP comme du bruit optionnel. Plus de héros, juste moins de réunions à 2 h du matin.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre société avait un service à haut débit utilisé pour déplacer des artefacts entre agents de build et un cache central. Quelqu’un a remarqué que les NIC, switches et hyperviseurs supportaient les jumbo frames. Le service étant sensible au débit, ils ont activé MTU 9000 sur les serveurs. Ça a bien benchmarké dans le même rack. Tout le monde était content.

Quelques semaines plus tard, un nouveau jeu d’agents de build dans un autre DC a commencé à signaler des timeouts intermittents en téléversant de gros artefacts. Le plus pénible : ça ne ratait que pour les builds « gros ». Les petits passaient. L’équipe a chassé la charge CPU, les réglages TLS et le load balancer. Ils ont mis à jour quelques kernels.
Ils ont même changé le niveau de compression des artefacts. Les échecs ont persisté.

Le chemin réseau entre les DCs avait un seul segment encore à MTU 1500. Les serveurs avec jumbo envoyaient joyeusement de gros segments,
qui étaient fragmentés ou abandonnés selon le saut. Certains flux survivaient selon le routage. D’autres mouraient à cause d’ECMP choisissant le chemin plus strict.

Ils ont corrigé en revenant en arrière sur les jumbo frames pour le service d’artefacts et en standardisant le MTU sur le chemin inter‑DC avant de réactiver.
Les jumbo frames n’étaient pas intrinsèquement mauvaises ; elles étaient mauvaises comme optimisation appliquée seulement sur une partie de la topologie. Le gain de performance existait,
mais le coût en fiabilité était plus élevé que prévu.

Le postmortem fut direct : ne déployez pas partiellement des changements MTU. Soit vous vous engagez pour un design bout‑à‑bout, soit vous restez à 1500 et dépensez votre budget performance autrement.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation de services financiers avait l’habitude qui ressemblait à de la bureaucratie : lorsqu’un changement réseau impliquait des tunnels, overlays ou circuits WAN,
ils exigeaient une checklist de pré‑vol. Elle incluait une ligne que les ingénieurs aimaient détester :
« Vérifier PMTUD ou appliquer le clamp MSS ; joindre des preuves. »

Lors d’une migration vers une nouvelle plateforme d’accès distant, un ingénieur a exécuté la checklist et a découvert que de grands pings DF échouaient via un certain fournisseur.
Les petits paquets passaient. Le fournisseur filtrait certains types ICMP (parce que bien sûr il le faisait), mais seulement sur une région. L’ingénieur a ajouté un clamp MSS
sur le concentrateur VPN pour cette région et a joint les captures avant/après. La migration a continué.

Deux semaines plus tard, une autre équipe a signalé « les gros uploads se bloquent » depuis cette région. L’on‑call a ouvert les notes de migration, a vu le clamp MSS et les preuves,
et a immédiatement exclu le trou noir MTU comme nouvelle cause. Ils ont ciblé une régression applicative et l’ont corrigée rapidement.

La pratique ennuyeuse n’a pas seulement empêché une panne. Elle a évité un mauvais diagnostic lors d’un incident ultérieur, ce qui vaut presque autant. De bonnes notes sont un multiplicateur de force opérationnelle.

Correction propre : solutions préférées par ordre

On peut « réparer » un désaccord MTU/MSS de mille façons. Peu sont propres. Voici l’ordre que je recommande en production, avec une forte préférence pour
des changements qu’on peut expliquer à 3 h du matin et inverser à midi.

1) Rendre le path MTU cohérent (meilleur, plus difficile)

Si vous possédez le réseau de bout en bout, standardisez le MTU sur le chemin. Pour les overlays, augmentez le MTU de l’underlay afin que l’overlay puisse rester à 1500.
Exemple : si VXLAN ajoute ~50 octets, réglez l’underlay MTU à 1550+ pour que l’overlay puisse fonctionner en 1500 sans fragmentation.

C’est la correction « faire proprement ». C’est aussi celle qui exige coordination entre équipes et fournisseurs, ce qui explique qu’elle n’est pas toujours la seule appliquée.

2) Assurer que PMTUD fonctionne (autoriser les bons ICMP)

PMTUD n’est pas optionnel si vous attendez d’un réseau moderne qu’il fonctionne. Autorisez ICMP type 3/code 4 en IPv4 (« fragmentation needed »).
Autorisez ICMPv6 « packet too big » et autres messages de contrôle nécessaires en IPv6.

L’essentiel n’est pas « autoriser tout ICMP pour toujours ». L’essentiel est « ne cassez pas le protocole puis étonnez‑vous du résultat ».
Si vous devez limiter le débit, faites‑le prudemment et testez.

3) Clamp MSS TCP à la bordure (meilleure solution pragmatique)

Le clamp MSS ajuste la valeur MSS TCP pendant le SYN pour que les endpoints conviennent de segments plus petits qui tiendront dans le path MTU.
Cela fonctionne même quand ICMP est filtré. Ça ne nécessite pas de changements côté hôte. C’est réversible. C’est facile à circonscrire.

Utilisez le clamp MSS basé sur la route quand c’est possible (comme dans la tâche nftables). Coder en dur une MSS est acceptable quand l’environnement est chaotique,
mais considérez‑le comme un pansement temporaire.

4) Baisser l’MTU sur l’hôte uniquement si l’hôte vit vraiment sur ce chemin contraint

Baisser le MTU sur une interface hôte est propre lorsque l’egress principal de l’hôte est réellement contraint (PPPoE classique à 1492).
Ce n’est pas propre quand seules certaines destinations sont contraintes. Vous pénalisez alors tout le reste pour réparer un chemin.

5) Activer le MTU probing TCP comme solution tactique, pas stratégique

Activer net.ipv4.tcp_mtu_probing peut permettre à Linux de se remettre de trous noirs en sondant des MTU plus petits.
Cela peut aider si vous ne contrôlez pas le pare‑feu au milieu et que vous avez besoin d’un soulagement rapide.

Mais ne confondez pas « le noyau a contourné le problème » avec « le réseau est sain ». Si vous pouvez clamp(er) la MSS ou fixer ICMP, faites‑le.

Erreurs courantes : symptôme → cause racine → correctif

Ce sont les schémas que je vois régulièrement dans les organisations réelles. Les corrections sont spécifiques parce que les conseils vagues transforment les incidents en « mystères ».

1) Gros téléchargements HTTPS qui se bloquent, mais petites pages chargent

Symptôme : Le site s’affiche ; le téléchargement d’un ISO se bloque à quelques Mo.

Cause racine : Trou noir PMTUD : ICMP fragmentation‑needed bloqué quelque part ; l’émetteur continue d’utiliser une MSS/MTU trop grande.

Fix : Autoriser ICMP type 3/code 4 (IPv4) et ICMPv6 Packet Too Big ; ou clampper la MSS sur la passerelle pour TCP/443.

2) SSH fonctionne, scp/rsync se bloque ou rampe

Symptôme : SSH interactif correct ; copie de fichier bloquée ou très lente.

Cause racine : Les paquets de données atteignent la limite path MTU ; les retransmissions explosent ; les paquets interactifs restent petits et s’en sortent.

Fix : Confirmer avec un ping DF ; clamp MSS pour TCP/22 sur le chemin ; valider que les retransmissions diminuent après correction.

3) Kubernetes : certains pods tirent des images, d’autres time‑out

Symptôme : Nœud A ok ; nœud B échoue à puller de grosses layers ; les redémarrages « réparent » parfois.

Cause racine : MTU mixte dans CNI overlay/underlay ; ECMP choisit des chemins différents avec des MTU effectifs différents.

Fix : Aligner le MTU CNI avec l’underlay ; ou clamp MSS à la sortie du nœud ; standardiser MTU sur tous les nœuds.

4) « On a activé les jumbo frames et maintenant la réplication inter‑DC est instable »

Symptôme : Sessions de réplication reset, gros transferts échouent de façon intermittente.

Cause racine : Jumbo activé seulement sur certains segments ; un saut à 1500 provoque fragmentation/abandon.

Fix : Revenir à 1500 jusqu’à ce que l’ensemble du chemin supporte jumbo ; puis réintroduire avec validation bout‑à‑bout.

5) IPv6 plus lent ou qui échoue seulement pour les gros transferts

Symptôme : Hôte dual‑stack préfère IPv6 ; gros transferts bloqués alors que IPv4 fonctionne.

Cause racine : ICMPv6 Packet Too Big bloqué ; les routeurs IPv6 ne fragmentent pas ; trou noir se produit.

Fix : Autoriser correctement ICMPv6 ; clamp MSS pour IPv6 ; vérifier avec ping -6 et tcpdump.

6) « On a mis MTU 1400 partout » et la performance a chuté

Symptôme : Tout fonctionne, mais le débit a baissé et la charge CPU a augmenté.

Cause racine : Sur‑correction : vous avez réduit l’MTU bien en dessous de ce que le chemin nécessite, augmentant l’overhead et le taux d’interruptions.

Fix : Mesurez le PMTU réel ; réglez MTU/MSS sur le minimum requis, pas une valeur arbitraire superstitieuse.

Listes de vérification / plan pas à pas

Checklist A : Quand un gros transfert se bloque maintenant

1. Reproduisez avec une commande (curl ou scp) et notez l’horodatage.
2. Exécutez un ping DF (IPv4) ou un grand ping (IPv6) vers la même destination ; trouvez la plus grande charge utile qui passe.
3. Vérifiez ss -ti pour les retransmissions et les valeurs MSS/PMTU pendant le blocage.
4. Lancez un court tcpdump recherchant retransmissions répétées et absence d’ICMP « too big ».
5. Si ICMP est bloqué et que vous contrôlez la bordure : appliquez le clamp MSS (basé sur la route si possible).
6. Retestez le transfert ; capturez la preuve « après » ; rendez le changement persistant.

Checklist B : Avant de déployer un tunnel/overlay

1. Calculez l’overhead (tunnel + encapsulation + éventuels tags VLAN) et décidez d’un MTU cible.
2. Fixez l’underlay MTU pour supporter l’overlay MTU (préféré), ou réduisez l’overlay MTU (acceptable).
3. Confirmez que ICMP/ICMPv6 nécessaires pour PMTUD sont autorisés à travers les périmètres de sécurité.
4. Validez avec un ping DF et un vrai test de transfert en masse à travers le tunnel.
5. Documentez le MTU choisi, où il est appliqué et quelles preuves vous avez capturées.

Checklist C : Guide de sélection de la « correction propre »

• Vous possédez tout le chemin : standardisez le MTU de bout en bout ; laissez l’overlay à 1500 si possible ; maintenez PMTUD opérationnel.
• Vous possédez seulement la bordure : clamp MSS basé sur la route + vérifier PMTU ; éventuellement ajuster le MTU local pour des liens contraints connus.
• Vous possédez seulement un hôte : ajustez le MTU sur l’interface pertinente si cet hôte utilise toujours le chemin contraint ; sinon envisagez un clamp MSS local en output.

FAQ

1) Pourquoi les pings réussissent tandis que les gros transferts TCP échouent ?

Parce que les pings typiques sont petits (payload 56 octets par défaut). Ils ne dépassent jamais le path MTU. Les gros transferts TCP utilisent des segments proches de l’MTU,
qui déclenchent des abandons lorsque le path MTU réel est plus petit.

2) Est‑ce vraiment MTU/MSS, ou peut‑ce être une perte générique de paquets ?

La perte générique affecte généralement tout : sessions interactives, petits téléchargements, appels API. Les trous noirs MTU sont sélectifs : le petit passe, le gros bloque.
Prouvez‑le avec des tests ping DF et un tcpdump montrant retransmissions répétées sans réponses ICMP « too big ».

3) Quelle est la différence entre corriger MTU et clamp MSS ?

Corriger l’MTU rend le chemin réseau capable de transporter les paquets que vous envoyez, de façon cohérente. Clamp MSS indique aux endpoints TCP d’envoyer des payloads plus petits
pour que les paquets tiennent dans le chemin existant. La correction MTU est architecturale ; le clamp MSS est pragmatique opérationnel.

4) Dois‑je simplement mettre MTU à 1400 partout ?

Non. Cela peut masquer le symptôme, mais c’est une taxe de performance et cela peut casser des chemins internes qui supportent réellement 1500 ou des jumbo frames.
Mesurez le PMTU réel et faites le plus petit changement nécessaire pour restaurer le comportement correct.

5) Debian 13 change‑t‑il quelque chose au comportement MTU ?

Debian 13 utilise des kernels et des outils modernes (systemd‑networkd, nftables, comportements TCP contemporains). Le problème n’est pas spécifique à Debian.
Mais Debian 13 facilite la mise en œuvre de corrections propres (clamp MSS avec nftables, config réseau cohérente) si vous utilisez correctement la pile native.

6) Est‑il sûr d’autoriser ICMP via les pare‑feux ?

« Autoriser tout ICMP » est paresseux. « Bloquer tout ICMP » est pire. Vous devriez autoriser les types essentiels ICMP/ICMPv6 pour le reporting d’erreurs et PMTUD,
idéalement avec des limites de débit. Si vous les bloquez, vous cassez un comportement fondamental d’Internet et vous le payez en pannes.

7) Quelle valeur MSS devrais‑je clamp(er) ?

Préférez un clamp MSS basé sur la route (set rt mtu) pour qu’il s’adapte. Si vous devez coder en dur, calculez à partir du path MTU :
MSS IPv4 ≈ MTU‑40, MSS IPv6 ≈ MTU‑60 (selon les options). En cas d’incertitude, choisissez une valeur conservatrice puis affinez par mesure.

8) Pourquoi ça échoue seulement pour certaines destinations ?

Différentes destinations peuvent emprunter des chemins distincts (ECMP, pairs différents, points de sortie VPN différents), chacun avec un MTU goulot d’étranglement ou un filtrage ICMP différent.
C’est pourquoi un même hôte peut « marcher vers A, échouer vers B ».

9) Les middleboxes peuvent‑elles réécrire la MSS ?

Oui. Certains pare‑feux et load balancers clampent déjà la MSS automatiquement. Cela peut masquer le problème — ou le rendre plus étrange si seuls certains chemins clampent.
Considérez la MSS comme quelque chose qui peut changer en transit et vérifiez avec des captures tcpdump des options SYN.

10) Et si c’est du UDP (comme certains stockage ou streaming) ?

Le clamp MSS est spécifique à TCP. Pour des charges UDP, vous avez besoin d’un MTU correct et/ou d’un contrôle de fragmentation au niveau applicatif.
En pratique, corrigez le path MTU ou configurez l’application pour utiliser des datagrammes plus petits.

Prochaines étapes à faire aujourd’hui

Si vous observez des gros transferts qui se bloquent sur Debian 13, traitez‑le comme un vrai bug réseau, pas une histoire de fantômes.
Faites trois choses, dans cet ordre :

1. Prouvez le path MTU. Exécutez des tests ping DF (IPv4) et/ou des tests IPv6 « packet too big ». Capturez la plus grande taille qui passe.
2. Capturez des preuves. Un tcpdump de 30 secondes montrant retransmissions répétées et absence d’ICMP vaut mille arguments Slack.
3. Appliquez une correction propre. Préférez : corriger la cohérence MTU et autoriser les ICMP de PMTUD. Si vous ne pouvez pas, clamppez la MSS à la bordure avec nftables.

Après la correction, relancez le même test de transfert en masse, puis enregistrez les sorties et captures avec le dossier de changement. La différence entre
« on l’a réparé » et « on a eu de la chance » est la documentation et la reproductibilité. Aussi, votre futur vous sera reconnaissant.