Git i WSL2 går i stå på en VPN: interface-MTU eller ruten?

Klonen godkender, objektantallet vises, og derefter flytter intet sig i minutter. Windows rapporterer VPN som forbundet, værtsnavnet opløses, og en browser på samme maskine henter samme repositoriumsside uden problemer. Kombinationen peger på pakkestørrelse frem for legitimationsoplysninger, og størrelsesspørgsmålet skal stilles to steder, fordi WSL2 har sit eget Linux-interface med sin egen MTU. Det ene tal hører til Windows-siden af ruten, det andet til distributionen, og at læse kun VPN-adapteren efterlader halvdelen af ruten uundersøgt.

Tre signaler adskiller et størrelsesproblem fra noget andet

Det første signal er formen: forbindelsesopsætning og en lille udveksling lykkes, derefter stopper den store overførsel med at gøre fremskridt. Det andet er symmetri: samme repositorium og samme transport fejler, mens en anden vært på samme rute virker, eller fejlen ændrer sig med nyttelastens størrelse frem for med tidspunktet på dagen. Det tredje er tavshed: ingen godkendelsesfejl, ingen proxyafvisning, ingen navneopløsningsfejl, blot en overførsel, der aldrig fuldføres.

De tre tilsammen retfærdiggør en hypotese om pakkestørrelse. En DNS-fejl, et udløbet token, en afvist SSH-nøgle og en proxy, der afviser CONNECT, giver hver deres fejl, og ingen af dem ligner et stop efter succes. At bevare samme repositorium, transport og tidsvindue under testen er det, der gør sammenligningen ærlig.

Sammenlign begge interfaces, før du beslutter

Indsaml Windows-visningen og Linux-visningen i samme session, og hold fast i repositoriets adresse i stedet for et gæt på, hvilket interface der bærer den. Kommandoen nedenfor opløser først destinationen, så ruteopslaget beskriver den faktiske server, klonen kontakter, som kan afvige fra det navn, en browser viste. Kør begge halvdele tæt på hinanden, fordi VPN kan ændre interface-metrikker mellem forsøg.

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ør Linux-halvdelen inde i distributionen i stedet for at indsætte outputtet i en Windows-shell, da interfacenavne og rutevalg kun giver mening der. En indsættelse fra en Windows-shell rapporterer de forkerte tal med stor selvsikkerhed. Notér enheden, den valgte rute og MTU'en fra hver side, før du ændrer noget.

Beslut, om tallet bør være mindre

En større interface-MTU, end ruten kan bære, er ikke automatisk en fejl, fordi opdagelse af rute-MTU findes netop til det. Fejltilstanden opstår, når opdagelsen undertrykkes: ICMP-beskeder filtreres et sted på vejen, afsenderen lærer aldrig grænsen, og store pakker forsvinder, mens små slipper igennem. Det er en egenskab ved ruten, ikke ved Git. Det er også grunden til, at en lille fil kan lykkes på en forbindelse, hvor en stor aldrig fuldføres.

Hvis beviserne understøtter det, er en midlertidig ændring på Linux-interfacet den billigste test. Vælg en værdi under den brugbare rutestørrelse, notér den forrige, og hold alt andet konstant, så sammenligningen betyder noget. Hvis overførslen fuldføres ved den mindre værdi, har du en diagnose i stedet for en tilfældighed.

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

Beslut, hvor indstillingen skal bo

Tre muligheder følger af testen, og kun én af dem er sædvanligvis passende. Hvis den mindre værdi retter overførslen, og værdien virkelig er nødvendig for dette netværk, har indstillingen brug for en ejer af livscyklussen: et opstartshook i distributionen, en netværkskonfiguration styret af platformen eller en dokumenteret procedure. Hvis værdien ikke retter noget, skal du rulle den tilbage og vende tilbage til spørgsmålene om transport, proxy og godkendelse.

Om der findes et opstartshook afhænger af de anvendte Windows- og WSL-versioner og af den konfigurerede netværkstilstand. Spejling af Windows-netværket kan ændre, hvordan en VPN interagerer med distributionen på måder, der betyder mere end en MTU-justering, så identificér tilstanden, før du designer en midlertidig løsning til den. En værdi, der passer til én udbyder eller én VPN-profil, er ikke en standard for den næste.

Det, der skal undgås, er den fristende placering: en privilegeret netværkskommando i hver interaktiv shells opstartsfil eller adgangskodefri sudo til hele ip-binæren, så et script kan køre én linje. Begge gør en diagnose til permanent eksponering og gør det oprindelige problem sværere at se senere.

Bekræft efter en frisk start, og rul derefter tilbage

En ændring, der kun holder, indtil distributionen genstarter, er ikke en rettelse. Genstart distributionen, tilslut VPN igen, og gentag den oprindelige Git-operation i stedet for en erstatning som ping eller en lille HTTP-anmodning. Bekræft derefter, at interfacet bærer den tilsigtede værdi i den nye session.

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

Hold den noterede oprindelige værdi ved siden af ændringen, så eksperimentet kan fortrydes rent, og notér, hvilken adressefamilie der blev testet, fordi et IPv4-resultat intet siger om en IPv6-forbindelse på samme vært. WSL's netværksdokumentation beskriver de tilstande, der bestemmer, hvordan en rettelse skal se ud; selve MTU-tallet er en lokal måling, ikke en anbefaling.