Git stringa WSL2 su VPN: sąsajos MTU ar kelias?

Klonas autentifikuojasi, objektų skaičius pasirodo, o paskui kelias minutes niekas nejuda. Windows praneša, kad VPN prijungtas, pagrindinio kompiuterio vardas išsprendžiamas, o toje pačioje mašinoje esanti naršyklė be vargo gauna tą patį saugyklos puslapį. Šis derinys rodo paketo dydį, o ne prisijungimo duomenis, ir dydžio klausimą reikia kelti dviejose vietose, nes WSL2 turi savo Linux sąsają su savo MTU. Vienas skaičius priklauso Windows kelio pusei, kitas – distribucijai, o skaitant tik VPN adapterį pusė kelio lieka neišnagrinėta.

Trys signalai atskiria dydžio problemą nuo kitų

Pirmasis signalas yra forma: ryšio nustatymas ir mažas apsikeitimas pavyksta, tada masinis perdavimas nustoja judėti į priekį. Antrasis – simetrija: ta pati saugykla ir tas pats transportas nepavyksta, nors kitas to paties kelio kompiuteris veikia, arba gedimas kinta su naudingosios apkrovos dydžiu, o ne su paros laiku. Trečiasis – tyla: jokios autentifikacijos klaidos, jokio tarpinio serverio atmetimo, jokios vardų sprendimo klaidos, tik perdavimas, kuris niekada nepasibaigia.

Šie trys kartu pateisina paketo dydžio hipotezę. DNS gedimas, pasibaigęs žetonas, atmestas SSH raktas ir tarpinis serveris, atmetantis CONNECT, kiekvienas sukuria savo klaidą, ir nė vienas neatrodo kaip sustojimas po sėkmės. To paties saugyklos, transporto ir laiko lango išlaikymas bandymo metu yra tai, kas palyginimą daro sąžiningą.

Prieš nuspręsdami palyginkite abi sąsajas

Surinkite Windows vaizdą ir Linux vaizdą toje pačioje sesijoje ir laikykitės saugyklos adreso, o ne spėjimo, kuri sąsaja jį neša. Toliau pateikta komanda pirmiausia išsprendžia paskirties vietą, kad maršruto paieška apibūdintų tikrąjį serverį, su kuriuo jungiasi klonas, ir jis gali skirtis nuo vardo, kurį parodė naršyklė. Vykdykite abi puses netoli viena kitos, nes VPN tarp bandymų gali pakeisti sąsajos metrikas.

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

Linux pusę vykdykite distribucijos viduje, o ne įklijuokite išvestį į Windows apvalkalą, nes sąsajų pavadinimai ir maršruto pasirinkimas turi prasmę tik ten. Įklijuota išvestis iš Windows apvalkalo praneša neteisingus skaičius su dideliu pasitikėjimu. Prieš ką nors keisdami, užrašykite įrenginį, pasirinktą maršrutą ir MTU iš kiekvienos pusės.

Nuspręskite, ar skaičius turėtų būti mažesnis

Didesnis sąsajos MTU nei kelias gali pernešti nėra automatiškai defektas, nes kelio MTU aptikimas egzistuoja būtent tam. Gedimo režimas pasireiškia, kai aptikimas nuslopinamas: ICMP pranešimai filtruojami kažkur kelyje, siuntėjas niekada nesužino ribos, o dideli paketai dingsta, kol maži praeina. Tai kelio savybė, o ne Git savybė. Tai ir priežastis, kodėl mažas failas gali pavykti ryšyje, kuriame didelis niekada nepasibaigia.

Jei įrodymai tai pagrindžia, laikinas pakeitimas Linux sąsajoje yra pigiausias bandymas. Pasirinkite reikšmę, mažesnę už naudojamą kelio dydį, užrašykite ankstesnę ir palikite visa kita pastovu, kad palyginimas ką nors reikštų. Jei perdavimas baigiasi su mažesne reikšme, turite diagnozę, o ne sutapimą.

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

Nuspręskite, kur turėtų gyventi nustatymas

Iš bandymo išplaukia trys parinktys, ir paprastai tinka tik viena iš jų. Jei mažesnė reikšmė ištaiso perdavimą ir reikšmė tikrai reikalinga šiam tinklui, nustatymui reikia gyvavimo ciklo savininko: paleidimo kablio distribucijoje, platformos valdomos tinklo konfigūracijos arba dokumentuotos procedūros. Jei reikšmė nieko neištaiso, grąžinkite ją ir grįžkite prie transporto, tarpinio serverio ir autentifikacijos klausimų.

Ar paleidimo kablys egzistuoja, priklauso nuo naudojamų Windows ir WSL versijų ir sukonfigūruoto tinklo režimo. Windows tinklo atspindėjimas gali pakeisti, kaip VPN sąveikauja su distribucija, tokiais būdais, kurie svarbesni už MTU koregavimą, todėl nustatykite režimą prieš kurdami jam apėjimo sprendimą. Vienam operatoriui ar vienam VPN profiliui tinkanti reikšmė nėra numatytoji kitam.

Ko reikia vengti, tai viliojanti vieta: privilegijuota tinklo komanda kiekvieno interaktyvaus apvalkalo paleidimo faile arba slaptažodžio nereikalaujantis sudo visam ip dvejetainiam failui, kad scenarijus galėtų įvykdyti vieną eilutę. Abu diagnozę paverčia nuolatine ekspozicija ir apsunkina pradinės problemos pastebėjimą vėliau.

Patikrinkite po švaraus paleidimo, tada atgręžkite

Pakeitimas, kuris išlieka tik iki distribucijos paleidimo iš naujo, nėra pataisa. Paleiskite distribuciją iš naujo, vėl prijunkite VPN ir pakartokite pradinę Git operaciją, o ne pakaitalą, pavyzdžiui, ping ar mažą HTTP užklausą. Tada patvirtinkite, kad naujoje sesijoje sąsaja neša numatytą reikšmę.

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

Užrašytą pradinę reikšmę laikykite prie pakeitimo, kad eksperimentą būtų galima švariai atšaukti, ir pažymėkite, kuri adresų šeima buvo testuota, nes IPv4 rezultatas nieko nesako apie IPv6 ryšį tame pačiame kompiuteryje. WSL tinklų dokumentacija aprašo režimus, kurie nustato, kaip turėtų atrodyti pataisa; pats MTU skaičius yra vietinis matavimas, o ne rekomendacija.