Git ve WSL2 zamrzne na VPN: MTU rozhraní, nebo cesta?

Klon se ověří, objeví se počet objektů a poté se několik minut nic nehýbe. Windows hlásí VPN jako připojenou, název hostitele se přeloží a prohlížeč na stejném stroji bez potíží načte stejnou stránku úložiště. Tato kombinace ukazuje na velikost paketů, nikoli na přihlašovací údaje, a otázku velikosti je třeba položit na dvou místech, protože WSL2 má vlastní linuxové rozhraní s vlastním MTU. Jedno číslo patří windowsové straně cesty, druhé distribuci, a čtení pouze adaptéru VPN nechává polovinu cesty neprozkoumanou.

Tři signály oddělují problém velikosti od jiného

První signál je tvar: navázání spojení a malá výměna uspějí, poté velký přenos přestane postupovat. Druhý je symetrie: stejné úložiště a stejný transport selžou, zatímco jiný hostitel na stejné cestě funguje, nebo se selhání mění s velikostí užitečného zatížení, nikoli s denní dobou. Třetí je ticho: žádná chyba ověření, žádné odmítnutí proxy, žádné selhání překladu jmen, jen přenos, který nikdy neskončí.

Tyto tři dohromady opravňují hypotézu velikosti paketů. Selhání DNS, propadlý token, odmítnutý klíč SSH a proxy, která odmítá CONNECT, každé vytváří vlastní chybu a žádné nevypadá jako zaseknutí po úspěchu. Zachování stejného úložiště, transportu a časového okna při testování je to, co dělá srovnání poctivým.

Před rozhodnutím porovnejte obě rozhraní

Shromážděte windowsový a linuxový pohled v téže relaci a držte se adresy úložiště místo hádání, které rozhraní ji nese. Níže uvedený příkaz nejprve přeloží cíl, aby vyhledání trasy popsalo skutečný server, se kterým se klon spojuje, a ten se může lišit od jména, které ukázal prohlížeč. Spusťte obě poloviny blízko sebe, protože VPN může mezi pokusy změnit metriky rozhraní.

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

Spusťte linuxovou polovinu uvnitř distribuce, místo abyste výstup vkládali do windowsového shellu, protože názvy rozhraní a volba trasy mají smysl jen tam. Vložení z windowsového shellu hlásí špatná čísla s velkou jistotou. Zaznamenejte zařízení, zvolenou trasu a MTU z každé strany, než cokoli změníte.

Rozhodněte, zda má být číslo menší

Větší MTU rozhraní, než cesta unese, není automaticky závada, protože zjišťování MTU cesty existuje právě pro to. Režim selhání se objeví, když je zjišťování potlačeno: zprávy ICMP se někde na cestě filtrují, odesílatel se limit nikdy nedozví a velké pakety mizí, zatímco malé procházejí. To je vlastnost cesty, nikoli vlastnost Gitu. Je to také důvod, proč malý soubor může uspět na spojení, kde velký nikdy neskončí.

Pokud to důkazy podporují, dočasná změna na linuxovém rozhraní je nejlevnější test. Zvolte hodnotu pod použitelnou velikostí cesty, zaznamenejte předchozí a vše ostatní držte konstantní, aby srovnání něco znamenalo. Pokud přenos při menší hodnotě skončí, máte diagnózu, nikoli náhodu.

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

Rozhodněte, kde má nastavení žít

Z testu vyplývají tři možnosti a obvykle je vhodná jen jedna z nich. Pokud menší hodnota přenos opraví a hodnota je pro tuto síť skutečně nutná, nastavení potřebuje vlastníka životního cyklu: spouštěcí hook v distribuci, síťovou konfiguraci spravovanou platformou, nebo zdokumentovaný postup. Pokud hodnota nic neopraví, vraťte ji a vraťte se k otázkám transportu, proxy a ověřování.

Zda spouštěcí hook existuje, závisí na používaných verzích Windows a WSL a na nakonfigurovaném síťovém režimu. Zrcadlení sítě Windows může změnit, jak VPN s distribucí interaguje, způsoby, které jsou důležitější než úprava MTU, proto režim identifikujte dřív, než pro něj navrhnete obejití. Hodnota, která vyhovuje jednomu operátorovi nebo jednomu profilu VPN, není výchozí pro další.

Čemu se vyhnout, je lákavé umístění: privilegovaný síťový příkaz ve spouštěcím souboru každého interaktivního shellu, nebo sudo bez hesla pro celý binární soubor ip, aby skript mohl spustit jeden řádek. Obé mění diagnostiku v trvalé vystavení a činí původní problém později hůře viditelným.

Ověřte po čistém startu a poté změnu vraťte

Změna, která vydrží jen do restartu distribuce, není oprava. Restartujte distribuci, znovu připojte VPN a zopakujte původní operaci Gitu, nikoli náhradu jako ping nebo malý požadavek HTTP. Poté potvrďte, že rozhraní v nové relaci nese zamýšlenou hodnotu.

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

Zaznamenanou původní hodnotu držte vedle změny, aby šel experiment čistě vrátit, a poznamenejte, která rodina adres byla testována, protože výsledek IPv4 nic neříká o připojení IPv6 na stejném hostiteli. Dokumentace k sítím WSL popisuje režimy, které určují, jak má oprava vypadat; samotné číslo MTU je místní měření, nikoli doporučení.