Git s'atura a WSL2 amb VPN: MTU de la interfície o el camí?

El clon s'autentica, apareix el recompte d'objectes i després res no es mou durant minuts. Windows informa que la VPN està connectada, el nom d'amfitrió es resol i un navegador a la mateixa màquina obté la mateixa pàgina del repositori sense dificultats. Aquesta combinació apunta a la mida del paquet més que a les credencials, i la qüestió de la mida s'ha de plantejar en dos llocs perquè WSL2 té la seva pròpia interfície Linux amb el seu propi MTU. Un número pertany al costat Windows del camí, l'altre a la distribució, i llegir només l'adaptador VPN deixa mig camí sense examinar.

Tres senyals separen un problema de mida d'un altre

El primer senyal és la forma: la configuració de la connexió i un intercanvi petit tenen èxit, i després la transferència massiva deixa d'avançar. El segon és la simetria: el mateix repositori i el mateix transport fallen mentre un altre amfitrió al mateix camí funciona, o la fallada canvia amb la mida de la càrrega útil i no amb l'hora del dia. El tercer és el silenci: cap error d'autenticació, cap rebuig del proxy, cap fallada de resolució de noms, només una transferència que mai no acaba.

Aquests tres junts justifiquen una hipòtesi de mida de paquet. Una fallada de DNS, un testimoni caducat, una clau SSH rebutjada i un proxy que rebutja CONNECT produeixen cadascun el seu propi error, i cap no sembla una aturada després d'un èxit. Mantenir el mateix repositori, transport i finestra temporal durant la prova és el que fa honesta la comparació.

Compareu les dues interfícies abans de decidir

Recolliu la vista de Windows i la vista de Linux a la mateixa sessió, i conserveu l'adreça del repositori en lloc d'endevinar quina interfície la transporta. L'ordre següent resol primer la destinació perquè la consulta de ruta descrigui el servidor real amb què contacta el clon, que pot diferir del nom que va mostrar un navegador. Executeu les dues meitats ben juntes, perquè la VPN pot canviar les mètriques de la interfície entre intents.

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"'

Executeu la meitat Linux dins de la distribució en lloc d'enganxar la sortida en un shell de Windows, ja que els noms d'interfície i la selecció de ruta només tenen sentit allà. Una enganxada des d'un shell de Windows informa de números equivocats amb molta confiança. Anoteu el dispositiu, la ruta seleccionada i la MTU de cada costat abans de canviar res.

Decidiu si el número ha de ser més petit

Una MTU d'interfície més gran del que el camí pot transportar no és automàticament un defecte, perquè el descobriment de la MTU del camí existeix precisament per a això. El mode de fallada apareix quan el descobriment se suprimeix: els missatges ICMP es filtren en algun punt del camí, l'emissor no aprèn mai el límit i els paquets grans desapareixen mentre els petits passen. Això és una propietat del camí, no una propietat de Git. És també la raó per la qual un fitxer petit pot tenir èxit en una connexió on un de gran no acaba mai.

Si les proves ho donen suport, un canvi temporal a la interfície Linux és la prova més barata. Trieu un valor per sota de la mida útil del camí, anoteu el anterior i manteniu tota la resta constant perquè la comparació signifiqui alguna cosa. Si la transferència acaba amb el valor més petit, teniu un diagnòstic i no una coincidència.

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

Decidiu on ha de viure el paràmetre

De la prova se'n deriven tres opcions, i normalment només una és adequada. Si el valor més petit arregla la transferència i el valor és realment necessari per a aquesta xarxa, el paràmetre necessita un propietari del cicle de vida: un ganxo d'inici a la distribució, una configuració de xarxa gestionada per la plataforma o un procediment documentat. Si el valor no arregla res, revertiu-lo i torneu a les qüestions de transport, proxy i autenticació.

Que existeixi un ganxo d'inici depèn de les versions de Windows i WSL en ús i del mode de xarxa configurat. Mirallar la xarxa de Windows pot canviar com la VPN interactua amb la distribució de maneres que importen més que un ajust de MTU, així que identifiqueu el mode abans de dissenyar-hi una solució alternativa. Un valor que va bé a un operador o a un perfil de VPN no és un valor per defecte per al següent.

El que cal evitar és la ubicació temptadora: una ordre de xarxa privilegiada al fitxer d'inici de cada shell interactiu, o sudo sense contrasenya per a tot el binari ip perquè un script pugui executar una línia. Totes dues converteixen un diagnòstic en exposició permanent i fan que el problema original sigui més difícil de veure més endavant.

Verifiqueu després d'un inici net i després revertiu

Un canvi que només sobreviu fins que es reinicia la distribució no és una solució. Reinicieu la distribució, torneu a connectar la VPN i repetiu l'operació Git original en lloc d'un substitut com un ping o una petició HTTP petita. Després confirmeu que la interfície porta el valor previst a la sessió nova.

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

Manteniu el valor original anotat al costat del canvi perquè l'experiment es pugui desfer net, i anoteu quina família d'adreces s'ha provat, ja que un resultat IPv4 no diu res sobre una connexió IPv6 al mateix amfitrió. La documentació de xarxes de WSL descriu els modes que determinen com ha de ser una solució; el número de MTU és una mesura local, no una recomanació.