Git stopper i WSL2 over VPN: interface-MTU eller ruten?

Klonen autentiserer, objektantallet vises, og deretter beveger ingenting seg på flere minutter. Windows rapporterer VPN som tilkoblet, vertsnavnet løses opp, og en nettleser på samme maskin henter den samme repositorisiden uten vanskeligheter. Kombinasjonen peker på pakkestørrelse fremfor på legitimasjon, og størrelsesspørsmålet må stilles på to steder fordi WSL2 har sitt eget Linux-grensesnitt med sin egen MTU. Det ene tallet tilhører Windows-siden av ruten, det andre distribusjonen, og å lese bare VPN-adapteren lar halve ruten stå uundersøkt.

Tre signaler skiller et størrelsesproblem fra noe annet

Det første signalet er formen: tilkoblingsoppsett og en liten utveksling lykkes, deretter slutter den store overføringen å gjøre fremgang. Det andre er symmetri: samme repositorium og samme transport feiler mens en annen vert på samme rute virker, eller feilen endrer seg med nyttelastens størrelse og ikke med tiden på dagen. Det tredje er stillhet: ingen autentiseringsfeil, ingen proxyavvisning, ingen navneoppløsningsfeil, bare en overføring som aldri fullføres.

De tre sammen rettferdiggjør en hypotese om pakkestørrelse. En DNS-feil, et utløpt token, en avvist SSH-nøkkel og en proxy som avviser CONNECT gir hver sin feil, og ingen av dem ser ut som en stopp etter suksess. Å beholde samme repositorium, transport og tidsvindu under testingen er det som gjør sammenligningen ærlig.

Sammenlign begge grensesnittene før du bestemmer deg

Samle Windows-visningen og Linux-visningen i samme økt, og hold på adressen til repositoriet i stedet for å gjette hvilket grensesnitt som bærer det. Kommandoen nedenfor løser først opp målet slik at ruteoppslaget beskriver den faktiske serveren klonen kontakter, som kan avvike fra navnet en nettleser viste. Kjør begge halvdelene tett etter hverandre, fordi VPN kan endre grensesnittmetrikker 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"'

Kjør Linux-halvdelen inne i distribusjonen i stedet for å lime utdataene inn i et Windows-skal, siden grensesnittnavn og rutevalg bare gir mening der. En innliming fra et Windows-skal rapporterer de gale tallene med stor selvsikkerhet. Noter enheten, den valgte ruten og MTU-en fra hver side før du endrer noe.

Avgjør om tallet bør være mindre

En større grensesnitt-MTU enn ruten kan bære er ikke automatisk en feil, fordi oppdagelse av rute-MTU finnes nettopp for det. Feilmodusen oppstår når oppdagelsen undertrykkes: ICMP-meldinger filtreres et sted på veien, avsenderen lærer aldri grensen, og store pakker forsvinner mens små slipper gjennom. Det er en egenskap ved ruten, ikke ved Git. Det er også grunnen til at en liten fil kan lykkes på en forbindelse der en stor aldri fullføres.

Hvis bevisene støtter det, er en midlertidig endring på Linux-grensesnittet den billigste testen. Velg en verdi under den brukbare rutestørrelsen, noter den forrige, og hold alt annet konstant slik at sammenligningen betyr noe. Hvis overføringen fullføres med den mindre verdien, har du en diagnose og ikke en tilfeldighet.

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

Avgjør hvor innstillingen skal bo

Tre alternativer følger av testen, og vanligvis er bare ett av dem passende. Hvis den mindre verdien retter overføringen og verdien virkelig er nødvendig for dette nettverket, trenger innstillingen en eier av livssyklusen: en oppstartskrok i distribusjonen, en nettverkskonfigurasjon styrt av plattformen eller en dokumentert prosedyre. Hvis verdien ikke retter noe, rull den tilbake og gå tilbake til spørsmålene om transport, proxy og autentisering.

Om det finnes en oppstartskrok avhenger av Windows- og WSL-versjonene som brukes og av nettverksmodusen som er konfigurert. Speiling av Windows-nettverket kan endre hvordan en VPN samhandler med distribusjonen på måter som betyr mer enn en MTU-justering, så identifiser modusen før du designer en midlertidig løsning for den. En verdi som passer for én tilbyder eller én VPN-profil er ikke en standard for den neste.

Det som må unngås er den fristende plasseringen: en privilegert nettverkskommando i oppstartsfilen til hvert interaktive skall, eller passordfri sudo for hele ip-binæren slik at et skript kan kjøre én linje. Begge gjør en diagnose til permanent eksponering og gjør det opprinnelige problemet vanskeligere å se senere.

Verifiser etter en frisk start, og rull deretter tilbake

En endring som bare varer til distribusjonen starter på nytt, er ikke en retting. Start distribusjonen på nytt, koble VPN til igjen, og gjenta den opprinnelige Git-operasjonen i stedet for en erstatning som ping eller en liten HTTP-forespørsel. Bekreft deretter at grensesnittet bærer den tiltenkte verdien i den nye økten.

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

Hold den noterte opprinnelige verdien ved siden av endringen slik at eksperimentet kan angres rent, og noter hvilken adressefamilie som ble testet, fordi et IPv4-resultat ikke sier noe om en IPv6-forbindelse på samme vert. WSLs nettverksdokumentasjon beskriver modusene som bestemmer hvordan en retting skal se ut; selve MTU-tallet er en lokal måling, ikke en anbefaling.