Git se fige dans WSL2 derrière un VPN : MTU de l’interface ou du chemin ?

Le clone s’authentifie, le nombre d’objets apparaît, puis plus rien ne bouge pendant des minutes. Windows indique que le VPN est connecté, le nom d’hôte se résout, et un navigateur sur la même machine récupère la même page du dépôt sans difficulté. Cette combinaison pointe vers la taille des paquets plutôt que vers les identifiants, et la question de la taille doit être posée à deux endroits parce que WSL2 possède sa propre interface Linux avec son propre MTU. Un nombre appartient au côté Windows du chemin, l’autre à la distribution, et ne lire que l’adaptateur VPN laisse la moitié du chemin non examinée.

Trois signaux séparent un problème de taille d’autre chose

Le premier signal est la forme : l’établissement de la connexion et un petit échange réussissent, puis le transfert massif cesse de progresser. Le deuxième est la symétrie : le même dépôt et le même transport échouent alors qu’un autre hôte sur le même chemin fonctionne, ou l’échec varie avec la taille de la charge utile plutôt qu’avec l’heure de la journée. Le troisième est le silence : aucune erreur d’authentification, aucun rejet du proxy, aucun échec de résolution de noms, juste un transfert qui ne se termine jamais.

Ces trois éléments réunis justifient une hypothèse de taille de paquet. Une panne DNS, un jeton expiré, une clé SSH rejetée et un proxy qui refuse CONNECT produisent chacun leur propre erreur, et aucune ne ressemble à un blocage après un succès. Conserver le même dépôt, le même transport et la même fenêtre temporelle pendant le test, voilà ce qui rend la comparaison honnête.

Comparez les deux interfaces avant de décider

Recueillez la vue Windows et la vue Linux dans la même session, et retenez l’adresse du dépôt plutôt que de deviner quelle interface la transporte. La commande ci-dessous résout d’abord la destination afin que la recherche de route décrive le serveur réel que contacte le clone, lequel peut différer du nom affiché par un navigateur. Exécutez les deux moitiés coup sur coup, car le VPN peut modifier les métriques de l’interface entre deux tentatives.

netsh interface ipv4 show subinterfaces
wsl -d Ubuntu -- bash -lc 'dest=$(getent ahostsv4 github.com | awk \'NR==1{print $1}\'); ip -br link show; ip route get "$dest"'

Exécutez la moitié Linux à l’intérieur de la distribution au lieu de coller la sortie dans un shell Windows, car les noms d’interface et la sélection de route n’ont de sens que là. Un copier-coller depuis un shell Windows rapporte les mauvais chiffres avec une grande assurance. Notez l’appareil, la route sélectionnée et le MTU de chaque côté avant de changer quoi que ce soit.

Décidez si le nombre doit être plus petit

Un MTU d’interface supérieur à ce que le chemin peut transporter n’est pas automatiquement un défaut, car la découverte du MTU de chemin existe précisément pour cela. Le mode de défaillance apparaît lorsque la découverte est étouffée : les messages ICMP sont filtrés quelque part en route, l’émetteur n’apprend jamais la limite, et les gros paquets disparaissent tandis que les petits passent. C’est une propriété du chemin, pas une propriété de Git. C’est aussi la raison pour laquelle un petit fichier peut réussir sur une connexion où un gros ne se termine jamais.

Si les preuves le confirment, une modification temporaire de l’interface Linux est le test le moins coûteux. Choisissez une valeur inférieure à la taille utile du chemin, notez la précédente et gardez tout le reste constant pour que la comparaison ait un sens. Si le transfert aboutit avec la valeur plus petite, vous avez un diagnostic et non une coïncidence.

ip -br link show dev eth0
sudo ip link set dev eth0 mtu 1380
ip -br link show dev eth0

Décidez où le réglage doit vivre

Trois options découlent du test, et une seule d’entre elles est généralement appropriée. Si la valeur plus petite corrige le transfert et que la valeur est réellement nécessaire pour ce réseau, le réglage a besoin d’un propriétaire de cycle de vie : un crochet de démarrage dans la distribution, une configuration réseau gérée par la plateforme ou une procédure documentée. Si la valeur ne corrige rien, revenez en arrière et retournez aux questions de transport, de proxy et d’authentification.

L’existence d’un crochet de démarrage dépend des versions de Windows et de WSL utilisées et du mode réseau configuré. Miroiter le réseau Windows peut modifier la façon dont un VPN interagit avec la distribution, d’une manière qui compte plus qu’un ajustement de MTU ; identifiez donc le mode avant de concevoir un contournement pour celui-ci. Une valeur qui convient à un opérateur ou à un profil VPN n’est pas une valeur par défaut pour le suivant.

Ce qu’il faut éviter, c’est l’emplacement tentant : une commande réseau privilégiée dans le fichier de démarrage de chaque shell interactif, ou un sudo sans mot de passe pour tout le binaire ip afin qu’un script puisse exécuter une ligne. Les deux transforment un diagnostic en exposition permanente et rendent le problème initial plus difficile à voir plus tard.

Vérifiez après un démarrage propre, puis annulez

Un changement qui ne survit qu’au redémarrage de la distribution n’est pas une correction. Redémarrez la distribution, reconnectez le VPN et répétez l’opération Git d’origine plutôt qu’un substitut comme un ping ou une petite requête HTTP. Confirmez ensuite que l’interface porte la valeur voulue dans la nouvelle session.

ip -br link show dev eth0
ip route get "$(getent ahostsv4 github.com | awk 'NR==1{print $1}')"

Gardez la valeur d’origine notée à côté du changement pour que l’expérience puisse être annulée proprement, et notez quelle famille d’adresses a été testée, car un résultat IPv4 ne dit rien d’une connexion IPv6 sur le même hôte. La documentation réseau de WSL décrit les modes qui déterminent à quoi doit ressembler une correction ; le nombre de MTU lui-même est une mesure locale, pas une recommandation.