Git juuttuu WSL2:ssa VPN:n yli: liitännän MTU vai polku?
Git todentaa ja jää sitten jumiin WSL2:ssa? Vertaa Linuxin liitäntää Windowsin VPN-sovittimeen, kokeile yhtä pienempää arvoa ja suunnittele sen elinkaari.
Klooni todentaa, objektien määrä ilmestyy, ja sitten mikään ei liiku minuutteihin. Windows ilmoittaa VPN:n yhdistetyksi, isäntänimi selvitetään, ja samalla koneella oleva selain noutaa saman repositoriosivun vaikeuksitta. Yhdistelmä viittaa paketin kokoon eikä tunnistetietoihin, ja kokokysymys on esitettävä kahdessa paikassa, koska WSL2:lla on oma Linux-liitäntänsä ja oma MTU. Yksi luku kuuluu polun Windows-puolelle, toinen jakelulle, ja vain VPN-sovittimen lukeminen jättää puolet polusta tutkimatta.
Kolme signaalia erottavat kokoprobleeman muusta
Ensimmäinen signaali on muoto: yhteyden muodostus ja pieni vaihto onnistuvat, sitten massansiirto lakkaa edistymästä. Toinen on symmetria: sama repositorio ja sama siirtotie epäonnistuvat, kun taas toinen isäntä samalla polulla toimii, tai vika vaihtuu hyötykuorman koon mukaan eikä vuorokaudenajan mukaan. Kolmas on hiljaisuus: ei todennusvirhettä, ei välityspalvelimen hylkäystä, ei nimien selvityksen epäonnistumista, vain siirto, joka ei koskaan valmistu.
Nämä kolme yhdessä oikeuttavat paketin kokoa koskevan hypoteesin. DNS-vika, vanhentunut token, hylätty SSH-avain ja CONNECTin hylkäävä välityspalvelin tuottavat kukin oman virheensä, eikä mikään niistä näytä onnistumisen jälkeiseltä pysähdykseltä. Saman repositorion, siirtotien ja aikaikkunan säilyttäminen testattaessa tekee vertailusta rehellisen.
Vertaa molempia liitäntöjä ennen päätöstä
Kerää Windows-näkymä ja Linux-näkymä samassa istunnossa ja pidä kiinni repositorion osoitteesta sen sijaan, että arvaisit, mikä liitäntä sitä kantaa. Alla oleva komento selvittää ensin kohteen, jotta reittihaku kuvaa varsinaisen palvelimen, johon klooni ottaa yhteyttä, ja se voi poiketa selaimen näyttämästä nimestä. Aja molemmat puoliskot lähekkäin, koska VPN voi muuttaa liitännän mittareita yritysten välillä.
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"'
Aja Linux-puolisko jakelun sisällä sen sijaan, että liittäisit tulosteen Windows-kuoreen, sillä liitäntöjen nimet ja reitin valinta ovat järkeviä vain siellä. Windows-kuoresta liitetty tuloste ilmoittaa väärät luvut suurella varmuudella. Kirjaa laite, valittu reitti ja MTU kummaltakin puolelta ennen kuin muutat mitään.
Päätä, pitäisikö luvun olla pienempi
Suurempi liitännän MTU kuin polku pystyy kantamaan ei ole automaattisesti vika, koska polun MTU:n selvitys on olemassa juuri sitä varten. Vikatila ilmenee, kun selvitys tukahdutetaan: ICMP-viestit suodatetaan jossain matkan varrella, lähettäjä ei koskaan opi rajaa, ja suuret paketit katoavat pienten mennessä läpi. Se on polun ominaisuus, ei Gitin ominaisuus. Se on myös syy siihen, miksi pieni tiedosto voi onnistua yhteydellä, jolla suuri ei koskaan valmistu.
Jos todisteet tukevat sitä, väliaikainen muutos Linux-liitännässä on halvin testi. Valitse arvo käytettävissä olevan polun koon alapuolelta, kirjaa edellinen ja pidä kaikki muu vakiona, jotta vertailu merkitsee jotain. Jos siirto valmistuu pienemmällä arvolla, sinulla on diagnoosi eikä sattuma.
ip -br link show dev eth0
sudo ip link set dev eth0 mtu 1380
ip -br link show dev eth0
Päätä, missä asetuksen pitäisi elää
Testistä seuraa kolme vaihtoehtoa, ja yleensä vain yksi niistä on sopiva. Jos pienempi arvo korjaa siirron ja arvo on todella tarpeen tälle verkolle, asetus tarvitsee elinkaaren omistajan: käynnistyskoukun jakelussa, alustan hallinnoiman verkkokokoonpanon tai dokumentoidun menettelyn. Jos arvo ei korjaa mitään, palauta se ja palaa siirtotien, välityspalvelimen ja todentamisen kysymyksiin.
Käynnistyskoukun olemassaolo riippuu käytössä olevista Windows- ja WSL-versioista ja määritetystä verkkotilasta. Windowsin verkon peilaaminen voi muuttaa sitä, miten VPN on vuorovaikutuksessa jakelun kanssa tavoilla, jotka merkitsevät enemmän kuin MTU-säätö, joten tunnista tila ennen kuin suunnittelet sille kiertoratkaisun. Yhdelle operaattorille tai yhdelle VPN-profiilille sopiva arvo ei ole oletus seuraavalle.
Sitä on vältettävä, mikä on houkutteleva sijoitus: etuoikeutettu verkkokomento jokaisen interaktiivisen kuoren käynnistystiedostossa tai salasanaton sudo koko ip-binäärille, jotta skripti voi ajaa yhden rivin. Molemmat muuttavat diagnoosin pysyväksi altistukseksi ja tekevät alkuperäisestä ongelmasta myöhemmin vaikeamman nähdä.
Vahvista puhtaan käynnistyksen jälkeen ja peru sitten
Muutos, joka kestää vain jakelun uudelleenkäynnistykseen, ei ole korjaus. Käynnistä jakelu uudelleen, yhdistä VPN uudelleen ja toista alkuperäinen Git-toiminto sen sijaan, että käyttäisit korviketta kuten ping tai pientä HTTP-pyyntöä. Vahvista sitten, että liitäntä kantaa aiottua arvoa uudessa istunnossa.
ip -br link show dev eth0
ip route get "$(getent ahostsv4 github.com | awk 'NR==1{print $1}')"
Pidä kirjattu alkuperäinen arvo muutoksen vieressä, jotta kokeilu voidaan peruuttaa puhtaasti, ja merkitse, mitä osoiteperhettä testattiin, koska IPv4-tulos ei kerro mitään IPv6-yhteydestä samalla isännällä. WSL:n verkkodokumentaatio kuvaa tilat, jotka määräävät, miltä korjauksen pitäisi näyttää; MTU-luku itsessään on paikallinen mittaus, ei suositus.