DNS ya VPN inafanya kazi, lakini majina ya .local bado yanashindwa: nani anayasuluhisha?

Mashine mbili kwenye VPN moja, jina moja la mwenyeji, na ni moja tu inayolisuluhisha: tofauti kawaida si handaki bali ni kizuguzi kipi kilijibu. Kwenye desktop ya Linux jina hilo linaweza kupita kwenye swichi ya huduma za majina, kupitia stub ya systemd-resolved, au kupitia kizuguzi ambacho programu ilikileta, na kila kimoja kinatumia kanuni yake kwa kiambishi kimoja. Ni kwenye kiambishi hasa kanuni zinatofautiana, kwa sababu .local si lebo isiyoegemea upande wowote. Tambua ni njia ipi programu inayoshindwa inachukua kwa kweli kabla ya kubadilisha mpangilio wa kitu chochote.

Vizuguzi viwili, majibu mawili tofauti

Utafutaji wa jadi wa glibc unapita kwenye mstari wa hosts: katika nsswitch.conf na kuuliza kila moduli kwa zamu hadi moja ijibu. Mteja anayezungumza na systemd-resolved kupitia kiskilizaji cha stub huuliza badala yake mchakato mmoja, na mchakato huo unatumia sera kwa kila kiungo pamoja na kesi zake maalum. Programu inayoleta kizuguzi chake mwenyewe, au inayounganisha maktaba inayofanya hivyo, inaweza kupita vyote viwili. Kwa hivyo jina moja la mwenyeji linaweza kuwa na wamiliki watatu kwenye mashine moja, na ni mmoja tu anajua VPN ilikusudia nini.

Tambua mmiliki kabla ya kubadilisha chochote, kwa sababu suluhisho ni tofauti kwa kila mmoja wa watatu. Kivinjari na chombo cha mstari wa amri kwenye desktop moja vinaweza kutokubaliana kihalali, na kutokubaliana huko ni kidokezo, si hitilafu. Ikiwa kivinjari kinasuluhisha jina na chombo hakifanyi, unasuluhisha njia ya kizuguzi na si njia ya VPN. Thibitisha njia kando, ili hitilafu ya uelekezaji isichukuliwe kama hitilafu ya huduma ya majina. Wakati zote mbili zinakubaliana, hitilafu iko juu ya mwenyeji na usanidi wa kizuguzi hapa haustahili uhariri mwingine.

Amri ipi iliuliza kizuguzi chako kwa kweli

Amri mbili za kusoma tu zinajibu maswali yanayohusiana, na kuzilinganisha kunabaini tatizo kwa haraka zaidi kuliko kusoma usanidi. Tumia jina halisi la ndani na uweke matokeo faragha, kwa sababu rekodi za ndani zinabaki za ndani. Endesha zote mbili katika kikao kilekile ambacho programu inayoshindwa inaendeshwa:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

Ya kwanza inauliza kupitia moduli zilizosanidiwa, ambayo ni kile programu ya kawaida hukumbana nacho. Ya pili inauliza moja kwa moja systemd-resolved na kuripoti kiungo, itifaki na seva iliyojibu. Kuuliza seva ya kampuni kwa anwani kunathibitisha tu kwamba seva ina rekodi, kwa sababu haisemi chochote kuhusu kama programu iliwahi kuiuliza. Soma kiungo kinachobeba VPN na vikoa inavyodai, kisha linganisha orodha hiyo na kiambishi kwenye jina linaloshindwa.

Kwa nini .local inapita eneo lako la unicast

marejeleo ya systemd-resolved inasema kwamba majina ya lebo nyingi yanayoishia kwa .local kawaida huenda kwenye DNS ya multicast wakati mDNS imewashwa, badala ya DNS ya kawaida ya unicast. RFC 6762 inatenga nafasi hiyo ya majina kwa multicast ya kiungo cha ndani, hivyo eneo la kampuni linaweza kuwa na rekodi sahihi ambayo haiulizwi kamwe kwa kiambishi hicho. Handaki linaweza kuelekeza kizuguzi kikamilifu na bado likashindwa mbio. Ping inayofanikiwa kutoka kwenye akiba haisemi chochote kuhusu utafutaji uliotokea sasa hivi.

Kuna ubaguzi ulioandikwa, na hutatua mengi ya kesi hizi: kiungo kinapotangaza kiambishi hicho kama kikoa cha utafutaji au kikoa cha uelekezaji, daemon huweka kwenye njia ya unicast na kuruka kesi maalum ya multicast. Hiyo ni sera kwa kila kiungo na si upendeleo wa kimataifa. Mashine mbili zilizo na seva moja ya VPN zinaweza kuwa na tabia tofauti wakati wasifu mmoja wa mtandao unatangaza kikoa na mwingine hautangazi, kwa hivyo soma wasifu unaotumika na si ule unaokumbuka kuuhariri.

Ubaguzi mwembamba unashinda upangaji upya wa kimataifa

Kwa eneo lililopo ambalo huwezi kulibadilisha jina, waambie wamiliki wa kizuguzi na VPN watangaze kikoa kwenye muunganisho unaolibeba. Kuingiza kikoa cha uelekezaji kwa kiambishi hicho kimoja pamoja na anwani ya seva inayokusudiwa ni badiliko dogo lenye mmiliki aliyetajwa, na linaishi na kiungo badala ya faili lililohaririwa kwa mkono.

Pia hustahimili kukatika, kwa sababu sera ya kiungo hutumika tena kiungo kinaporejea. Kuhariri nsswitch.conf inayoshirikiwa ni mbadala wa kuvutia na wa gharama kubwa, kwa sababu hubadilisha tabia ya utafutaji kwa kila jina kwenye mashine, ikiwa ni pamoja na ugunduzi wa ndani. Kuzima daemon ya multicast pia si sawa: huondoa tabia ya ndani bila kufundisha kizuguzi chochote kuhusu eneo la kampuni. Ikiwa huduma ni mpya na si ya kurithi, weka chini ya kikoa kidogo kinachodhibitiwa na shirika lako na ruka mashindano kabisa. Chagua ubaguzi mwembamba wakati jina limewekwa kwenye firmware au limechapishwa kwenye lebo, na chagua kikoa kidogo kipya wakati bado unadhibiti mteja.

Nini cha kuthibitisha baada ya badiliko

Thibitisha suluhisho kwa utafutaji wa programu yenyewe na si kwa chombo ulichoweka kwa ajili ya majaribio, na safisha akiba yoyote inayoweza kujibu badala yake. Kisha thibitisha njia ya kizuguzi na kiungo kilichotoa jibu. Mwisho angalia kwamba ugunduzi wa ndani unatenda kama kabla ya badiliko, kwa sababu printa inayoacha kuonekana ndiyo sehemu ambayo watu huiona mwisho. Amri hizi tatu hukagua jina, njia na utambulisho wa TLS kwa mpangilio huo:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

Anwani sahihi yenye cheti kibaya bado humfanya mteja mkali ashindwe, kwa hivyo angalia jina ambalo programu inatarajia baada ya utatuzi kufanya kazi. Thibitisha kwamba huduma inakubali miunganisho kutoka anwani ya VPN na si kutoka safu ya ofisi pekee. Andika wigo wa kikoa, seva na mmiliki katika nyaraka za muunganisho. Vinginevyo mtu anayefuata kukutana na hitilafu hii atakwenda kwenye uhariri uleule wa kimataifa ambao umeuepuka sasa hivi.