Git stoggar i WSL2 over VPN: interface-MTU eller ruta?

Klonen autentiserer, objektalet dukkar opp, og deretter rører ingenting seg på fleire minutt. Windows rapporterer VPN som tilkopla, vertsnamnet blir løyst opp, og ein nettlesar på same maskin hentar den same repositorisida utan vanskar. Kombinasjonen peikar på pakkestorleik framfor på legitimasjon, og storleiksspørsmålet må stillast på to stader fordi WSL2 har sitt eige Linux-grensesnitt med sin eigen MTU. Det eine talet høyrer til Windows-sida av ruta, det andre til distribusjonen, og å lese berre VPN-adapteren lèt halve ruta stå uundersøkt.

Tre signal skil eit storleiksproblem frå noko anna

Det første signalet er forma: tilkoplingsoppsett og ei lita utveksling lukkast, deretter sluttar den store overføringa å gjere framgang. Det andre er symmetri: same repositorium og same transport feilar medan ein annan vert på same rute verkar, eller feilen endrar seg med nyttelaststorleiken og ikkje med tida på dagen. Det tredje er stillheit: ingen autentiseringsfeil, inga proxyavvising, ingen namneoppløysingsfeil, berre ei overføring som aldri blir fullført.

Dei tre saman rettferdiggjer ein hypotese om pakkestorleik. Ein DNS-feil, eit utlope token, ein avvist SSH-nøkkel og ein proxy som avviser CONNECT gir kvar sin feil, og ingen av dei ser ut som ein stopp etter suksess. Å halde same repositorium, transport og tidsvindauge under testinga er det som gjer samanlikninga ærleg.

Samanlikn begge grensesnitta før du bestemmer deg

Samle Windows-visninga og Linux-visninga i same økt, og hald på adressa til repositoriet i staden for å gjette kva grensesnitt som ber det. Kommandoen nedanfor løyser først opp målet slik at ruteoppslaget skildrar den faktiske tenaren klonen kontaktar, som kan avvike frå namnet ein nettlesar viste. Køyr begge halvdelane tett etter kvarandre, fordi VPN kan endre grensesnittmetrikkar mellom forsøk.

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

Køyr Linux-halvdelen inne i distribusjonen i staden for å lime utdata inn i eit Windows-skal, sidan grensesnittnamn og ruteval berre gir meining der. Ei innliming frå eit Windows-skal rapporterer dei gale tala med stor sjølvtillit. Noter eininga, den valde ruta og MTU-en frå kvar side før du endrar noko.

Avgjer om talet bør vere mindre

Ein større grensesnitt-MTU enn ruta kan bere er ikkje automatisk ein feil, fordi oppdaging av rute-MTU finst nettopp for det. Feilmodusen oppstår når oppdaginga blir undertrykt: ICMP-meldingar blir filtrerte ein stad på vegen, avsendaren lærer aldri grensa, og store pakkar forsvinn medan små slepp gjennom. Det er ein eigenskap ved ruta, ikkje ved Git. Det er også grunnen til at ei lita fil kan lukkast på ei samband der ei stor aldri blir fullført.

Viss prova støttar det, er ei mellombels endring på Linux-grensesnittet den billegaste testen. Vel ein verdi under den brukbare rutestorleiken, noter den førre, og hald alt anna konstant slik at samanlikninga betyr noko. Viss overføringa blir fullført med den mindre verdien, har du ein diagnose og ikkje eit tilfelle.

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

Avgjer kvar innstillinga skal bu

Tre alternativ følgjer av testen, og vanlegvis er berre eitt av dei høveleg. Viss den mindre verdien rettar overføringa og verdien verkeleg er naudsynt for dette nettet, treng innstillinga ein eigar av livssyklusen: ein oppstartskrok i distribusjonen, ein nettverkskonfigurasjon styrt av plattforma eller ein dokumentert prosedyre. Viss verdien ikkje rettar noko, rull han tilbake og gå tilbake til spørsmåla om transport, proxy og autentisering.

Om det finst ein oppstartskrok avheng av Windows- og WSL-versjonane som blir brukte og av nettverksmodusen som er konfigurert. Spegling av Windows-nettet kan endre korleis ein VPN samhandlar med distribusjonen på måtar som betyr meir enn ei MTU-justering, så identifiser modusen før du designar ei mellombels løysing for han. Ein verdi som passar for éin tilbydar eller éin VPN-profil er ikkje ein standard for den neste.

Det som må unngåast er den freistande plasseringa: ein privilegert nettverkskommando i oppstartsfila til kvar interaktive skal, eller passordfri sudo for heile ip-binæra slik at eit skript kan køyre éi linje. Begge gjer ein diagnose til permanent eksponering og gjer det opphavlege problemet vanskelegare å sjå seinare.

Verifiser etter ein frisk start, og rull deretter tilbake

Ei endring som berre varer til distribusjonen startar på nytt, er ikkje ei retting. Start distribusjonen på nytt, kople VPN til igjen, og gjenta den opphavlege Git-operasjonen i staden for ein erstatning som ping eller ei lita HTTP-førespurnad. Stadfest deretter at grensesnittet ber den tiltenkte verdien i den nye økta.

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

Hald den noterte opphavlege verdien ved sida av endringa slik at eksperimentet kan gjerast om gjort reint, og noter kva adressefamilie som vart testa, fordi eit IPv4-resultat ikkje seier noko om ei IPv6-samband på same vert. WSL sin nettverksdokumentasjon skildrar modusane som avgjer korleis ei retting skal sjå ut; sjølve MTU-talet er ei lokal måling, ikkje ei tilråding.