Git ngec në WSL2 përmes VPN: MTU e ndërfaqes apo rruga?

Kloni vërteton, numri i objekteve shfaqet dhe pastaj asgjë nuk lëviz për minuta. Windows raporton se VPN është i lidhur, emri i hostit zgjidhet dhe një shfletues në të njëjtën makinë merr të njëjtën faqe të depove pa vështirësi. Ky kombinim tregon madhësinë e paketës dhe jo kredencialet, dhe çështja e madhësisë duhet bërë në dy vende sepse WSL2 ka ndërfaqen e vet Linux me MTU-n e vet. Një numër i përket anës Windows të rrugës, tjetri shpërndarjes, dhe leximi vetëm i përshtatësit VPN lë gjysmën e rrugës pa u shqyrtuar.

Tre sinjale e ndajnë problemin e madhësisë nga të tjerat

Sinjali i parë është forma: vendosja e lidhjes dhe një shkëmbim i vogël ia dalin, pastaj transferimi masiv ndalon së përparuari. I dyti është simetria: i njëjti depo dhe i njëjti transport dështojnë ndërsa një host tjetër në të njëjtën rrugë funksionon, ose dështimi ndryshon me madhësinë e ngarkesës dhe jo me orën e ditës. I treti është heshtja: asnjë gabim vërtetimi, asnjë refuzim proxy, asnjë dështim zgjidhjeje emrash, vetëm një transferim që nuk përfundon kurrë.

Këta tre së bashku justifikojnë hipotezën e madhësisë së paketës. Një dështim DNS, një token i skaduar, një çelës SSH i refuzuar dhe një proxy që refuzon CONNECT prodhojnë secili gabimin e vet, dhe asnjëri nuk duket si ndalesë pas suksesit. Mbajtja e të njëjtit depo, transport dhe dritare kohore gjatë testimit është ajo që e bën krahasimin të ndershëm.

Krahasoni të dyja ndërfaqet përpara se të vendosni

Mblidhni pamjen e Windows dhe pamjen e Linux në të njëjtën sesion, dhe mbani adresën e depos në vend të hamendjes se cila ndërfaqe e mbart atë. Komanda më poshtë zgjidh fillimisht destinacionin, kështu që kërkimi i rrugës përshkruan serverin real me të cilin kontakton kloni, i cili mund të ndryshojë nga emri që shfaqi një shfletues. Xhironi të dyja gjysmat pranë njëra-tjetrës, sepse VPN mund të ndryshojë metrikat e ndërfaqes midis provave.

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

Xhironi gjysmën Linux brenda shpërndarjes në vend që ta ngjitni daljen në një shell Windows, sepse emrat e ndërfaqeve dhe zgjedhja e rrugës kanë kuptim vetëm atje. Një ngjitje nga një shell Windows raporton numrat e gabuar me besim të madh. Regjistroni pajisjen, rrugën e zgjedhur dhe MTU-në nga secila anë përpara se të ndryshoni çdo gjë.

Vendosni nëse numri duhet të jetë më i vogël

Një MTU e ndërfaqes më e madhe sesa rruga mund të mbajë nuk është automatikisht defekt, sepse zbulimi i MTU-së së rrugës ekziston pikërisht për këtë. Mënyra e dështimit shfaqet kur zbulimi shtypet: mesazhet ICMP filtrohen diku përgjatë rrugës, dërguesi nuk e mëson kurrë kufirin, dhe paketat e mëdha zhduken ndërsa të voglat kalojnë. Kjo është veti e rrugës, jo veti e Git. Është gjithashtu arsyeja pse një skedar i vogël mund të ketë sukses në një lidhje ku një i madh nuk përfundon kurrë.

Nëse provat e mbështesin, një ndryshim i përkohshëm në ndërfaqen Linux është testi më i lirë. Zgjidhni një vlerë nën madhësinë e përdorshme të rrugës, regjistroni të mëparshmen dhe mbani çdo gjë tjetër konstante që krahasimi të ketë kuptim. Nëse transferimi përfundon me vlerën më të vogël, keni një diagnozë dhe jo një rastësi.

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

Vendosni ku duhet të jetojë cilësimi

Nga testi dalin tre opsione, dhe zakonisht vetëm njëri prej tyre është i përshtatshëm. Nëse vlera më e vogël e rregullon transferimin dhe vlera është vërtet e nevojshme për këtë rrjet, cilësimi ka nevojë për një pronar të ciklit të jetës: një grep nisjeje në shpërndarje, një konfigurim rrjeti i menaxhuar nga platforma, ose një procedurë e dokumentuar. Nëse vlera nuk rregullon asgjë, kthejeni dhe kthehuni te pyetjet e transportit, proxy dhe vërtetimit.

Nëse ekziston një grep nisjeje varet nga versionet e Windows dhe WSL që përdoren dhe nga mënyra e rrjetit e konfiguruar. Pasqyrimi i rrjetit të Windows mund të ndryshojë mënyrën se si VPN ndërvepron me shpërndarjen, në mënyra që kanë më shumë rëndësi se një rregullim i MTU-së, prandaj identifikoni mënyrën përpara se të projektoni një zgjidhje anashkaluese për të. Një vlerë që i përshtatet një operatori ose një profili VPN nuk është parazgjedhje për atë tjetrin.

Ajo që duhet shmangur është vendosja joshëse: një komandë rrjeti e privilegjuar në skedarin e nisjes së çdo shell interaktiv, ose sudo pa fjalëkalim për të gjithë binarin ip që një skript të mund të ekzekutojë një rresht. Të dyja e kthejnë një diagnozë në ekspozim të përhershëm dhe e bëjnë problemin origjinal më të vështirë për t'u parë më vonë.

Verifikoni pas një nisjeje të pastër, pastaj kthejeni

Një ndryshim që zgjat vetëm derisa shpërndarja të rinisë nuk është rregullim. Rinisni shpërndarjen, rilidhni VPN dhe përsëritni operacionin origjinal Git në vend të një zëvendësuesi si ping ose një kërkesë e vogël HTTP. Pastaj konfirmoni që ndërfaqja mbart vlerën e synuar në sesionin e ri.

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

Mbani vlerën origjinale të regjistruar pranë ndryshimit që eksperimenti të mund të zhbëhet pastër, dhe vini re cila familje adresash u testua, sepse një rezultat IPv4 nuk thotë asgjë për një lidhje IPv6 në të njëjtin host. Dokumentacioni i rrjeteve të WSL përshkruan mënyrat që përcaktojnë si duhet të duket një rregullim; vetë numri i MTU-së është matje lokale, jo rekomandim.