Git megakad a WSL2-ben VPN mögött: interfész-MTU vagy az útvonal?

A klón hitelesít, megjelenik az objektumok száma, majd percekig semmi nem mozdul. A Windows jelzi, hogy a VPN csatlakoztatva van, a gazdagépnév feloldódik, és egy böngésző ugyanazon a gépen nehézség nélkül letölti ugyanazt a tárolóoldalt. Ez a kombináció a csomagméretre utal, nem a hitelesítő adatokra, és a méret kérdését két helyen kell feltenni, mert a WSL2-nek saját Linux interfésze van saját MTU-val. Az egyik szám az útvonal Windows oldalához tartozik, a másik a disztribúcióhoz, és ha csak a VPN-adaptert olvassa, az útvonal felét vizsgálatlanul hagyja.

Három jel választja el a méretproblémát mástól

Az első jel a forma: a kapcsolat létrejötte és egy kis csere sikerül, majd a tömeges átvitel leáll. A második a szimmetria: ugyanaz a tároló és ugyanaz a szállítás meghiúsul, miközben egy másik gazdagép ugyanazon az útvonalon működik, vagy a hiba a hasznos teher méretével változik, nem a napszakkal. A harmadik a csend: nincs hitelesítési hiba, nincs proxyelutasítás, nincs névfeloldási hiba, csak egy átvitel, amely soha nem fejeződik be.

Ez a három együtt igazolja a csomagméret-hipotézist. A DNS-hiba, a lejárt token, az elutasított SSH-kulcs és a CONNECT-et megtagadó proxy mindegyike a saját hibáját adja, és egyik sem néz ki sikeres utáni megakadásnak. Ugyanazon tároló, szállítás és időablak megtartása a tesztelés során az, ami őszintévé teszi az összehasonlítást.

Hasonlítsa össze mindkét interfészt, mielőtt dönt

Gyűjtse össze a Windows-nézetet és a Linux-nézetet ugyanabban a munkamenetben, és tartsa meg a tároló címét ahelyett, hogy találgatná, melyik interfész hordozza. Az alábbi parancs először feloldja a célt, hogy az útvonalkeresés a klón által ténylegesen elért kiszolgálót írja le, amely eltérhet a böngésző által mutatott névtől. Futtassa a két felet egymáshoz közel, mert a VPN a kísérletek között módosíthatja az interfész metrikáit.

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

A Linux-felét a disztribúcióban futtassa ahelyett, hogy a kimenetet Windows-héjba illesztené, mert az interfésznevek és az útvonalválasztás csak ott értelmezhető. A Windows-héjból beillesztett kimenet nagy magabiztossággal jelent rossz számokat. Jegyezze fel az eszközt, a választott útvonalat és az MTU-t mindkét oldalon, mielőtt bármit módosítana.

Döntse el, hogy a számnak kisebbnek kell-e lennie

Az útvonal által elbírható méretnél nagyobb interfész-MTU nem automatikusan hiba, mert az útvonal-MTU felderítése éppen erre való. A hibaüzemmód akkor jelentkezik, amikor a felderítést elnyomják: az ICMP-üzeneteket valahol az útvonalon szűrik, a küldő soha nem tudja meg a korlátot, és a nagy csomagok eltűnnek, míg a kicsik átjutnak. Ez az útvonal tulajdonsága, nem a Git tulajdonsága. Ez az oka annak is, hogy egy kis fájl sikerülhet olyan kapcsolaton, amelyen egy nagy soha nem fejeződik be.

Ha a bizonyítékok ezt támogatják, a Linux interfészen végzett ideiglenes módosítás a legolcsóbb teszt. Válasszon a használható útvonalméret alatti értéket, jegyezze fel az előzőt, és tartson minden mást változatlanul, hogy az összehasonlításnak legyen értelme. Ha az átvitel a kisebb értéken befejeződik, diagnózisa van, nem véletlen.

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

Döntse el, hol éljen a beállítás

A tesztből három lehetőség következik, és általában csak egy alkalmas közülük. Ha a kisebb érték megjavítja az átvitelt, és az érték valóban szükséges ehhez a hálózathoz, a beállításnak életciklus-gazdára van szüksége: indítási horogra a disztribúcióban, a platform által kezelt hálózati konfigurációra vagy dokumentált eljárásra. Ha az érték semmit nem javít, állítsa vissza, és térjen vissza a szállítás, a proxy és a hitelesítés kérdéseihez.

Hogy létezik-e indítási horog, a használt Windows- és WSL-verzióktól és a beállított hálózati módtól függ. A Windows-hálózat tükrözése megváltoztathatja, hogyan lép kölcsönhatásba a VPN a disztribúcióval, oly módon, ami fontosabb egy MTU-módosításnál, ezért azonosítsa a módot, mielőtt kerülőmegoldást tervezne hozzá. Az egy szolgáltatóhoz vagy egy VPN-profilhoz illő érték nem alapértelmezés a következőhöz.

Amit el kell kerülni, az a csábító elhelyezés: kiemelt hálózati parancs minden interaktív héj indítási fájljában, vagy jelszó nélküli sudo a teljes ip binárisra, hogy egy szkript futtathasson egy sort. Mindkettő állandó kitettséggé teszi a diagnózist, és később nehezebbé teszi az eredeti probléma meglátását.

Friss indítás után ellenőrizze, majd vonja vissza

Az a változás, amely csak a disztribúció újraindításáig tart, nem javítás. Indítsa újra a disztribúciót, csatlakoztassa újra a VPN-t, és ismételje meg az eredeti Git-műveletet, nem pedig egy helyettesítőt, például egy pinget vagy egy kis HTTP-kérést. Ezután erősítse meg, hogy az interfész az új munkamenetben a kívánt értéket hordozza.

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

Tartsa a feljegyzett eredeti értéket a változás mellett, hogy a kísérlet tisztán visszafordítható legyen, és jegyezze fel, melyik címcsaládot tesztelte, mert egy IPv4-eredmény semmit nem mond egy IPv6-kapcsolatról ugyanazon a gazdagépen. A WSL hálózati dokumentációja leírja azokat a módokat, amelyek meghatározzák, milyen legyen egy javítás; maga az MTU-szám helyi mérés, nem javaslat.