Git iestrēgst WSL2 ar VPN: saskarnes MTU vai ceļš?

Klons autentificējas, parādās objektu skaits, un pēc tam vairākas minūtes nekas nekustas. Windows ziņo, ka VPN ir savienots, resursdatora vārds tiek atrisināts, un pārlūks tajā pašā mašīnā bez grūtībām iegūst to pašu repozitorija lapu. Šī kombinācija norāda uz paketes izmēru, nevis akreditācijas datiem, un izmēra jautājums ir jāuzdod divās vietās, jo WSL2 ir sava Linux saskarne ar savu MTU. Viens skaitlis pieder ceļa Windows pusei, otrs distribūcijai, un lasot tikai VPN adapteri, puse ceļa paliek neizpētīta.

Trīs signāli atdala izmēra problēmu no citām

Pirmais signāls ir forma: savienojuma izveide un neliela apmaiņa izdodas, pēc tam lielapjoma pārsūtīšana pārstāj virzīties uz priekšu. Otrais ir simetrija: tas pats repozitorijs un tas pats transports neizdodas, kamēr cits resursdators tajā pašā ceļā darbojas, vai arī kļūme mainās līdz ar kravnesības izmēru, nevis ar diennakts laiku. Trešais ir klusums: nav autentifikācijas kļūdas, nav starpniekservera atteikuma, nav nosaukumu atrisināšanas kļūmes, tikai pārsūtīšana, kas nekad nebeidzas.

Šie trīs kopā attaisno paketes izmēra hipotēzi. DNS kļūme, novecojis tokens, noraidīta SSH atslēga un starpniekserveris, kas atsaka CONNECT, katrs rada savu kļūdu, un neviens no tiem neizskatās kā apstāšanās pēc panākumiem. Tā paša repozitorija, transporta un laika loga saglabāšana testēšanas laikā ir tas, kas padara salīdzinājumu godīgu.

Pirms lēmuma salīdziniet abas saskarnes

Apkopojiet Windows skatu un Linux skatu vienā sesijā un turiet repozitorija adresi, nevis miniet, kura saskarne to nes. Tālāk dotā komanda vispirms atrisina galamērķi, lai maršruta meklēšana aprakstītu faktisko serveri, ar kuru klons sazinās, un tas var atšķirties no nosaukuma, ko parādīja pārlūks. Palaidiet abas puses tuvu vienu otrai, jo VPN starp mēģinājumiem var mainīt saskarnes 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 pusi palaidiet distribūcijas iekšienē, nevis ielīmējiet izvadi Windows čaulā, jo saskarņu nosaukumiem un maršruta izvēlei jēga ir tikai tur. Ielīmēta izvade no Windows čaulas ziņo nepareizus skaitļus ar lielu pārliecību. Pirms kaut ko mainīt, pierakstiet ierīci, izvēlēto maršrutu un MTU no katras puses.

Izlemiet, vai skaitlim jābūt mazākam

Lielāks saskarnes MTU nekā ceļš spēj pārnest nav automātiski defekts, jo ceļa MTU atklāšana pastāv tieši tam. Kļūmes režīms parādās, kad atklāšana tiek nomākta: ICMP ziņojumi tiek filtrēti kaut kur ceļā, sūtītājs nekad neuzzina ierobežojumu, un lielās paketes pazūd, kamēr mazās iziet. Tas ir ceļa īpašība, nevis Git īpašība. Tas ir arī iemesls, kāpēc maza datne var izdoties savienojumā, kur liela nekad nebeidzas.

Ja pierādījumi to atbalsta, īslaicīga izmaiņa Linux saskarnē ir lētākais tests. Izvēlieties vērtību zem izmantojamā ceļa lieluma, pierakstiet iepriekšējo un turiet visu pārējo nemainīgu, lai salīdzinājumam būtu jēga. Ja pārsūtīšana pabeidzas ar mazāko vērtību, jums ir diagnoze, nevis nejaušība.

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

Izlemiet, kur iestatījumam jādzīvo

No testa izriet trīs iespējas, un parasti piemērota ir tikai viena no tām. Ja mazākā vērtība salabo pārsūtīšanu un vērtība šim tīklam patiešām ir vajadzīga, iestatījumam vajadzīgs dzīves cikla īpašnieks: palaišanas āķis distribūcijā, platformas pārvaldīta tīkla konfigurācija vai dokumentēta procedūra. Ja vērtība neko nelabo, atgrieziet to un atgriezieties pie transporta, starpniekservera un autentifikācijas jautājumiem.

Tas, vai palaišanas āķis pastāv, ir atkarīgs no izmantotajām Windows un WSL versijām un konfigurētā tīkla režīma. Windows tīkla atspoguļošana var mainīt to, kā VPN mijiedarbojas ar distribūciju, tādos veidos, kas ir svarīgāki par MTU pielāgošanu, tāpēc nosakiet režīmu pirms apiešanas risinājuma projektēšanas. Vērtība, kas der vienam operatoram vai vienam VPN profilam, nav noklusējums nākamajam.

No kā izvairīties, ir vilinošais izvietojums: privileģēta tīkla komanda katras interaktīvās čaulas palaišanas failā, vai sudo bez paroles visai ip binārajai datnei, lai skripts varētu izpildīt vienu rindu. Abi pārvērš diagnozi pastāvīgā pakļautībā un padara sākotnējo problēmu vēlāk grūtāk saskatāmu.

Pārbaudiet pēc tīras palaišanas, pēc tam atgrieziet

Izmaiņa, kas saglabājas tikai līdz distribūcijas restartam, nav labojums. Restartējiet distribūciju, atkārtoti pievienojiet VPN un atkārtojiet sākotnējo Git darbību, nevis aizstājēju, piemēram, ping vai mazu HTTP pieprasījumu. Pēc tam apstipriniet, ka jaunajā sesijā saskarne nes paredzēto vērtību.

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

Pierakstīto sākotnējo vērtību turiet blakus izmaiņai, lai eksperimentu varētu tīri atsaukt, un atzīmējiet, kura adrešu saime tika testēta, jo IPv4 rezultāts neko nepasaka par IPv6 savienojumu tajā pašā resursdatorā. WSL tīklu dokumentācija apraksta režīmus, kas nosaka, kā jāizskatās labojumam; pats MTU skaitlis ir vietējs mērījums, nevis ieteikums.