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 е локално мерење, не препорака.