Git stjit fêst yn WSL2 efter in VPN: ynterface-MTU of it paad?

De kloan autentisearret, it oantal objekten ferskynt, en dan beweecht neat minuten lang. Windows meldt de VPN as ferbûn, de hostnamme wurdt oplost, en in browser op deselde masine hellet deselde repository-side sûnder swierrichheden. Dy kombinaasje wiist op pakketgrutte yn stee fan op oanmeldgegevens, en de gruttefrage moat op twa plakken steld wurde, om't WSL2 syn eigen Linux-ynterface hat mei syn eigen MTU. It iene getal heart by de Windows-kant fan it paad, it oare by de distribúsje, en allinnich de VPN-adapter lêze lit de helte fan it paad ûndersocht.

Trije sinjalen skiede in grutteprobleem fan oars

It earste sinjaal is foarm: ferbiningsopset en in lytse útwikseling slagje, dêrnei hâldt de massale oerdracht op mei foarútgong. It twadde is symmetry: deselde repository en deselde transport falle, wylst in oare host op itselde paad wurket, of de flater feroaret mei de grutte fan 'e lading yn stee fan mei de tiid fan 'e dei. It tredde is stilte: gjin autentikaasjeflater, gjin proxy-ôfwizing, gjin nammoplossingsflater, allinnich in oerdracht dy't nea foltôge wurdt.

Dy trije tegearre rjochtfeardigje in hypoteze oer pakketgrutte. In DNS-flater, in ferrûn token, in ôfwiisd SSH-kaai en in proxy dy't CONNECT ôfwiist meitsje elk har eigen flater, en gjinien liket op in stilstean nei sukses. Itselde repository, deselde transport en itselde tiidfinster by it testen hâlde is wat de ferliking earlik makket.

Ferlykje beide ynterfaces foardat jo beslute

Sammele de Windows-werjefte en de Linux-werjefte yn deselde sesje, en hâld it adres fan it repository oan yn stee fan te rieden hokker ynterface it draacht. It kommando hjirûnder lost earst de bestimming op, sadat de rûtesyktocht de werklike server beskriuwt dy't de kloan kontaktet, dy't ferskille kin fan 'e namme dy't in browser toande. Run beide helten ticht byinoar, om't de VPN ynterface-metriken tusken besikings feroarje kin.

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

Run de Linux-helte yn 'e distribúsje yn stee fan de útfier yn in Windows-shell te plakken, om't de ynterfacenammen en rûtekar allinnich dêr sin meitsje. In plak fan in Windows-shell rapportearret de ferkearde getallen mei grut fertrouwen. Notearje it apparaat, de keazen rûte en de MTU fan elke kant foardat jo wat feroarje.

Beslute oft it getal lytser wêze moat

In grutter ynterface-MTU as it paad drage kin is net automatysk in flater, om't paad-MTU-ûntdekking krekt dêrfoar bestiet. De flatermodus ferskynt as ûntdekking ûnderdrukt wurdt: ICMP-berjochten wurde earne op it paad filtere, de ferstjoerder leart de limyt nea, en grutte pakketten ferdwine wylst lytse trochkomme. Dat is in eigenskip fan it paad, net fan Git. It is ek de reden wêrom't in lyts bestân slagje kin op in ferbining dêr't in grut nea foltôge wurdt.

As it bewiis dat stipet, is in tydlike feroaring op it Linux-ynterface de goedkeapste test. Kies in wearde ûnder de brûkbere paadgrutte, notearje de foarige, en hâld al it oare konstant sadat de ferliking wat betsjut. As de oerdracht by de lytsere wearde foltôge wurdt, hawwe jo in diagnoaze en gjin tafal.

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

Beslute wêr't de ynstelling wenje moat

Ut de test folgje trije opsjes, en meastentiids is mar ien fan har passend. As de lytsere wearde de oerdracht reparearret en de wearde echt nedich is foar dit netwurk, hat de ynstelling in eigner fan 'e libbenssyklus nedich: in startheak yn 'e distribúsje, in netwurkkonfiguraasje beheard troch it platfoarm, of in dokumintearre proseduere. As de wearde neat reparearret, set har werom en gean werom nei de fragen oer transport, proxy en autentikaasje.

Oft der in startheak bestiet hinget ôf fan 'e brûkte Windows- en WSL-ferzjes en fan 'e konfigurearre netwurkmode. It spegeljen fan it Windows-netwurk kin feroarje hoe't in VPN mei de distribúsje omgiet, op manieren dy't mear betsjutte as in MTU-oanpassing, dus identifisearje de mode foardat jo dêrfoar in tydlike oplossing ûntwerpe. In wearde dy't by ien oanbieder of ien VPN-profyl past is gjin standert foar de folgjende.

Wat te foarkommen is, is it ferlokjende plak: in privilezjeare netwurkopdracht yn it startbestân fan elke ynteraktive shell, of sudo sûnder wachtwurd foar it hiele ip-binêre bestân sadat in skript ien rigel rinne kin. Beide meitsje in diagnoaze ta permaninte bleatstelling en meitsje it oarspronklike probleem letter dreger te sjen.

Ferifiearje nei in frisse start, set dan werom

In feroaring dy't allinnich oant it werstarten fan 'e distribúsje bliuwt, is gjin oplossing. Werstart de distribúsje, ferbyn de VPN opnij, en werhelje de oarspronklike Git-operaasje yn stee fan in ferfanger lykas ping of in lytse HTTP-oanfraach. Befêstigje dan dat it ynterface yn 'e nije sesje de bedoelde wearde draacht.

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

Hâld de notearre oarspronklike wearde neist de feroaring sadat it eksperimint skjin weromdraaid wurde kin, en notearje hokker adresfamylje test is, om't in IPv4-resultaat neat seit oer in IPv6-ferbining op deselde host. De WSL-netwurkkdokumintaasje beskriuwt de modi dy't bepale hoe't in oplossing derút moat sjen; it MTU-getal sels is in lokale mjitting, gjin oanbefelling.