Git fastnar i WSL2 över VPN: gränssnittets MTU eller vägen?

Git autentiserar och hänger sedan i WSL2? Jämför Linux-gränssnittet med Windows VPN-adaptern, testa ett mindre värde och planera dess livslängd.

Klones autentiserar, objektantalet visas och sedan rör sig ingenting på flera minuter. Windows rapporterar VPN som anslutet, värdnamnet löses upp och en webbläsare på samma maskin hämtar samma repositorisida utan svårighet. Kombinationen pekar på paketstorlek snarare än på inloggningsuppgifter, och storleksfrågan måste ställas på två ställen eftersom WSL2 har ett eget Linux-gränssnitt med egen MTU. Det ena talet hör till Windows-sidan av vägen, det andra till distributionen, och att bara läsa VPN-adaptern lämnar halva vägen oundersökt.

Tre signaler skiljer ett storleksproblem från annat

Den första signalen är formen: anslutningsuppbyggnad och ett litet utbyte lyckas, sedan slutar den stora överföringen att göra framsteg. Den andra är symmetri: samma repositorium och samma transport misslyckas medan en annan värd på samma väg fungerar, eller så ändras felet med nyttolastens storlek och inte med tiden på dagen. Den tredje är tystnad: inget autentiseringsfel, ingen proxyavvisning, ingen namnmatchning, bara en överföring som aldrig slutförs.

De tre tillsammans motiverar en hypotes om paketstorlek. Ett DNS-fel, en utgången token, en avvisad SSH-nyckel och en proxy som avvisar CONNECT ger var sitt fel, och ingen av dem ser ut som en stillestånd efter framgång. Att behålla samma repositorium, transport och tidsfönster under testet är det som gör jämförelsen ärlig.

Jämför båda gränssnitten innan du bestämmer dig

Samla Windows-vyn och Linux-vyn i samma session och håll fast vid repositoriets adress i stället för att gissa vilket gränssnitt som bär den. Kommandot nedan löser först upp målet så att routningen beskriver den faktiska server som klonen kontaktar, vilken kan skilja sig från namnet en webbläsare visade. Kör båda halvorna tätt inpå varandra, eftersom VPN kan ändra gränssnittets mätvärden mellan försöken.

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-halvan inne i distributionen i stället för att klistra in utdata i ett Windows-skal, eftersom gränssnittsnamn och vägval bara är meningsfulla där. En inklistring från ett Windows-skal rapporterar fel siffror med stor säkerhet. Notera enheten, den valda vägen och MTU:n från varje sida innan du ändrar något.

Avgör om talet bör vara mindre

En större gränssnitts-MTU än vägen kan bära är inte automatiskt ett fel, eftersom upptäckt av väg-MTU finns just för det. Fellläget uppstår när upptäckten undertrycks: ICMP-meddelanden filtreras någonstans på vägen, avsändaren lär sig aldrig gränsen och stora paket försvinner medan små släpps igenom. Det är en egenskap hos vägen, inte hos Git. Det är också anledningen till att en liten fil kan lyckas på en anslutning där en stor aldrig slutförs.

Om bevisen stöder det är en tillfällig ändring på Linux-gränssnittet det billigaste testet. Välj ett värde under den användbara vägstorleken, notera det föregående och håll allt annat konstant så att jämförelsen betyder något. Om överföringen slutförs vid det mindre värdet har du en diagnos och inte en slump.

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

Avgör var inställningen ska bo

Tre alternativ följer av testet, och vanligtvis är bara ett av dem lämpligt. Om det mindre värdet rättar överföringen och värdet verkligen behövs för detta nätverk behöver inställningen en ägare av livscykeln: en uppstartskrok i distributionen, en nätverkskonfiguration som hanteras av plattformen eller en dokumenterad procedur. Om värdet inte rättar något, rulla tillbaka det och återgå till frågorna om transport, proxy och autentisering.

Om det finns en uppstartskrok beror på de Windows- och WSL-versioner som används och på det konfigurerade nätverksläget. Spegling av Windows-nätverket kan ändra hur en VPN samverkar med distributionen på sätt som betyder mer än en MTU-justering, så identifiera läget innan du designar en tillfällig lösning för det. Ett värde som passar en leverantör eller en VPN-profil är inte en standard för nästa.

Det som ska undvikas är den frestande placeringen: ett privilegierat nätverkskommando i varje interaktivt skals startfil, eller lösenordslöst sudo för hela ip-binären så att ett skript kan köra en rad. Båda gör en diagnos till permanent exponering och gör det ursprungliga problemet svårare att se senare.

Verifiera efter en ren start och rulla sedan tillbaka

En ändring som bara håller till distributionen startar om är ingen åtgärd. Starta om distributionen, anslut VPN igen och upprepa den ursprungliga Git-åtgärden i stället för en ersättning som ping eller en liten HTTP-begäran. Bekräfta sedan att gränssnittet bär det avsedda värdet i den nya sessionen.

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

Håll det noterade ursprungsvärdet bredvid ändringen så att experimentet kan ångras rent, och notera vilken adressfamilj som testades, eftersom ett IPv4-resultat inte säger något om en IPv6-anslutning på samma värd. WSL:s nätverksdokumentation beskriver de lägen som avgör hur en åtgärd ska se ut; själva MTU-talet är en lokal mätning, inte en rekommendation.

Relaterade artiklar