Git se blochează în WSL2 prin VPN: MTU al interfeței sau calea?

Clone-ul se autentifică, numărul de obiecte apare, iar apoi nimic nu se mișcă minute în șir. Windows raportează VPN-ul ca fiind conectat, numele de gazdă se rezolvă, iar un browser de pe aceeași mașină aduce aceeași pagină a depozitului fără dificultate. Această combinație indică dimensiunea pachetului, nu acreditările, iar întrebarea despre dimensiune trebuie pusă în două locuri pentru că WSL2 are propria interfață Linux cu propriul MTU. Un număr aparține părții Windows a căii, celălalt distribuției, iar citirea doar a adaptorului VPN lasă jumătate din cale neexaminată.

Trei semnale separă o problemă de dimensiune de altele

Primul semnal este forma: stabilirea conexiunii și un schimb mic reușesc, apoi transferul masiv încetează să mai progreseze. Al doilea este simetria: același depozit și același transport eșuează în timp ce o altă gazdă pe aceeași cale funcționează, sau eșecul se schimbă cu dimensiunea încărcăturii, nu cu ora din zi. Al treilea este tăcerea: nicio eroare de autentificare, niciun refuz al proxy-ului, nicio eroare de rezolvare a numelor, doar un transfer care nu se termină niciodată.

Aceste trei împreună justifică ipoteza dimensiunii pachetului. O eroare DNS, un token expirat, o cheie SSH respinsă și un proxy care refuză CONNECT produc fiecare propria eroare, iar niciuna nu arată ca o oprire după succes. Păstrarea aceluiași depozit, transport și interval de timp în timpul testului este ceea ce face comparația corectă.

Comparați ambele interfețe înainte de a decide

Strângeți imaginea Windows și imaginea Linux în aceeași sesiune și păstrați adresa depozitului în loc să ghiciți care interfață o poartă. Comanda de mai jos rezolvă mai întâi destinația, astfel încât căutarea rutei să descrie serverul real cu care comunică clone-ul, care poate diferi de numele afișat de un browser. Rulați ambele jumătăți aproape una de alta, pentru că VPN-ul poate schimba metricile interfeței între încercări.

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

Rulați jumătatea Linux în interiorul distribuției în loc să lipiți ieșirea într-un shell Windows, deoarece numele interfețelor și alegerea rutei au sens doar acolo. O lipire dintr-un shell Windows raportează numerele greșite cu mare încredere. Notați dispozitivul, ruta aleasă și MTU-ul din fiecare parte înainte de a schimba ceva.

Decideți dacă numărul ar trebui să fie mai mic

Un MTU al interfeței mai mare decât poate calea să transporte nu este automat un defect, pentru că descoperirea MTU a căii există exact pentru asta. Modul de eșec apare când descoperirea este suprimată: mesajele ICMP sunt filtrate undeva pe parcurs, expeditorul nu află niciodată limita, iar pachetele mari dispar în timp ce cele mici trec. Aceasta este o proprietate a căii, nu o proprietate a Git. Este și motivul pentru care un fișier mic poate reuși pe o conexiune pe care unul mare nu se termină niciodată.

Dacă dovezile susțin asta, o modificare temporară pe interfața Linux este cel mai ieftin test. Alegeți o valoare sub dimensiunea utilizabilă a căii, notați-o pe cea anterioară și păstrați tot restul constant pentru ca comparația să însemne ceva. Dacă transferul se termină cu valoarea mai mică, aveți un diagnostic și nu o coincidență.

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

Decideți unde ar trebui să locuiască setarea

Din test rezultă trei opțiuni, iar de obicei doar una este potrivită. Dacă valoarea mai mică repară transferul și valoarea este cu adevărat necesară pentru această rețea, setarea are nevoie de un proprietar al ciclului de viață: un cârlig de pornire în distribuție, o configurație de rețea gestionată de platformă sau o procedură documentată. Dacă valoarea nu repară nimic, readuceți-o și reveniți la întrebările despre transport, proxy și autentificare.

Existența unui cârlig de pornire depinde de versiunile Windows și WSL folosite și de modul de rețea configurat. Oglindirea rețelei Windows poate schimba modul în care VPN-ul interacționează cu distribuția, în feluri care contează mai mult decât o ajustare a MTU, așa că identificați modul înainte de a proiecta o soluție ocolitoare pentru el. O valoare potrivită pentru un operator sau un profil VPN nu este o valoare implicită pentru următorul.

Ce trebuie evitat este plasarea tentantă: o comandă de rețea privilegiată în fișierul de pornire al fiecărui shell interactiv, sau sudo fără parolă pentru întregul binar ip ca un script să poată rula o linie. Ambele transformă un diagnostic în expunere permanentă și fac problema originală mai greu de văzut mai târziu.

Verificați după o pornire curată, apoi reveniți

O modificare care rezistă doar până la repornirea distribuției nu este o remediere. Reporniți distribuția, reconectați VPN-ul și repetați operația Git originală în locul unui substitut precum ping sau o cerere HTTP mică. Apoi confirmați că interfața poartă valoarea dorită în noua sesiune.

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

Păstrați valoarea originală notată lângă modificare pentru ca experimentul să poată fi anulat curat, și notați care familie de adrese a fost testată, deoarece un rezultat IPv4 nu spune nimic despre o conexiune IPv6 pe aceeași gazdă. Documentația de rețea a WSL descrie modurile care determină cum ar trebui să arate o remediere; numărul MTU în sine este o măsurătoare locală, nu o recomandare.