Ping kwa anwani hufanya kazi ndani ya usambazaji, usakinishaji wa vifurushi na uvutaji wa git hazifanyi kazi, na hitilafu ilionekana mara moja baada ya handaki kupanda. Majina pekee yaliacha kutatuliwa, jambo linaloelekeza kwa DNS na si kwa muunganisho. Kusakinisha upya vifurushi ni hatua ya kwanza isiyo sahihi inayopendwa zaidi hapa. WSL2 ina njia mbili huru za kuzalisha dalili hiyo hasa, na zinahitaji matengenezo tofauti.

Kwa nini usambazaji unahifadhi resolver wake

Mteja wa DNS wa Windows hautumiki ndani ya usambazaji. WSL2 huunda faili lake la resolver wakati wa kuanza, likielekeza kwa anwani ya stub ambayo Windows huchapisha kwenye swichi pepe kwa mashine pepe saidizi.

Mpangilio huo ni thabiti katika mabadiliko ya kawaida ya mtandao kwa sababu huandikwa mara moja na kutumika tena. Mpangilio huacha kuwa sahihi pale mteja wa handaki anapoandika upya orodha ya adapta za mwenyeji baada ya mashine pepe saidizi kuanza tayari.

Hakuna kitu ndani ya usambazaji kinachofuatilia mabadiliko hayo, kwa hivyo faili linaendelea kuelekeza kwa anwani ambayo huenda haiko tena njiani. Utafutaji unaofuata hukaa, huisha muda, au hupata jibu kutoka kwa seva ambayo haijawahi kusikia kuhusu eneo la ndani. Kutoka ndani, resolver huacha kujibu tu, na majina yote hushindwa kwa wakati mmoja.

Kwanza kusanya ushahidi katika pande zote mbili

Rekodi kile usambazaji unachokiona, kisha kile Windows inachokiona, kabla ya kubadilisha chochote. Mitazamo hiyo miwili pamoja ndiyo inayotofautisha aina za kushindwa.

Ndani ya usambazaji, chapisha faili la resolver, jedwali la njia na utafutaji mmoja wa ndani na mmoja wa umma:

ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.com

Kwenye Windows, orodhesha seva za DNS kwa kila adapta na jedwali la IPv4 pamoja na vipimo. Mteja wa VPN kwa kawaida husakinisha njia kwa subnet ya WSL2, na kipimo chake huamua kama trafiki hiyo inatoka kupitia handaki au inabaki ndani.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Kipimo cha njia au faili lililopitwa na wakati

Hitilafu ya kwanza ni faili lililopitwa na wakati. Resolver iliandikwa kwa hali ya adapta wakati wa kuanza, na handaki ilibadilisha hali hiyo. Anwani yake ya stub sasa inaweza kufikiwa au inaweza kutaja seva isiyojua chochote kuhusu eneo la ndani.

Ya pili ni tatizo la njia. VPN inapoongeza njia inayofunika subnet ya WSL2 kwa kipimo cha chini kuliko njia ya kiungo cha mwenyeji, pakiti zinazoelekezwa kwa mashine pepe saidizi huingia handakini. Ndipo kila huduma ya WSL2 huisha muda, si DNS pekee.

Jaribio la kutofautisha hugharimu mstari mmoja. Ikiwa anwani ya nambari kama resolver ya umma bado inajibu ping wakati majina yanashindwa, njia iko salama na tatizo ni DNS. Hii ndiyo hali ambayo mabadiliko ya resolver yanahalalishwa, na hali ambayo hayahalalishwi pia huwa wazi. Ikiwa jaribio la nambari pia linashindwa, mashine pepe saidizi imepoteza njia yake na hakuna faili la resolver litakalotengeneza hilo.

Kwa hali ya njia, ondoa kipimo kiotomatiki kwenye adapta ya handaki na ipe nambari juu ya njia ya kiungo ya WSL2:

Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown

Kuzima ni muhimu. Kubadilisha kipimo hakuandiki upya mashine pepe saidizi inayoendesha, kwa hivyo usambazaji lazima ujengwe upya kabla ya mabadiliko kuonekana.

Chukua faili, kwa makusudi

Ikiwa uelekezaji ni sahihi na majina ya ndani pekee yanashindwa, resolver ndiye mwenye kosa na unaweza kusimamisha jenereta. Haya ni mabadiliko ya makusudi yenye gharama ya matengenezo, si suluhisho la muda la kutumiwa kizembe.

Unda /etc/wsl.conf ndani ya usambazaji pamoja na sehemu ya mtandao inayozima uzalishaji, kisha andika faili la resolver mwenyewe, seva ya kampuni kwanza na ya umma kama akiba baadaye:

[network]
generateResolvConf = false
search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

Mpangilio wa mambo ni muhimu. Resolver ya umma haiwezi kujibu jina la ndani, na akiba ipo kwa ajili ya utafutaji wa intaneti pekee. Faili linapokuwa lako, hakuna kinacholizalisha upya, kwa hivyo resolver ya kampuni inayohama huwa usumbufu ambao wewe mwenyewe unapaswa kuuona.

Angalia majina, kisha vifurushi

Thibitisha jina moja la ndani na moja la umma kwa resolver ya mfumo, kisha rudia operesheni iliyoshindwa. Wasimamizi wa vifurushi wakati mwingine hutumia resolver yao wenyewe, ndiyo sababu getent inayofanya kazi inaweza kuishi pamoja na usakinishaji uliovunjika.

Ikiwa unaendesha uandikaji upya kiotomatiki, fanya iwe na matokeo sawa kila mara: bila handaki, hifadhi faili lililopo badala ya kuandika orodha tupu ya seva.

getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com

Utafutaji wa ndani unaofanya kazi na utafutaji wa umma unaofanya kazi, kutoka ndani ya usambazaji, ndiyo tokeo linalostahili kurekodiwa. Aikoni ya kijani ya VPN kwenye mwenyeji haithibitishi hata moja.

Makala zinazohusiana