Kwa nini ingizo lako la /etc/hosts halifiki kwenye DNS ya VPN

Uliongeza jina kwenye /etc/hosts, ukajiunga na VPN na ukatarajia rekodi ionekane kwa kila mtu. Hilo halifanyiki, na mshangao kwa kawaida huja na dalili ya pili: jina linatatuliwa kwenye mashine yako na linashindwa kwa mwenzako, jambo ambalo linaonekana kama huduma ya DNS ya VPN iliyovunjika na kwa kweli faili ya hosts inafanya kile ilichoundwa kufanya. Faili ya hosts ni usanidi wa ndani wa utatuzi wa majina, si sasisho la eneo, na hakuna kitu katika muunganisho wa kawaida wa VPN kinachoiweka juu.

Hosts ni ubatilishaji wa ndani, si sasisho la eneo

Faili ni orodha ya ramani ambazo maktaba za huduma ya majina hushauriana nazo kabla ya, au badala ya, kuuliza seva ya DNS. Mstari kama 10.40.0.20 build.corp.example hubadilisha kile ambacho programu kwenye mashine hiyo moja huhitimisha. Hauiundi rekodi, hausafiri kupitia handaki, na seva ya DNS ambayo handaki inaelekeza haijui kabisa kwamba ipo.

Ndiyo sababu kushindwa ni kutofautiana. Mteja wako hupata jibu kutoka kwenye faili. Mteja mwingine huuliza seva ya DNS ya VPN, ambayo hairudishi kitu, na programu huripoti kwamba jina halipo. Mashine zote mbili zinafanya kwa usahihi; moja tu ina ubatilishaji ambao mwingine hakuwahi kuona.

Amri mbili, sehemu mbili tofauti

Njia ya haraka zaidi ya kusimamisha mjadala ni kufanya tofauti ionekane katika amri mbili, zote mbili zikitekelezwa kwenye mteja aliye na ingizo la hosts:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

Ya kwanza huuliza njia ya utafutaji ya mfumo wenyewe, ambayo kwenye mfumo wa kawaida wa glibc husoma faili za ndani kabla ya DNS. Ya pili hutuma hoja ya DNS moja kwa moja kwa seva iliyo katika anwani hiyo na haishauriani na faili za ndani hata kidogo. Wakati ya kwanza inarudisha ingizo lako na ya pili inarudisha NXDOMAIN, umethibitisha kwamba rekodi haipo kwenye DNS na kwamba mashine yako inajibu kutoka kwa ubatilishaji wa ndani.

Mpangilio unaweza kusanidiwa, na inafaa kuuangalia kabla ya kuhitimisha chochote kuhusu usambazaji fulani. Angalia mstari wa hosts: katika /etc/nsswitch.conf; hosts: files dns hushauriana na faili kwanza. Usinakili mfano huo juu ya usanidi unaofanya kazi kwa sababu tu ya kubadilisha mpangilio, kwa sababu mifumo halisi mara nyingi huorodhesha vyanzo vya ziada na maingizo ya huduma yenye masharti ambayo mfano hauna.

systemd-resolved hufifisha jaribio

Kwenye mfumo unaotumia systemd-resolved, stub ya ndani pia huhudumia majina kutoka hifadhidata ya hosts. Kwa hiyo hoja kwa 127.0.0.53 si jaribio huru la seva ya mbali, ingawa inaonekana kama hoja ya DNS na hufanya hivyo. Unaweza kuthibitisha kile kitatuzi kinachojua na ni seva zipi itauliza kwa:

resolvectl query build.corp.example
resolvectl status

Matokeo ya status hutaja seva za DNS kwa kila kiungo, na hivyo ndivyo unavyogundua kama kiungo cha VPN kilipata kitatuzi hata kidogo. Swali hilo ni tofauti na ingizo la hosts na ndilo linalofaa kuulizwa wakati jina la kibinafsi linashindwa kwa kila mtumiaji na si kwa mmoja.

Programu zinaweza kuongeza tabaka jingine. Kivinjari chenye mpangilio wake wa DNS-over-HTTPS, kontena yenye usanidi wake wa kitatuzi, au mazingira ya utekelezaji yanayohifadhi utafutaji katika kumbukumbu kwa muda wote wa mchakato kila kimoja kinaweza kujibu tofauti na mfumo. Jaribu programu unayojali badala ya kudhani kwamba amri moja inaelezea kila programu kwenye mashine.

Ni nini hasa kinachoshiriki jina kupitia VPN

Ikiwa jina la kibinafsi linapaswa kufanya kazi kwa kila mtu, linahitaji mmiliki ambaye kitatuzi cha kila mtu kinaweza kumfikia. Jibu safi ni kuchapisha rekodi katika eneo linalosimamiwa na kufanya eneo hilo litatuliwe kupitia njia ya DNS ya VPN inayokusudiwa. Hapo rekodi inakuwa na chanzo kimoja cha ukweli, athari ya ukaguzi na mzunguko wa maisha, na hakuna anayelazimika kukumbuka laptop ipi inabeba ubatilishaji wa ndani.

Kusambaza faili za hosts ni mbadala halali, na ni usimamizi wa vituo vya mwisho na si huduma ya majina. Ukichagua hivyo, faili lazima isambazwe, ipewe toleo na iondolewe na kile kinachosimamia kundi, na inapaswa kuelezewa hivyo katika muundo. “VPN inashughulikia hilo” si maelezo ya mchakato huo.

Usajili wa DNS unaobadilika ni utaratibu wa tatu, ukiwa na ruhusa zake, uthibitishaji wa masasisho na muda wa maisha wa rekodi. Hautokani na ingizo la hosts, na hautokani pia na mteja kuunganisha tu, isipokuwa seva na mteja wote wawili wamesanidiwa kufanya hivyo. Rekodi inayojitokeza yenyewe ni ishara kwamba mtu amewezesha masasisho salama na mteja anayejisajili yenyewe, na usanidi huo unapaswa kuwa katika rekodi ya muundo na si kwenye uzi wa utatuzi wa matatizo. Ikiwa hakuna anayeweza kutaja mmiliki wa mpangilio huo, chukulia rekodi ya kiotomatiki kuwa isiyothibitishwa na uweke eneo linalosimamiwa kama chanzo cha ukweli.

Jina lililotatuliwa si njia

Utatuzi wa majina na ufikivu ni mambo tofauti, na ramani ya ndani iliyopitwa na wakati ndiyo njia ya kawaida ya kuvichanganya. Ingizo la hosts linaloelekeza kwenye anwani iliyohama litaendelea kuchagua mwenyeji aliyepitwa na wakati muda mrefu baada ya DNS kusahihishwa, na dalili inaonekana kama kushindwa kwa uelekezaji kwenye jina linalotatuliwa vizuri.

Kwa hiyo wakati ripoti inasema “jina linatatuliwa lakini huduma haifikiki”, linganisha utafutaji wa mfumo na hoja ya wazi kwa seva ya DNS ya VPN, kisha angalia anwani uliyopata dhidi ya ile ambayo huduma inatumia kweli. Rejea ya systemd-resolved inaandika vyanzo vya ndani inavyoshauriana navyo, na hiyo ndiyo ramani unayohitaji kwa ulinganisho huo.

Kisha rekebisha ubatilishaji kupitia mmiliki wake. Kuondoa mstari kutoka kwenye faili yako ya hosts hakufanyi chochote kwa laptop kumi na mbili zilizopata mstari huo huo kutoka kwa skripti ya usambazaji, na hicho ndicho toleo la tatizo hili ambalo watu wanalo kweli.