Git stöðvast í WSL2 í gegnum VPN: MTU viðmótsins eða leiðin?
Git auðkennir sig og hangir svo inni í WSL2? Berið saman Linux-viðmótið og VPN-tengið í Windows, prófið eitt minna gildi og skipuleggið líftíma þess.
Klóninn auðkennir sig, fjöldi hluta birtist og svo hreyfist ekkert í mínútur. Windows tilkynnir að VPN sé tengt, hýsilnafnið leysist og vafri á sömu vél sóttir sömu hólfsíðuna án vandræða. Þessi samsetning bendir til pakkastærðar frekar en skilríkja, og spyrja verður um stærðina á tveimur stöðum því WSL2 hefur eigið Linux-viðmót með eigin MTU. Ein tala tilheyrir Windows-hlið leiðarinnar, hin dreifingunni, og að lesa aðeins VPN-tengið lætur helming leiðarinnar óskoðaðan.
Þrjú merki aðskilja stærðarvandamál frá öðru
Fyrsta merkið er lögun: tenging og lítil skipti takast, svo stöðvast magnflutningurinn. Annað er samhverfa: sama hólf og sama flutningur mistakast á meðan annar hýsill á sömu leið virkar, eða bilunin breytist með stærð farmsins en ekki tíma dags. Þriðja er þögnin: engin auðkenningarvilla, engin höfnun milliþjóns, engin nafnupplausnarbilun, bara flutningur sem klárast aldrei.
Þessi þrjú saman réttlæta tilgátu um pakkastærð. DNS-bilun, útrunnið tákn, hafnaður SSH-lykill og milliþjónn sem hafnar CONNECT framleiða hvert sína villu, og ekkert þeirra lítur út eins og stöðvun eftir árangur. Að halda sama hólfi, sama flutningi og sama tímaglugga við prófun er það sem gerir samanburðinn heiðarlegan.
Berðu saman bæði viðmótin áður en þú ákveður
Safnið Windows-sýninni og Linux-sýninni í sama lotu, og haldið í vistfang hólfsins frekar en að giska á hvaða viðmót ber það. Skipunin hér að neðan leysir áfangastaðinn fyrst svo leiðarleitin lýsi raunverulega þjóninum sem klóninn heimsækir, sem getur verið annar en nafnið sem vafrinn sýndi. Keyrið báða helmingana skammt hvor frá öðrum, því VPN getur breytt mæligildum viðmótsins milli tilrauna.
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"'
Keyrið Linux-helminginn inni í dreifingunni í stað þess að líma útkomuna í Windows-skel, því viðmótsnöfn og leiðarval hafa aðeins merkingu þar. Líming úr Windows-skel tilkynnir röngu tölurnar með mikilli vissu. Skráið tækið, valda leið og MTU frá hvorri hlið áður en þið breytið nokkru.
Ákveðið hvort talan eigi að vera minni
Stærra viðmóts-MTU en leiðin getur borið er ekki sjálfkrafa galli, því uppgötvun leiðar-MTU er einmitt til fyrir það. Bilunarhamurinn kemur fram þegar uppgötvun er kæfð: ICMP-skilaboð eru sigtuð einhvers staðar á leiðinni, sendandinn lærir aldrei mörkin og stórir pakkar hverfa á meðan litlir komast í gegn. Þetta er eiginleiki leiðarinnar, ekki eiginleiki Git. Þetta er líka ástæðan fyrir því að lítil skrá getur tekist á tengingu þar sem stór klárast aldrei.
Ef sannanir styðja það er tímabundin breyting á Linux-viðmótinu ódýrasta prófið. Veljið gildi undir nothæfri leiðarstærð, skráið það fyrra og haldið öllu öðru stöðugu svo samanburðurinn þýði eitthvað. Ef flutningurinn klárast við minna gildið hefur þú greiningu en ekki tilviljun.
ip -br link show dev eth0
sudo ip link set dev eth0 mtu 1380
ip -br link show dev eth0
Ákveðið hvar stillingin á að búa
Þrír kostir fylgja prófinu, og venjulega er aðeins einn þeirra viðeigandi. Ef minna gildið lagar flutninginn og gildið er raunverulega nauðsynlegt fyrir þetta net þarf stillingin eiganda líftíma: ræsingarkrók í dreifingunni, netstillingu sem stýrt er af pallinum eða skjalfesta ferli. Ef gildið lagar ekkert skal setja það til baka og snúa aftur að spurningum um flutning, milliþjón og auðkenningu.
Hvort ræsingarkrókur er til fer eftir Windows- og WSL-útgáfum sem eru í notkun og stilltri netstillingu. Speglun Windows-netsins getur breytt því hvernig VPN hefur samskipti við dreifinguna á vegu sem skiptir meira máli en MTU-aðlögun, svo greinið haminn áður en þið hanni sniðgöngu fyrir hann. Gildi sem hentar einum símafyrirtæki eða einni VPN-sniði er ekki sjálfgefið fyrir það næsta.
Það sem forðast á er freistandi staðsetningin: forgangsnetskipun í ræsingarskrá hverrar gagnvirkrar skeljar, eða sudo án lykilorðs fyrir allan ip tvíundarforritið svo skrift geti keyrt eina línu. Bæði gera greiningu að varanlegri vá og gera upprunalega vandann erfiðara að sjá síðar.
Sannreynið eftir hreina ræsingu og snúið svo við
Breyting sem lifir aðeins þar til dreifingin endurræsist er ekki lagfæring. Endurræsið dreifinguna, tengið VPN aftur og endurtakið upprunalegu Git-aðgerðina í stað staðgengils eins og ping eða lítillar HTTP-beiðni. Staðfestið svo að viðmótið beri fyrirhugað gildi í nýju lotunni.
ip -br link show dev eth0
ip route get "$(getent ahostsv4 github.com | awk 'NR==1{print $1}')"
Haldið skráða upprunalega gildinu við hlið breytingarinnar svo hægt sé að afturkalla tilraunina hreinlega, og skráið hvaða vistfangafjölskylda var prófuð, því IPv4-niðurstaða segir ekkert um IPv6-tengingu á sama hýsli. WSL-netsskjölin lýsa hamunum sem ákvarða hvernig lagfæring á að líta út; MTU-talan sjálf er staðbundin mæling, ekki ráðlegging.