Majina ya ndani yanashindwa kwenye VPN wakati tovuti za umma zinatatuliwa

Mtumiaji mmoja anaripoti kwamba jina la mwenyeji wa intranet halitatuliwi kupitia VPN. Ripoti ya pili, kutoka kwa kompyuta hiyo hiyo, inasema jaribio la uvujaji bado linaonyesha maulizo yanayojibiwa na kisuluhishi cha ndani. Zinasikika kama tatizo moja lakini ni mawili, na ushahidi tofauti, na matengenezo ya kawaida ya la kwanza hufanya la pili kuwa baya zaidi. Tenganisha kabla ya kugusa mpangilio wowote.

Dalili mbili ambazo si hitilafu moja

Kushindwa kutafsiri jina la ndani kunamaanisha swali lilienda mahali pasipo na jibu lake. Maulizo yanayotoka kwenye handaki yanamaanisha swali lilienda mahali pasipo sahihi hata wakati jibu lilikuwa linapatikana. Hizo ni hitilafu kinyume: moja ni jibu linalokosekana, nyingine ni mwisho wa ziada.

Mtego ni kwamba kuongeza kisuluhishi cha ofisi kila mahali hutengeneza la kwanza na huhakikisha la pili. Kuongeza kisuluhishi cha umma kila mahali hufanya kinyume chake.

Andika uchunguzi wote wawili na muhuri wa muda, kisha pitia ukaguzi nne zifuatazo kwa mpangilio.

Kisuluhishi cha adapta ipi kinapata swali

Kwenye Windows, mteja wa DNS huchagua seva kulingana na mpangilio wa kufunga adapta, na adapta ya handaki haiko mbele kiotomatiki. Fungua mipangilio ya hali ya juu ya adapta na usonge muunganisho wa ufikiaji wa mbali juu ya adapta halisi, kisha unganisha tena ili mabadiliko yatumike kwa kipindi kipya.

Mpangilio wa kufunga ni nusu ya kwanza tu. Mteja pia lazima ajue majina yapi ni ya adapta hiyo, na hilo ni swali la kiambishi badala ya swali la mpangilio.

Weka ipconfig /all ya mashine inayofanya kazi kando ya ya kompyuta, zote zikichukuliwa wakati handaki imefunguliwa. Mashine inayofanya kazi itaonyesha kiambishi cha DNS maalum cha muunganisho kwenye adapta yake ya ofisi, na kompyuta inaweza kutoonyesha chochote kwenye handaki. Tofauti hiyo inaeleza daraja zima la ripoti za aina ya "seva iko pale na jina bado linashindwa", kwa sababu bila kiambishi jina fupi halikamilikiwi kamwe ndani ya ukanda ambao kisuluhishi cha ofisi kinahudumia.

Jina fupi linahitaji kiambishi kabla ya kuhitaji njia

Kuandika jina la mwenyeji lisilostahili huuliza kisuluhishi kukisia kikoa. Kisio linatoka kwenye orodha ya viambishi iliyoambatishwa na muunganisho, na ikiwa orodha hiyo ni tupu swali linatoka kama lebo moja ambayo hakuna ukanda wa kibinafsi utakaolingana nayo.

Nakili kiambishi cha mashine inayofanya kazi ndani ya sifa za IPv4 za adapta ya VPN kwenye kichupo cha DNS, kisha unganisha tena. Kwenye Linux sawa ni kikoa cha utafutaji kwenye kiungo cha handaki, ambacho systemd-resolved hukifichua kwa kila kiungo badala ya kimataifa.

Tenganisha mipangilio hiyo miwili kwenye madokezo yako. Kiambishi hubadilisha kinachoulizwa; anwani ya kisuluhishi hubadilisha nani anaulizwa. Kutengeneza kimoja wakati kingine si sahihi hutoa matokeo yanayofanana na ya nasibu.

Uliza kisuluhishi moja kwa moja, kisha jina

Swali la moja kwa moja kwa kisuluhishi cha ofisi hutenganisha tatizo la jina na tatizo la njia, kwa sababu linapita kabisa uteuzi wa kisuluhishi wa mteja.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Amri ya kwanza inauliza seva maalum kuhusu jina lililostahili kikamilifu. Ikijibu, kisuluhishi na njia ya kufika kwake ziko sawa na hitilafu iko kwenye uteuzi au kiambishi. Ikishindwa kwa muda, anwani si sahihi au haifikiki na tatizo ni uelekezaji, si DNS. Amri ya pili inaonyesha kinachotokea na jina fupi, na ya tatu huchapisha usanidi wa kisuluhishi kwa kila kiungo kwenye mwenyeji wa systemd.

Angalia majibu ya alama ya kijoker, ambayo mitandao mingine huyarudisha kwa majina yasiyojulikana. Jibu linaloonekana la kueleweka si uthibitisho kwamba seva iliyokusudiwa ilijibu, kwa hivyo linganisha anwani iliyorudishwa na ile ambayo huduma ya ndani inatumia kweli. Ikiwa anwani ni ya ukurasa wa kuegesha au ya wakala, kisuluhishi kilijibu lakini jibu halikuwa lako kamwe. Tofauti hiyo huokoa saa moja ya kufukuza handaki iliyokuwa ikifanya kazi muda wote.

Kwenye Linux, mteja wa VPN anayeandika upya /etc/resolv.conf hubadilisha kisuluhishi cha ndani kabisa. vpnc hufichua DNSUpdate no ili kuzuia hilo, na systemd-resolved inaweza kuelekeza vikoa vilivyoorodheshwa pekee kwenye kiungo cha handaki. Mbinu zote mbili huweka majina ya umma kwenye kisuluhishi cha ndani huku zikituma majina ya ndani ofisini.

Uvujaji ni kanuni, si kisanduku cha kuti

Utatuzi wa majina ni mabadilishano ya UDP kwenda bandari 53, kwa hivyo handaki inayobeba trafiki ya wavuti lakini si UDP huacha swali kwenye njia halisi. Thibitisha kwa kunasa kwenye kadi halisi ya mtandao wakati jina la umma linatatuliwa. Swali linaloonekana kwenye kiolesura hicho kwa umbo linalosomeka linamaanisha handaki hailibebi.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Ikiwa swali linaonekana kwenye kiolesura hicho kwa umbo linalosomeka, handaki hailibebi. Matengenezo ni kanuni inayoruhusu bandari 53 tu kwa kisuluhishi kilichosukumwa na VPN na kutupa maeneo mengine, pamoja na usanidi wa mteja usiotupa kimyakimya chaguo lililosukumwa.

Sehemu ya mwisho ni muhimu zaidi kuliko inavyoonekana. Anzisha OpenVPN na route-nopull na chaguo la DNS lililosukumwa hupotea pamoja na njia, isipokuwa kichujio cha kuvuta kipanuliwe ili kukihifadhi. na mteja anayepuuza dhcp-option DNS ataendelea kutumia kile alichokuwa nacho awali. Mabadiliko yoyote upande wa seva yanahitaji kipindi kipya ili yaanze kutumika, kwa sababu orodha ya visuluhishi huwasilishwa handaki inapoinuka na kipindi cha zamani huendelea kuonyesha hali ya zamani.

Rekodi ni hitilafu ipi uliyoiona kweli kabla ya kufunga tikiti. Jibu la ndani linalokosekana na swali linalotoka kwenye handaki huhitaji matengenezo tofauti, na mabadiliko ya kiambishi yanayotengeneza la kwanza yanaweza kufanya la pili kuwa baya kimyakimya. Atakayechukua tikiti baadaye ataamini lebo, kwa hivyo ifanye lebo iwe sahihi.