# Blocages de MTU sous WSL Un hôte WSL2 est la seule configuration où une session se connecte normalement puis s'arrête, tout simplement, sans erreur d'aucun côté. Ce n'est presque jamais SSH ni Tessera — c'est la MTU de l'adaptateur virtuel derrière lequel WSL2 se trouve. Quand Tessera observe ce blocage caractéristique pendant la connexion, il affiche une carte ambre *problème de MTU possible avec WSL2 / Tailscale* qui renvoie ici. ## Symptômes - La session se connecte, l'invite apparaît, et les commandes courtes s'exécutent normalement. - Tout ce qui envoie une grosse rafale se fige : un `cat` sur un fichier long, un `ls` large, un rafraîchissement complet de tmux, un transfert dans le [panneau fichiers](https://bambouville.com/docs/fr/files/). - Rien ne signale d'échec. La session cesse simplement d'avancer. Se reconnecter fonctionne, puis le blocage revient sur le même type de sortie. - Le même hôte se comporte mieux en mosh qu'en ssh. Si la connexion n'atteint jamais l'invite, la même panne peut avaler l'échange de clés SSH, qui est lui-même volumineux. Le test ci-dessous s'applique quand même. ## Pourquoi cela arrive WSL2 tourne derrière un commutateur virtuel Hyper-V, et son `eth0` démarre avec une MTU de 1500. Quand la machine Windows atteint en réalité le réseau à travers quelque chose de plus petit — un VPN, du PPPoE ou n'importe quel tunnel — les paquets dépassant cette MTU de chemin réelle sont abandonnés quelque part en route. La découverte de la MTU de chemin est censée gérer exactement cela : le saut incapable de transmettre le paquet renvoie un ICMP *fragmentation needed*, et l'émetteur réduit la taille. Beaucoup de VPN et de pare-feu abandonnent cet ICMP, si bien qu'aucune réponse n'arrive jamais. Les petits paquets continuent de passer et les gros disparaissent en silence — un trou noir de PMTU. Pour SSH, cela ressemble à une connexion qui s'est arrêtée sans raison. ## Le confirmer Depuis WSL, regardez ce que l'interface annonce : ``` ip link show eth0 ``` Trouvez ensuite la taille qui survit réellement au chemin. Ces pings activent le bit don't-fragment, et la charge utile plus 28 octets d'en-tête donne la taille totale : `-s 1472` sonde donc un paquet de 1500 octets. Visez quelque chose situé de l'autre côté du même chemin — le serveur auquel vous vous connectez, ou n'importe quelle adresse publique : ``` ping -M do -s 1472 -c 1 example.com # 1500 — usually times out ping -M do -s 1372 -c 1 example.com # 1400 — usually gets through ``` Un **timeout**, c'est le trou noir. (Une erreur locale immédiate signifie au contraire que la taille dépasse la MTU de votre propre interface — baissez `-s` et réessayez.) Resserrez la fourchette jusqu'à trouver la plus grande charge utile qui répond ; ajoutez 28 et vous obtenez votre MTU de chemin réelle. Les équivalents côté Windows, depuis PowerShell : ``` ping -f -l 1472 example.com netsh interface ipv4 show subinterfaces ``` La seconde liste la MTU de chaque adaptateur. Un adaptateur VPN à 1400 à côté de `vEthernet (WSL)` à 1500, voilà l'incohérence que vous cherchez. ## Corriger dans WSL Réglez l'interface sur la taille que vous avez mesurée. Cela prend effet immédiatement et se perd au prochain arrêt : ``` sudo ip link set dev eth0 mtu 1400 ``` Reconnectez-vous et refaites ce qui bloquait. Si la sortie défile proprement, le diagnostic est confirmé. Pour que cela persiste, demandez à WSL de l'appliquer au démarrage. Dans `/etc/wsl.conf`, à l'intérieur de la distribution : ``` [boot] command = ip link set dev eth0 mtu 1400 ``` Lancez ensuite `wsl --shutdown` depuis Windows, puis redémarrez la distribution. La commande `[boot]` demande un WSL raisonnablement récent — vérifiez avec `wsl --version`. Utilisez le nombre produit par votre test de ping plutôt que de recopier 1400. C'est une valeur de repli sûre, qui passe presque tous les VPN, mais une valeur ajustée à votre chemin gaspille moins sur chaque paquet. ## Ou laisser WSL refléter l'hôte Sous Windows 11 22H2 et ultérieur avec WSL 2.0+, le réseau en miroir donne à la distribution les interfaces de la machine hôte, MTU comprises, si bien que l'incohérence ne se produit jamais. Dans `%UserProfile%\.wslconfig` : ``` [wsl2] networkingMode=mirrored ``` Appliquez avec `wsl --shutdown`. Cela change bien plus que la MTU — la joignabilité de localhost et celle du LAN se comportent l'une comme l'autre différemment — préférez donc la commande de démarrage si une session qui bloque est votre seul problème. ## Quand le saut à faible MTU est du côté serveur WSL n'est pas toujours l'extrémité contrainte ; refaire le même test de ping depuis le serveur vous dit quel côté est bridé. Là où vous contrôlez le routeur intermédiaire, ramener le MSS de TCP à la MTU de chemin découverte corrige d'un coup toutes les connexions qui le traversent : ``` iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN \ -j TCPMSS --clamp-mss-to-pmtu ``` ## Tant que vous êtes bloqué Basculer le [transport](https://bambouville.com/docs/fr/connections/#transport-ssh-ou-mosh) de l'hôte sur mosh est un contournement, pas un correctif. Les datagrammes de mosh sont assez petits pour se glisser sous une MTU cassée, et il repeint l'écran au lieu de rejouer un flux d'octets : une session interactive survit donc. Le panneau fichiers et le canal tmux secondaire empruntent toujours SSH, si bien que les gros transferts peuvent continuer à bloquer. Si rien de tout cela ne correspond à ce que vous observez, capturez un journal (**réglages → diagnostics → exporter le journal**, voir [diagnostics](https://bambouville.com/docs/fr/security/#diagnostics)) et ouvrez un ticket sur [GitHub Issues](https://github.com/bambouville/tessera/issues).