Git haltas en WSL2 ĉe VPN: interfaca MTU aŭ la vojo?

La klono aŭtentikigas, la objekta nombro aperas, kaj poste nenio moviĝas dum minutoj. Windows raportas la VPN kiel konektitan, la hostnomo solviĝas, kaj retumilo sur la sama maŝino elŝutas la saman deponejan paĝon sen malfacilaĵo. Tiu kombinaĵo montras al paketa grandeco anstataŭ al akreditiloj, kaj la grandeca demando devas esti demandita du lokoj, ĉar WSL2 havas sian propran Linux-interfacon kun sia propra MTU. Unu nombro apartenas al la Windows-flanko de la vojo, la alia al la distribuo, kaj legi nur la VPN-adaptilon lasas duonon de la vojo nesplorita.

Tri signaloj apartigas grandecan problemon de alio

La unua signalo estas formo: konekta starigo kaj malgranda interŝanĝo sukcesas, poste la amasa transigo ĉesas progresi. La dua estas simetrio: la sama deponejo kaj la sama transporto malsukcesas dum alia gastiganto sur la sama vojo funkcias, aŭ la malsukceso ŝanĝiĝas kun la utilŝarĝa grandeco anstataŭ kun la horo de la tago. La tria estas silento: neniu aŭtentikiga eraro, neniu prokura rifuzo, neniu nomreza malsukceso, nur transigo kiu neniam finiĝas.

Tiuj tri kune pravigas hipotezon pri paketa grandeco. DNS-malsukceso, eksvalidiĝinta ĵetono, rifuzita SSH-ŝlosilo kaj prokuro kiu rifuzas CONNECT ĉiu produktas sian propran eraron, kaj neniu el ili aspektas kiel halto post sukceso. Teni la saman deponejon, transporton kaj tempan fenestron dum testado estas tio, kio faras la komparon honesta.

Komparu ambaŭ interfacojn antaŭ ol decidi

Kolektu la Windows-vidon kaj la Linux-vidon en la sama sesio, kaj tenu la adreson de la deponejo anstataŭ konjekton pri tio, kiu interfaco portas ĝin. La suba komando unue solvas la celon, por ke la voja serĉo priskribu la efektivan servilon, kiun la klono kontaktas, kiu povas diferenci de la nomo, kiun retumilo montris. Rulu ambaŭ duonojn proksime unu al la alia, ĉar la VPN povas ŝanĝi interfacajn metrikojn inter provoj.

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

Rulu la Linux-duonon ene de la distribuo anstataŭ enmeti la eligon en Windows-ŝelon, ĉar la interfacaj nomoj kaj voja elekto havas sencon nur tie. Enmeto el Windows-ŝelo raportas la malĝustajn nombrojn kun granda memfido. Notu la aparaton, la elektitan vojon kaj la MTU de ĉiu flanko antaŭ ol ŝanĝi ion.

Decidu, ĉu la nombro devus esti pli malgranda

Pli granda interfaca MTU ol la vojo povas porti ne estas aŭtomate difekto, ĉar la malkovro de voja MTU ekzistas ĝuste por tio. La fiaska reĝimo aperas kiam la malkovro estas subpremita: ICMP-mesaĝoj estas filtritaj ie survoje, la sendinto neniam lernas la limon, kaj grandaj pakaĵoj malaperas dum malgrandaj sukcesas. Tio estas eco de la vojo, ne eco de Git. Ĝi estas ankaŭ la kialo, kial malgranda dosiero povas sukcesi sur konekto, kie granda neniam finiĝas.

Se la pruvoj subtenas ĝin, provizora ŝanĝo sur la Linux-interfaco estas la plej malmultekosta testo. Elektu valoron sub la uzebla voja grandeco, notu la antaŭan, kaj tenu ĉion alian konstantan por ke la komparo signifu ion. Se la transigo finiĝas ĉe la pli malgranda valoro, vi havas diagnozon anstataŭ koincidon.

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

Decidu, kie la agordo devus loĝi

El la testo sekvas tri opcioj, kaj kutime nur unu el ili taŭgas. Se la pli malgranda valoro riparas la transigon kaj la valoro vere necesas por ĉi tiu reto, la agordo bezonas posedanton de la vivociklo: startan hokon en la distribuo, retan agordon administrata de la platformo, aŭ dokumentitan proceduron. Se la valoro riparas nenion, restarigu ĝin kaj revenu al la demandoj pri transporto, prokuro kaj aŭtentikigo.

Ĉu ekzistas starta hoko dependas de la uzataj Windows- kaj WSL-versioj kaj de la agordita reta reĝimo. Spegulado de la Windows-reto povas ŝanĝi kiel VPN interagas kun la distribuo en manieroj, kiuj gravas pli ol MTU-ĝustigo, do identigu la reĝimon antaŭ ol desegni provizoran solvon por ĝi. Valoro, kiu taŭgas por unu funkciigisto aŭ unu VPN-profilon, ne estas defaŭlto por la sekva.

Kion eviti estas la tentiga lokigo: privilegia reta komando en la starta dosiero de ĉiu interaga ŝelo, aŭ sudo senpasvorta por la tuta ip binara dosiero por ke skripto povu ruli unu linion. Ambaŭ igas diagnozon daŭra eksponiĝo kaj igas la originan problemon pli malfacila videbla poste.

Kontrolu post freŝa starto, poste restarigu

Ŝanĝo, kiu postvivas nur ĝis la distribuo restartos, ne estas riparo. Restartu la distribuon, rekonektu la VPN, kaj ripetu la originan Git-operacion anstataŭ anstataŭaĵon kiel ping aŭ malgranda HTTP-peto. Poste konfirmu, ke la interfaco portas la celitan valoron en la nova sesio.

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

Tenu la notitan originan valoron apud la ŝanĝo, por ke la eksperimento povu esti malfarita pure, kaj notu, kiun adresan familion vi testis, ĉar IPv4-rezulto diras nenion pri IPv6-konekto sur la sama gastiganto. La WSL-reta dokumentaro priskribas la reĝimojn, kiuj determinas kiel riparo devus aspekti; la MTU-nombro mem estas loka mezuro, ne rekomendo.