Kwa nini resolv.conf inaonyesha DNS ya VPN yako lakini utafutaji unaipuuza

Hakuna kitu kwenye kumbukumbu kinachoonekana kibaya: kiolesura kiko juu, kitatuzi kinaarifu seva ya DNS ya VPN, na faili iliyo kwenye diski inaiorodhesha. Hata hivyo jina la mwenyeji wa ndani bado linatatuliwa kupitia kipanga njia cha ndani. Kauli hizi tatu hazipingani, kwa sababu faili, hali ya kila kiungo na njia ya utafutaji ni vitu tofauti vinavyoshiriki jina moja kwa bahati. Ifuatayo ni njia ambayo swali hupita kweli kwenye mwenyeji aliye na systemd-resolved.

Vitu vitatu vinavyoitwa resolv.conf

Kwenye mwenyeji aliye na resolved, /etc/resolv.conf kwa kawaida ni kiungo cha mfano kuelekea /run/systemd/resolve/stub-resolv.conf. Lengo hilo lina anwani ya msikilizaji wa stub wa ndani, 127.0.0.53, pamoja na vikoa vya utafutaji vilivyohesabiwa na resolved. Ni mwonekano wa hali, si hali yenyewe.

Hali inaishi katika usanidi wa resolved kwa kila kiungo, ndiyo sababu resolvectl status unaweza kutokubaliana na faili na bado uwe sahihi. Kila kiungo hubeba seva zake na vikoa vyake vya uelekezaji, na stub hushauriana na data hiyo swali linapofika. Mwongozo wa systemd-resolved unaeleza faili zinazozalishwa na mtindo wa kila kiungo; mgawanyo kati ya mwonekano na hali ni sehemu inayofaa kukumbukwa. Kubadilisha lengo la kiungo cha mfano hubadilisha kile wateja wa kawaida wanakisoma, si kile kitatuzi kinachojua.

Kitu cha tatu, /run/systemd/resolve/resolv.conf, husawazisha kila kiungo kuwa orodha moja ya seva. Programu inayoelekea faili hilo hutuma maswali moja kwa moja kwa seva zilizoorodheshwa na huruka stub, kwa hiyo sera ya kila kiungo haitumiki tena kwa hiyo. Kwa hiyo programu mbili kwenye mashine moja zinaweza kujibu jina moja kwa namna tofauti, na hakuna iliyovunjika.

Fuata utafutaji mmoja kupitia NSS

glibc husoma /etc/nsswitch.conf ili kuamua nani anajibu jina. Mstari wa hosts ulio na resolve huelekeza swali kwa nss-resolve, ambao huuuliza resolved kupitia D-Bus na hupokea jibu la kila kiungo. Mstari wenye files dns pekee hutuma swali kwa anwani ambayo /etc/resolv.conf inashikilia.

Mstari huo mmoja unaeleza tofauti nyingi kati ya kivinjari na dig. dig husoma resolv.conf moja kwa moja na huwahi kugusa NSS, kwa hiyo hujaribu stub au seva ya juu badala ya njia inayotumiwa na programu. getent hosts internal.example hupitia NSS, na kulinganisha jibu lake na la dig ni kipimo cha kwanza chenye manufaa.

Programu zinazobeba kitatuzi chao, au zinazozungumza DNS kupitia HTTPS kwa mwisho maalum, hukwepa njia zote mbili. Hakuna kitu katika resolv.conf au katika hali ya resolved kinachozizuia.

Angalia faili ni ya nani na inaelekea wapi

Soma mnyororo wa viungo kabla ya kubadilisha chochote, kwa sababu umiliki huamua faili gani lina mamlaka. Kila amri iliyo hapa chini husoma hali tu.

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

Mstari wa kwanza huchapisha kiungo na lengo lake pamoja, na faili ya kawaida inayomilikiwa na script ya VPN ina maana kitatuzi huwahi kuchukua maandishi hayo kama ingizo. Matokeo ya hali huorodhesha seva za kila kiungo pamoja na vikoa vya uelekezaji vinavyoamua kila swali linaenda wapi. Mstari wa nsswitch husema kama stub inashauriwa hata kidogo, kwa hiyo anwani ya stub kwenye faili bila resolve hapo ina maana maswali yanafika kwa msikilizaji wa ndani wakati hakuna kinachosimamia mgawanyo. Orodha hiyo ya mwisho pia ni muhimu, kwa sababu mwenyeji asiye na stub-resolv.conf haendeshi mpangilio ulioelezwa hapa.

Ikiwa mnyororo unaishia kwenye faili inayosimamiwa na kifurushi kingine, mteja wa VPN na kifurushi hicho ni wamiliki wawili wanaopaswa kupatanishwa. Kubadilisha kiungo hutupa kazi ya mmiliki mmoja na kuacha ya mwingine mahali pake.

Rekebisha kwa mmiliki wa kiungo

Muunganisho wa VPN unapaswa kusajili seva zake na vikoa vyake kwenye kiungo chake, kisha kuziondoa inapokatika. Muunganiko wa resolved wa NetworkManager na msaidizi wa mteja mwenyewe zote hufanya kazi hivyo; script inayoandika upya resolv.conf pekee haifanyi hivyo.

Kwenye kiungo kilichopo tayari, mipangilio ya wakati wa utekelezaji huonyesha utaratibu. resolvectl dns tun0 10.40.0.53 huambatanisha seva, na resolvectl domain tun0 '~corp.example' huambatanisha kikoa cha uelekezaji. Tilde (~) ni herufi inayobeba mzigo: huzuia maswali ya kiambishi hicho kwa kiungo hiki na kuacha kila kitu kingine kwa utulivu, ilhali thamani hiyo hiyo bila hiyo inakuwa kikoa cha utafutaji na mgawanyo hutoweka. Anwani hizo ni mifano ya maabara, si usanidi wa kudumu. Thibitisha kwa resolvectl query host.corp.example na soma ni kiungo kipi kilijibu.

Seva iliyosajiliwa bado inahitaji njia. Swali linapofika kwenye kiungo sahihi na muda unaisha, kasoro iko katika ufikivu kupitia handaki, si katika umiliki wa kitatuzi.

Hali inayofanya kazi inaonekanaje

Matokeo yenye afya ni thabiti katika maonyesho yote matatu: seva za kila kiungo zinalingana na kile VPN iligawanya, vikoa vya uelekezaji hufunika viambishi vya ndani pekee, na programu muhimu hutatua jina la ndani wakati jina la umma bado linafuata njia ya ndani. Swali moja lililofanikiwa linathibitisha kidogo kuliko makubaliano hayo.

Kisha kata muunganisho na urudie maswali yote mawili. Mteja anayeacha vikoa vyake vimesajiliwa baada ya kuvunjwa huzalisha mashine inayoshindwa katika utafutaji wa ndani saa kadhaa baadaye, bila handaki lililofunguliwa na bila sababu ya wazi.