Git blijft hangen in WSL2 via VPN: interface-MTU of het pad?

De kloon authenticeert, het objectenaantal verschijnt en daarna beweegt er minutenlang niets. Windows meldt de VPN als verbonden, de hostnaam wordt omgezet en een browser op dezelfde machine haalt dezelfde repositorypagina zonder moeite op. Die combinatie wijst op pakketgrootte en niet op inloggegevens, en de groottevraag moet op twee plaatsen worden gesteld omdat WSL2 een eigen Linux-interface met een eigen MTU heeft. Het ene getal hoort bij de Windows-kant van het pad, het andere bij de distributie, en alleen de VPN-adapter lezen laat de helft van het pad ononderzocht.

Drie signalen scheiden een grootteprobleem van iets anders

Het eerste signaal is vorm: verbindingsopbouw en een kleine uitwisseling slagen, daarna stopt de bulkoverdracht met voortgang maken. Het tweede is symmetrie: dezelfde repository en hetzelfde transport falen terwijl een andere host op hetzelfde pad werkt, of de fout verandert met de payloadgrootte en niet met de tijd van de dag. Het derde is stilte: geen authenticatiefout, geen proxyweigering, geen naamomzettingsfout, alleen een overdracht die nooit voltooid wordt.

Die drie samen rechtvaardigen een hypothese over de pakketgrootte. Een DNS-fout, een verlopen token, een geweigerde SSH-sleutel en een proxy die CONNECT weigert geven elk hun eigen fout, en geen ervan ziet eruit als een stilstand na succes. Dezelfde repository, hetzelfde transport en hetzelfde tijdvenster aanhouden tijdens het testen is wat de vergelijking eerlijk maakt.

Vergelijk beide interfaces voordat u beslist

Verzamel de Windows-weergave en de Linux-weergave in dezelfde sessie, en houd het adres van de repository aan in plaats van te raden welke interface het draagt. De opdracht hieronder zet eerst de bestemming om, zodat de route-lookup de werkelijke server beschrijft die de kloon benadert, die kan afwijken van de naam die een browser toonde. Voer beide helften kort na elkaar uit, omdat de VPN tussen pogingen de interfacemetrieken kan wijzigen.

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

Voer de Linux-helft binnen de distributie uit in plaats van de uitvoer in een Windows-shell te plakken, omdat interfacenamen en routekeuze alleen daar betekenis hebben. Een plaksel uit een Windows-shell meldt de verkeerde getallen met groot vertrouwen. Noteer het apparaat, de gekozen route en de MTU van elke kant voordat u iets wijzigt.

Bepaal of het getal kleiner moet zijn

Een grotere interface-MTU dan het pad kan dragen is niet automatisch een fout, omdat path-MTU-detectie juist daarvoor bestaat. De foutmodus verschijnt wanneer detectie wordt onderdrukt: ICMP-berichten worden ergens onderweg gefilterd, de afzender leert de limiet nooit en grote pakketten verdwijnen terwijl kleine erdoor komen. Dat is een eigenschap van het pad, niet van Git. Dat is ook de reden waarom een klein bestand kan slagen op een verbinding waar een groot nooit voltooid wordt.

Als de bewijzen dat ondersteunen, is een tijdelijke wijziging op de Linux-interface de goedkoopste test. Kies een waarde onder de bruikbare padgrootte, noteer de vorige en houd al het andere constant zodat de vergelijking iets betekent. Als de overdracht bij de kleinere waarde voltooid wordt, hebt u een diagnose en geen toeval.

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

Bepaal waar de instelling moet leven

Uit de test volgen drie opties, en meestal is er maar één passend. Als de kleinere waarde de overdracht herstelt en de waarde echt nodig is voor dit netwerk, heeft de instelling een eigenaar van de levensduur nodig: een starthook in de distributie, een door het platform beheerde netwerkconfiguratie of een gedocumenteerde procedure. Als de waarde niets herstelt, draai hem terug en keer terug naar de vragen over transport, proxy en authenticatie.

Of er een starthook bestaat, hangt af van de gebruikte Windows- en WSL-versies en van de geconfigureerde netwerkmodus. Het Windows-netwerk spiegelen kan veranderen hoe een VPN met de distributie omgaat, op manieren die meer uitmaken dan een MTU-aanpassing, dus identificeer de modus voordat u daarvoor een tijdelijke oplossing ontwerpt. Een waarde die bij één provider of één VPN-profiel past, is geen standaard voor de volgende.

Wat vermeden moet worden, is de verleidelijke plaatsing: een bevoorrecht netwerkcommando in het opstartbestand van elke interactieve shell, of sudo zonder wachtwoord voor het hele ip-binair zodat een script één regel kan uitvoeren. Beide maken van een diagnose een blijvende blootstelling en maken het oorspronkelijke probleem later moeilijker te zien.

Verifieer na een schone start en draai het daarna terug

Een wijziging die alleen standhoudt tot de distributie opnieuw start, is geen oplossing. Herstart de distributie, verbind de VPN opnieuw en herhaal de oorspronkelijke Git-bewerking in plaats van een vervanging zoals ping of een klein HTTP-verzoek. Bevestig daarna dat de interface in de nieuwe sessie de bedoelde waarde draagt.

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

Houd de genoteerde oorspronkelijke waarde naast de wijziging zodat het experiment schoon ongedaan gemaakt kan worden, en noteer welke adresfamilie is getest, want een IPv4-resultaat zegt niets over een IPv6-verbinding op dezelfde host. De WSL-netwerkdocumentatie beschrijft de modi die bepalen hoe een oplossing eruit moet zien; het MTU-getal zelf is een lokale meting, geen aanbeveling.