Git inakwama katika WSL2 kupitia VPN: MTU ya kiolesura au njia?
Git inathibitisha kisha inaning'inia ndani ya WSL2? Linganisha kiolesura cha Linux na adapta ya VPN ya Windows, jaribu thamani moja ndogo na upange maisha yake.
Klonu inathibitisha, idadi ya vitu inaonekana, kisha hakuna kinachosogea kwa dakika. Windows inaripoti VPN imeunganishwa, jina la mwenyeji linatatuliwa, na kivinjari kwenye mashine hiyo hiyo kinapata ukurasa huo wa hazina bila ugumu. Mchanganyiko huo unaashiria ukubwa wa pakiti na si vitambulisho, na swali la ukubwa lazima liulizwe sehemu mbili kwa sababu WSL2 ina kiolesura chake cha Linux na MTU yake. Namba moja ni ya upande wa Windows wa njia, nyingine ni ya usambazaji, na kusoma adapta ya VPN pekee kunaacha nusu ya njia bila kuchunguzwa.
Ishara tatu hutenganisha tatizo la ukubwa na mengine
Ishara ya kwanza ni umbo: kuanzisha muunganisho na kubadilishana kidogo hufanikiwa, kisha uhamishaji mkubwa huacha kuendelea. Ya pili ni ulinganifu: hazina hiyo na usafiri huo hushindwa huku mwenyeji mwingine kwenye njia hiyo akifanya kazi, au hitilafu hubadilika na ukubwa wa mzigo na si na saa ya siku. Ya tatu ni ukimya: hakuna hitilafu ya uthibitishaji, hakuna kukataliwa kwa proksi, hakuna kushindwa kwa utatuzi wa majina, ni uhamishaji tu ambao haukamiliki kamwe.
Hizi tatu pamoja zinahalalisha dhana ya ukubwa wa pakiti. Hitilafu ya DNS, token iliyoisha muda, ufunguo wa SSH uliokataliwa na proksi inayokataa CONNECT kila moja hutoa hitilafu yake, na hakuna inayoonekana kama kusimama baada ya mafanikio. Kudumisha hazina hiyo, usafiri huo na dirisha hilo la muda wakati wa kujaribu ndiko kunafanya ulinganisho uwe wa kweli.
Linganisha violesura vyote viwili kabla ya kuamua
Kusanya mwonekano wa Windows na mwonekano wa Linux katika kipindi kimoja, na shikilia anwani ya hazina badala ya kukisia kiolesura gani kinaibeba. Amri hapa chini kwanza hutatua lengwa ili utafutaji wa njia ueleze seva halisi ambayo klonu inawasiliana nayo, ambayo inaweza kutofautiana na jina ambalo kivinjari kilionyesha. Endesha nusu zote mbili karibu kwa wakati mmoja, kwa sababu VPN inaweza kubadilisha vipimo vya kiolesura kati ya majaribio.
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"'
Endesha nusu ya Linux ndani ya usambazaji badala ya kubandika matokeo kwenye gamba la Windows, kwa sababu majina ya violesura na uchaguzi wa njia yana maana hapo pekee. Kubandika kutoka gamba la Windows huripoti namba zisizo sahihi kwa kujiamini sana. Andika kifaa, njia iliyochaguliwa na MTU kutoka kila upande kabla ya kubadilisha chochote.
Amua ikiwa namba inapaswa kuwa ndogo
MTU ya kiolesura kubwa kuliko njia inaweza kubeba si kasoro kiotomatiki, kwa sababu ugunduzi wa MTU ya njia upo kwa ajili hiyo. Hali ya kushindwa huonekana wakati ugunduzi unakandamizwa: ujumbe wa ICMP huchujwa mahali pengine njiani, mtumaji hajui kikomo kamwe, na pakiti kubwa hutoweka wakati ndogo zinapita. Hiyo ni sifa ya njia, si sifa ya Git. Ndiyo sababu faili ndogo inaweza kufanikiwa kwenye muunganisho ambao mkubwa haukamiliki kamwe.
Ikiwa ushahidi unaunga mkono, badiliko la muda kwenye kiolesura cha Linux ni jaribio la bei nafuu. Chagua thamani chini ya ukubwa unaoweza kutumika wa njia, andika ile ya awali, na uweke kila kitu kingine sawa ili ulinganisho uwe na maana. Ikiwa uhamishaji unakamilika kwa thamani ndogo, una utambuzi na si bahati nasibu.
ip -br link show dev eth0
sudo ip link set dev eth0 mtu 1380
ip -br link show dev eth0
Amua mpangilio unapaswa kuishi wapi
Chaguo tatu zinatokea kutokana na jaribio, na kwa kawaida ni moja tu iliyofaa. Ikiwa thamani ndogo inarekebisha uhamishaji na thamani inahitajika kweli kwa mtandao huu, mpangilio unahitaji mmiliki wa mzunguko wa maisha: ndoano ya kuanza katika usambazaji, usanidi wa mtandao unaosimamiwa na jukwaa, au utaratibu ulioandikwa. Ikiwa thamani hairekebishi chochote, irudishe na urudi kwenye maswali ya usafiri, proksi na uthibitishaji.
Kama ndoano ya kuanza ipo inategemea matoleo ya Windows na WSL yanayotumika na hali ya mtandao iliyosanidiwa. Kuakisisha mtandao wa Windows kunaweza kubadilisha jinsi VPN inavyoshirikiana na usambazaji kwa njia ambazo ni muhimu zaidi kuliko marekebisho ya MTU, kwa hivyo tambua hali kabla ya kubuni suluhisho la pembeni kwa ajili yake. Thamani inayofaa mwendeshaji mmoja au wasifu mmoja wa VPN si chaguo-msingi kwa inayofuata.
Kinachopaswa kuepukwa ni uwekaji wa kuvutia: amri ya mtandao yenye upendeleo katika faili ya kuanza ya kila gamba la mwingiliano, au sudo bila nenosiri kwa binary yote ya ip ili script iweze kuendesha mstari mmoja. Zote mbili zinageuza utambuzi kuwa mfiduo wa kudumu na kufanya tatizo la awali kuwa gumu kuona baadaye.
Thibitisha baada ya kuanza safi, kisha urudishe
Badiliko linalodumu tu hadi usambazaji uanze upya si suluhisho. Anzisha upya usambazaji, unganisha VPN tena, na urudie operesheni ya awali ya Git badala ya mbadala kama ping au ombi dogo la HTTP. Kisha thibitisha kuwa kiolesura kinabeba thamani iliyokusudiwa katika kipindi kipya.
ip -br link show dev eth0
ip route get "$(getent ahostsv4 github.com | awk 'NR==1{print $1}')"
Weka thamani ya awali iliyoandikwa kando ya badiliko ili jaribio liweze kutenduliwa kwa usafi, na andika ni familia gani ya anwani iliyojaribiwa, kwa sababu matokeo ya IPv4 hayasemi chochote kuhusu muunganisho wa IPv6 kwenye mwenyeji huyo huyo. Nyaraka za mtandao za WSL zinaeleza hali zinazoamua jinsi marekebisho yanapaswa kuonekana; namba ya MTU yenyewe ni kipimo cha ndani, si pendekezo.