Kwa nini majina ya mwenyeji wa ndani hutatuliwa katika dig lakini hushindwa katika curl kwenye VPN

Laptop yako iko kwenye VPN, dig service.internal.example hujibu kwa anwani ya 10.x, na curl bado hutoka na Could not resolve host. Handaki si tatizo: ilibeba swali la dig bila malalamiko. Tofauti ni nani anayeuliza swali. dig hutuma swali moja kwa seva moja unayoitaja, wakati curl hupitia mnyororo wa utafutaji wa mfumo wa uendeshaji, na mnyororo huo una sheria zake kuhusu seva ipi inauliwa.

Utafutaji mbili kwa jina moja

dig ni stub resolver yake yenyewe. Husoma /etc/resolv.conf, huchagua seva ya majina, hutuma swali moja la A au AAAA na huchapisha jibu. Hupita nsswitch kabisa na haijui chochote kuhusu hali ya kila kiungo ambayo systemd-resolved au NetworkManager huweka nje ya faili hilo, ndiyo sababu jibu la dig linaweza kuwa sahihi na bado lisikwambie chochote kuhusu kile ambacho programu yako itaona.

Programu huita getaddrinfo, na getaddrinfo hupitia mnyororo mrefu: mpangilio wa moduli za nsswitch, kisha moduli inayoshughulikia jina, na hatimaye resolver iliyojengwa kutoka kwa usanidi wa kiungo wa sasa. Kwenye mashine ya systemd swali huenda kwa 127.0.0.53 na systemd-resolved huchagua seva ya juu kwa kila kiungo kulingana na kikoa cha uelekezaji kilichounganishwa na kiolesura cha tun.

Amri mbili hutenganisha tabaka hizo bila kukisia:

getent ahosts service.internal.example
resolvectl query service.internal.example

getent hutumia njia sawa na curl, kwa hiyo kutofaulu kwa getent kando ya dig inayofanya kazi huweka hitilafu kwenye sera ya utafutaji na si kwenye uelekezaji wa pakiti. resolvectl query pia huchapisha kiolesura na seva ya juu iliyotoa jibu, jambo linaloonyesha kama kiungo cha handaki au kiungo halisi kilishinda uamuzi.

Soma resolver ambayo programu hutumia kweli

/etc/resolv.conf huzalishwa kwenye kompyuta nyingi za mezani, na mteja wa VPN ana njia tatu za kushughulika nayo: kuongeza seva ya majina mbele, kuandika juu ya faili, au kukabidhi seva zake kwa NetworkManager na kumruhusu daemon kuiandika upya. Mtindo wa tatu pekee huhifadhi DNS kwa kila kiungo, kwa sababu seva hubaki zimefungwa kwenye kiolesura badala ya kubanwa kuwa orodha moja ya kimataifa.

Kwenye mifumo ya NetworkManager matokeo hutegemea backend iliyo katika /etc/NetworkManager/NetworkManager.conf:

[main]
dns=systemd-resolved

Kwa dns=default seva za mteja huunganishwa kwenye resolv.conf kwa mpangilio unaoshinda, na utafutaji wa faragha bado unaweza kutumwa kwa resolver ya umma. Kwa backend inayoelewa viungo, systemd-resolved au dnsmasq, seva za handaki hubaki zimefungwa kwenye handaki na ni majina yanayolingana na kikoa chake cha uelekezaji pekee yanayoenda huko. Uwekaji huo ndio maana ya split DNS kivitendo, na ndicho kipande kinachokosekana mara nyingi zaidi mteja anapodai kuunga mkono.

Soma hali kabla ya kubadilisha chochote:

resolvectl status
resolvectl dns tun0

Unataka kuona kiolesura cha tun kimeorodheshwa na seva ya DNS na kikoa cha uelekezaji kwa kiambishi cha faragha, kikionyeshwa kama ~internal.example. Hakuna seva kwenye kiungo inamaanisha mteja hakuituma chochote. Seva isiyo na kikoa inamaanisha utafutaji wote huenda huko au hakuna kabisa, kulingana na mteja, na hakuna kati ya hizo mbili ni split DNS.

Mahali nsswitch humaliza utafutaji mapema mno

Mstari wa kawaida wa kompyuta ya mezani unaonekana hivi:

hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname

mdns4_minimal hushughulikia multicast DNS na hudai kila jina linaloishia .local. Huduma ya Kubernetes kama api.infra.svc.cluster.local pia inaishia .local. Wakati moduli ya mDNS inaripoti NOTFOUND, kitendo [NOTFOUND=return] humaliza utafutaji wote badala ya kuendelea hadi moduli ya dns, kwa hiyo jina hilo halitumwa kamwe kwa resolver ya VPN. dig huizunguka faili kabisa, na ndiyo sababu zana hizo mbili hazikubaliani.

Huo ni utofautishaji mkali zaidi katika tatizo hili, na unashuka hadi neno moja katika faili ya usanidi iliyozeeka kuliko VPN yako. Kubadilisha kitendo kuwa [NOTFOUND=continue] huhifadhi mDNS kwa printa na vifaa vya ndani huku ukiruhusu DNS kuona jina. Kubadilisha mstari na hosts: files dns pia hufanya kazi na ni mbaya zaidi: huacha utatuzi wa .local kwa printa unayotumia kweli.

Majina yanayoishi katika mtandao mmoja tu

Kanda za faragha zina mamlaka mahali pamoja tu. Jina la AWS kama ip-10-0-4-31.eu-west-1.compute.internal hujibiwa kupitia resolver ya VPC ya eneo hilo, na ni wakati tu ambapo kituo cha mwisho cha VPN yako kiko katika eneo moja na rasilimali. Unganisha kwa kituo cha Frankfurt, uliza jina la compute.internal kutoka Ireland, na hakuna mpangilio wowote wa ndani utakaosaidia: kanda iliyo na rekodi haifikiki kutoka hapo.

Vikoa vya utafutaji huzalisha picha ya kioo. service tupu hukamilishwa na kiambishi ambacho resolver huona kinafaa, na kwa kiungo cha VPN kikoa cha ndani kinaweza kushinda cha shirika. Uliza kwa nukta mwishoni ili kuondoa kukisia, getent ahosts service.internal.example., na ikiwa hilo linafanya kazi wakati jina fupi linashindwa, marekebisho ni kikoa cha utafutaji kwenye handaki, si anwani ya seva.

Wateja wanaosimamiwa huongeza tabaka la tatu juu ya resolver ya mfumo. Profaili ya VPN ya Windows inaweza kubeba sera yake ya utatuzi wa majina, sheria kwa kila programu na jedwali la NRPT linalotumika hata handaki ikiwa imezimwa. Programu zilizo na akiba yao ya DNS, zilizo kawaida katika mazingira ya .NET na Java, huweka kosa lililopitwa na wakati kwa muda mrefu baada ya mnyororo kurekebishwa. Wateja wa Apple husanidi split DNS kupitia vikoa vinavyolingana katika mipangilio ya DNS badala ya resolv.conf, na Chromium au Firefox katika hali ya DNS salama zinaweza kupita resolver ya mfumo kwa majina ya umma. Rejeleo la Microsoft kuhusu utatuzi wa majina ya VPN linaeleza upande wa Windows wa tabaka hilo la sera.

Amua ni tabaka gani la kurekebisha

Fanya kazi kutoka kwa dalili kuelekea tabaka badala ya kujaribu marekebisho kwa mfuatano:

Mistari miwili hubeba mzigo mwingi. Muda wa kumalizika ni tatizo la ufikivu: resolver ya faragha haijibu kupitia handaki, kwa hiyo angalia njia hadi anwani yake na kama seva ya DNS kwenye kiungo ni ile unayofikiri. NXDOMAIN ni tatizo la mamlaka: kitu kilijibu na hakijui jina, jambo linaloelekeza kwenye kanda, eneo au resolver ambayo haikupaswa kupokea swali hilo.

Mstari wa mwisho ndio ambao watu huukosa kwa sababu nusu zote mbili zinaonekana kama mafanikio. Jina fupi linalotatuliwa tofauti na FQDN ni kutokulingana kwa kiambishi, na kuunganisha tena handaki hakutabadilisha kiambishi ambacho mteja hutuma.

Rekodi hali kabla ya kuhariri faili ya usanidi, ili uweze kusema kama uhariri ulifanya chochote:

resolvectl status > before.txt
getent ahosts service.internal.example >> before.txt

Endesha ukaguzi kwa mpangilio huu na usimame kwenye kosa la kwanza. getent na resolvectl query lazima zikubaliane; ikiwa getent inashindwa wakati dig inajibu, baki kwenye mnyororo wa utafutaji na usiguse uelekezaji. resolvectl status lazima ionyeshe seva ya DNS na kikoa cha uelekezaji kwenye kiolesura cha tun. nsswitch haipaswi kurudi mapema na NOTFOUND kwa kiambishi unachojaribu. Jina lazima liwe na mamlaka katika mtandao ambao kituo chako kimeunganishwa, limejaribiwa kwa nukta mwishoni. Programu haipaswi kuweka akiba yake au ubatilishaji wa DNS salama.

Rekebisha tabaka la kwanza linaloshindwa pekee, kisha endesha tena amri zile zile. Mabadiliko mawili kwa wakati mmoja hukuzuia kusema lipi lililo muhimu, na hitilafu inayofuata huanza uchunguzi kutoka sufuri.