Bumabara ang Git sa WSL2 sa VPN: MTU ng interface o ang ruta?
Nag-authenticate ang Git at pagkatapos ay bumabara sa WSL2? Ikumpara ang Linux interface sa Windows VPN adapter, subukan ang isang mas maliit na halaga, at planuhin ang buhay nito.
Nag-authenticate ang clone, lumilitaw ang bilang ng mga object, at pagkatapos ay walang gumagalaw nang ilang minuto. Iniulat ng Windows na konektado ang VPN, nare-resolve ang hostname, at ang browser sa parehong makina ay nakakakuha ng parehong pahina ng repository nang walang kahirapan. Ang kombinasyong iyon ay tumuturo sa laki ng packet at hindi sa mga kredensyal, at ang tanong ng laki ay dapat itanong sa dalawang lugar dahil may sariling Linux interface ang WSL2 na may sariling MTU. Ang isang numero ay pag-aari ng panig Windows ng ruta, ang isa ay ng distribusyon, at ang pagbasa lamang ng VPN adapter ay nag-iiwan ng kalahati ng ruta na hindi nasuri.
Tatlong senyales ang naghihiwalay ng problema sa laki mula sa iba
Ang unang senyales ay hugis: nagtagumpay ang pag-set up ng koneksyon at isang maliit na palitan, pagkatapos ay humihinto ang malaking paglilipat sa pag-usad. Ang pangalawa ay simetrya: nabigo ang parehong repository at parehong transport habang gumagana ang ibang host sa parehong ruta, o nagbabago ang kabiguan sa laki ng payload at hindi sa oras ng araw. Ang pangatlo ay katahimikan: walang error sa authentication, walang pagtanggi ng proxy, walang kabiguan sa resolution ng pangalan, isang paglilipat lamang na hindi natatapos.
Ang tatlong ito na magkakasama ay nagbibigay-katwiran sa hypothesis ng laki ng packet. Ang kabiguan ng DNS, isang token na nag-expire, isang tinanggihang SSH key at isang proxy na tumatanggi sa CONNECT ay gumagawa ng kani-kanilang error, at wala sa kanila ang mukhang paghinto pagkatapos ng tagumpay. Ang pagpapanatili ng parehong repository, transport at time window habang nagsubok ang siyang gumagawa sa paghahambing na tapat.
Ikumpara ang dalawang interface bago magpasya
Kolektahin ang pananaw ng Windows at pananaw ng Linux sa parehong session, at hawakan ang address ng repository sa halip na hulaan kung aling interface ang nagdadala nito. Ang utos sa ibaba ay nagre-resolve muna ng destinasyon upang ilarawan ng paghahanap ng ruta ang aktwal na server na kinokontak ng clone, na maaaring iba sa pangalang ipinakita ng browser. Patakbuhin ang dalawang kalahati nang malapit sa isa't isa, dahil maaaring baguhin ng VPN ang mga metric ng interface sa pagitan ng mga pagtatangka.
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"'
Patakbuhin ang kalahating Linux sa loob ng distribusyon sa halip na i-paste ang output sa isang Windows shell, dahil ang mga pangalan ng interface at pagpili ng ruta ay may kahulugan lamang doon. Ang paste mula sa Windows shell ay nag-uulat ng maling numero nang may malaking kumpiyansa. Itala ang device, napiling ruta at MTU mula sa bawat panig bago baguhin ang anuman.
Magpasya kung dapat mas maliit ang numero
Ang MTU ng interface na mas malaki kaysa kayang dalhin ng ruta ay hindi awtomatikong depekto, dahil ang pagtuklas ng MTU ng ruta ay umiiral para doon. Lumilitaw ang mode ng kabiguan kapag pinipigilan ang pagtuklas: sinasala ang mga mensaheng ICMP sa isang lugar sa ruta, hindi natututuhan ng nagpadala ang limitasyon, at nawawala ang malalaking packet habang dumadaan ang maliliit. Iyon ay katangian ng ruta, hindi katangian ng Git. Iyon din ang dahilan kung bakit maaaring magtagumpay ang maliit na file sa koneksyon kung saan hindi natatapos ang malaki.
Kung sinusuportahan ito ng ebidensya, ang pansamantalang pagbabago sa Linux interface ay ang pinakamurang pagsubok. Pumili ng halagang mas mababa sa magagamit na laki ng ruta, itala ang nauna, at panatilihing pare-pareho ang lahat ng iba upang may kahulugan ang paghahambing. Kung natapos ang paglilipat sa mas maliit na halaga, mayroon kang diagnosis at hindi pagkakataon.
ip -br link show dev eth0
sudo ip link set dev eth0 mtu 1380
ip -br link show dev eth0
Magpasya kung saan dapat manirahan ang setting
Tatlong opsyon ang sumusunod mula sa pagsubok, at kadalasan isa lamang ang angkop. Kung inaayos ng mas maliit na halaga ang paglilipat at talagang kailangan ang halaga para sa network na ito, kailangan ng setting ang may-ari ng lifecycle: isang start hook sa distribusyon, isang network configuration na pinamamahalaan ng platform, o isang dokumentadong pamamaraan. Kung wala itong inaayos, ibalik ito at bumalik sa mga tanong tungkol sa transport, proxy at authentication.
Kung may start hook ay nakasalalay sa mga bersyon ng Windows at WSL na ginagamit at sa na-configure na networking mode. Ang pag-mirror sa network ng Windows ay maaaring baguhin kung paano nakikipag-ugnayan ang VPN sa distribusyon sa mga paraang mas mahalaga kaysa sa pagsasaayos ng MTU, kaya tukuyin ang mode bago magdisenyo ng solusyon para rito. Ang halagang angkop sa isang operator o isang VPN profile ay hindi default para sa susunod.
Ang dapat iwasan ay ang mapang-akit na paglalagay: isang privileged network command sa startup file ng bawat interactive shell, o sudo na walang password para sa buong ip binary upang ang isang script ay makapagpatakbo ng isang linya. Ang dalawa ay ginagawang permanenteng pagkakalantad ang diagnosis at pinapahirapang makita ang orihinal na problema mamaya.
I-verify pagkatapos ng malinis na pagsisimula, pagkatapos ay ibalik
Ang pagbabagong tumatagal lamang hanggang mag-restart ang distribusyon ay hindi pag-aayos. I-restart ang distribusyon, muling ikonekta ang VPN, at ulitin ang orihinal na operasyon ng Git sa halip na kapalit tulad ng ping o maliit na HTTP request. Pagkatapos ay kumpirmahin na dinadala ng interface ang nilalayong halaga sa bagong session.
ip -br link show dev eth0
ip route get "$(getent ahostsv4 github.com | awk 'NR==1{print $1}')"
Panatilihin ang naitalang orihinal na halaga sa tabi ng pagbabago upang malinis na maibalik ang eksperimento, at itala kung aling pamilya ng address ang sinubukan, dahil walang sinasabi ang resulta ng IPv4 tungkol sa koneksyong IPv6 sa parehong host. Ang dokumentasyon ng networking ng WSL ay naglalarawan ng mga mode na tumutukoy kung ano ang dapat hitsura ng pag-aayos; ang numero ng MTU mismo ay lokal na pagsukat, hindi rekomendasyon.