WSL2 se Git staak op 'n VPN: koppelvlak-MTU of die pad?

Die kloon verifieer, die objektelling verskyn, en dan beweeg niks vir minute nie. Windows rapporteer die VPN as gekoppel, die gasheernaam los op, en 'n blaaier op dieselfde masjien haal dieselfde bewaarplekbladsy sonder moeite. Daardie kombinasie dui op pakketgrootte eerder as op geloofsbriewe, en die groottevraag moet op twee plekke gevra word, want WSL2 het sy eie Linux-koppelvlak met sy eie MTU. Een getal hoort by die Windows-kant van die pad, die ander by die verspreiding, en as jy net die VPN-adapter lees, bly die helfte van die pad ondersoek.

Drie tekens skei 'n grootteprobleem van iets anders

Die eerste teken is vorm: verbindingsopstelling en 'n klein uitruiling slaag, dan hou grootmaatoordrag op om vordering te maak. Die tweede is simmetrie: dieselfde bewaarplek en dieselfde vervoer misluk terwyl 'n ander gasheer op dieselfde pad werk, of die mislukking verander met die vragrootte eerder as met die tyd van die dag. Die derde is stilte: geen verifikasiefout nie, geen volmagverwerping nie, geen naamoplossingsfout nie, net 'n oordrag wat nooit voltooi nie.

Daardie drie saam regverdig 'n pakketgrootte-hipotese. 'n DNS-fout, 'n verval' token, 'n verwerpte SSH-sleutel en 'n volmag wat CONNECT weier, lewer elkeen sy eie fout, en nie een van hulle lyk soos 'n staking ná sukses nie. Om dieselfde bewaarplek, vervoer en tydvenster tydens toetsing te behou, is wat die vergelyking eerlik maak.

Vergelyk albei koppelvlakke voordat jy besluit

Versamel die Windows-aansig en die Linux-aansig in dieselfde sessie, en hou die bewaarplek se adres eerder as 'n raaiskoot oor watter koppelvlak dit dra. Die opdrag hieronder los eers die bestemming op, sodat die roetesoektog die werklike bediener beskryf wat die kloon kontak, wat van die naam wat 'n blaaier getoon het, kan verskil. Voer albei helftes kort na mekaar uit, want die VPN kan koppelvlakmaatstawwe tussen pogings verander.

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

Voer die Linux-helfte binne die verspreiding uit in plaas daarvan om die uitset in 'n Windows-dop te plak, want die koppelvlakname en roetekeuse maak net daar sin. 'n Plak uit 'n Windows-dop rapporteer die verkeerde getalle met groot selfvertroue. Teken die toestel, die gekose roete en die MTU van elke kant aan voordat jy enigiets verander.

Besluit of die getal kleiner moet wees

'n Groter koppelvlak-MTU as wat die pad kan dra, is nie outomaties 'n fout nie, want pad-MTU-ontdekking bestaan juis om dit te hanteer. Die foutmodus verskyn wanneer ontdekking onderdruk word: ICMP-boodskappe word êrens langs die pad gefiltreer, die sender leer nooit die limiet nie, en groot pakkette verdwyn terwyl klein s'n slaag. Dit is 'n eienskap van die pad, nie van Git nie. Dit is ook die rede waarom 'n klein lêer kan slaag op 'n verbinding waar 'n groot een nooit klaarkry nie.

As die bewyse dit ondersteun, is 'n tydelike verandering op die Linux-koppelvlak die goedkoopste toets. Kies 'n waarde onder die bruikbare padgrootte, teken die vorige een aan, en hou alles anders konstant sodat die vergelyking iets beteken. As die oordrag by die kleiner waarde voltooi, het jy 'n diagnose eerder as 'n toevalligheid.

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

Besluit waar die instelling moet woon

Drie opsies volg uit die toets, en net een van hulle is gewoonlik geskik. As die kleiner waarde die oordrag regmaak en die waarde werklik vir hierdie netwerk nodig is, het die instelling 'n eienaar vir sy lewensduur nodig: 'n beginhaak in die verspreiding, 'n netwerkkonfigurasie wat deur die platform bestuur word, of 'n gedokumenteerde prosedure. As die waarde niks regmaak nie, draai dit terug en keer terug na die vrae oor vervoer, volmag en verifikasie.

Of 'n beginhaak bestaan, hang af van die Windows- en WSL-weergawes wat gebruik word en van die gekonfigureerde netwerkmodus. Die spieël van die Windows-netwerk kan verander hoe 'n VPN met die verspreiding omgaan, op maniere wat meer saak maak as 'n MTU-aanpassing, so identifiseer die modus voordat jy 'n tydelike oplossing daarvoor ontwerp. 'n Waarde wat by een operateur of een VPN-profiel pas, is nie 'n verstek vir die volgende nie.

Wat om te vermy, is die aanloklike plasing: 'n bevoorregte netwerkopdrag in elke interaktiewe dop se beginlêer, of sudo sonder wagwoord vir die hele ip-program sodat 'n skrip een reël kan uitvoer. Albei verander 'n diagnostiek in permanente blootstelling en maak die oorspronklike probleem later moeiliker om te sien.

Verifieer ná 'n vars begin en draai dit dan terug

'n Verandering wat net tot die volgende herbegin van die verspreiding hou, is nie 'n oplossing nie. Herbegin die verspreiding, koppel die VPN weer, en herhaal die oorspronklike Git-bewerking eerder as 'n plaasvervanger soos 'n ping of 'n klein HTTP-versoek. Bevestig dan dat die koppelvlak die bedoelde waarde in die nuwe sessie dra.

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

Hou die aangetekende oorspronklike waarde langs die verandering sodat die eksperiment skoon ongedaan gemaak kan word, en let op watter adresfamilie getoets is, want 'n IPv4-uitslag sê niks oor 'n IPv6-verbinding op dieselfde gasheer nie. Die WSL-netwerkdokumentasie beskryf die modusse wat bepaal hoe 'n oplossing moet lyk; die MTU-getal self is 'n plaaslike meting, nie 'n aanbeveling nie.