Git в WSL2 засича при VPN: MTU на интерфейса или пътят?

Клонирането се удостоверява, броят на обектите се появява и след това нищо не помръдва с минути. Windows отчита VPN като свързан, името на хоста се разрешава, а браузър на същата машина зарежда същата страница на хранилището без затруднения. Тази комбинация сочи към размера на пакета, а не към идентификационните данни, и въпросът за размера трябва да се зададе на две места, защото WSL2 има свой Linux интерфейс със собствен MTU. Едното число принадлежи на Windows страната на пътя, другото на дистрибуцията, а четенето само на VPN адаптера оставя половината път непроверен.

Три сигнала отделят проблем с размера от друго

Първият сигнал е формата: установяването на връзката и малкият обмен успяват, после масовото прехвърляне спира да напредва. Вторият е симетрията: същото хранилище и същият транспорт се провалят, докато друг хост по същия път работи, или отказът се променя с размера на полезния товар, а не с часа от деня. Третият е тишината: никаква грешка при удостоверяване, никакво отхвърляне от прокси, никакъв провал при разрешаване на имена, само прехвърляне, което никога не завършва.

Тези три заедно оправдават хипотезата за размера на пакета. DNS отказ, изтекъл токен, отхвърлен SSH ключ и прокси, което отказва CONNECT, всяко произвежда своя грешка и никое от тях не изглежда като засичане след успех. Запазването на същото хранилище, транспорт и времеви прозорец по време на тестването е това, което прави сравнението честно.

Сравнете двата интерфейса, преди да решите

Съберете Windows изгледа и Linux изгледа в една и съща сесия и пазете адреса на хранилището, вместо да гадаете кой интерфейс го носи. Командата по-долу първо разрешава дестинацията, така че търсенето на маршрут описва действителния сървър, който клонирането посещава, а той може да се различава от името, което браузърът е показал. Изпълнете двете половини близо една до друга, защото VPN може да промени метриките на интерфейса между опитите.

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

Изпълнете Linux половината вътре в дистрибуцията, вместо да поставяте изхода в Windows обвивка, защото имената на интерфейсите и изборът на маршрут имат смисъл само там. Поставяне от Windows обвивка съобщава грешни числа с голяма увереност. Запишете устройството, избрания маршрут и MTU от всяка страна, преди да промените каквото и да е.

Решете дали числото трябва да е по-малко

По-голям MTU на интерфейса, отколкото пътят може да носи, не е автоматично дефект, защото откриването на MTU на пътя съществува точно за това. Режимът на отказ се появява, когато откриването е потиснато: ICMP съобщенията се филтрират някъде по пътя, изпращачът така и не научава границата и големите пакети изчезват, докато малките успяват. Това е свойство на пътя, не на Git. Това е и причината малък файл да успее на връзка, на която голям никога не завършва.

Ако доказателствата го подкрепят, временна промяна на Linux интерфейса е най-евтиният тест. Изберете стойност под използваемия размер на пътя, запишете предишната и задръжте всичко останало непроменено, за да има смисъл сравнението. Ако прехвърлянето завърши при по-малката стойност, имате диагноза, а не съвпадение.

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

Решете къде да живее настройката

От теста следват три варианта и обикновено е подходящ само един от тях. Ако по-малката стойност поправи прехвърлянето и стойността наистина е нужна за тази мрежа, настройката се нуждае от собственик на жизнения цикъл: кука за стартиране в дистрибуцията, мрежова конфигурация, управлявана от платформата, или документирана процедура. Ако стойността не поправя нищо, върнете я и се върнете към въпросите за транспорта, проксито и удостоверяването.

Дали има кука за стартиране зависи от използваните версии на Windows и WSL и от конфигурирания мрежов режим. Огледалното копиране на Windows мрежата може да промени начина, по който VPN взаимодейства с дистрибуцията, по начини, които имат по-голямо значение от корекция на MTU, затова определете режима, преди да проектирате заобиколно решение за него. Стойност, която подхожда на един оператор или един VPN профил, не е подразбиране за следващия.

Какво да избягвате е изкушаващото поставяне: привилегирована мрежова команда в стартовия файл на всяка интерактивна обвивка или sudo без парола за целия ip двоичен файл, за да може скрипт да изпълни един ред. И двете превръщат диагностиката в постоянна експозиция и правят първоначалния проблем по-труден за виждане по-късно.

Проверете след чист старт, после отменете промяната

Промяна, която издържа само до рестартирането на дистрибуцията, не е поправка. Рестартирайте дистрибуцията, свържете VPN отново и повторете оригиналната Git операция, а не заместител като ping или малка HTTP заявка. След това потвърдете, че интерфейсът носи желаната стойност в новата сесия.

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

Пазете записаната оригинална стойност до промяната, за да може експериментът да се отмени чисто, и отбележете кое семейство адреси е тествано, защото резултат за IPv4 не казва нищо за IPv6 връзка на същия хост. Документацията за WSL мрежи описва режимите, които определят как трябва да изглежда поправката; самото MTU число е локално измерване, не препоръка.