Kwa nini majina ya DNS ya faragha hushindwa kwenye wateja wa VPN na wapi pa kukagua

Unafumbua kompyuta ya mkononi katika chumba cha hoteli, unanzisha mteja, unaandika jina la seva ya faili ya ndani, na haupati kitu. Handaki linaripoti kuwa limeunganishwa, na ping kwa anwani ndani ya subnet hiyo hiyo bado inajibu, kwa hiyo usafirishaji wenyewe uko sawa. Jina pekee ndilo linaloshindwa, na pengo hilo hupunguza tatizo hadi sehemu mbili: ni kitatuzi kipi mteja aliuliza na kama jibu alilopata linaweza kurudi kupitia handaki. Rekebisha moja na uache lingine, na hitilafu inahama tu.

Kabla ya kuhariri wasifu wowote, thibitisha kile mteja anachofanya na jina. Kwenye Linux, resolvectl query files.corp.example huonyesha kiungo kipi na kitatuzi kipi kilitoa jibu. Kwenye Windows, Resolve-DnsName files.corp.example huonyesha seva iliyojibu na anwani iliyorudisha.

Soma jibu kabla ya kubadilisha chochote

Ikiwa jina linarudi kama NXDOMAIN katika milisekunde chache, swali halikufika kwenye ukanda wako kamwe na kitatuzi cha umma au cha hoteli ndicho kilijibu. Ikiwa linarudi baada ya kipindi kirefu, kuna kitu kinatupa mlango wa UDP 53 njiani na mteja mwishowe alirudi kwenye akiba. Ikiwa linajibu kwa anwani sahihi lakini muunganisho bado unakwama, utafutaji uko sawa na tatizo lako liko kwenye uelekezaji au kwenye huduma yenyewe.

Mgawanyo huo wa tatu huokoa saa moja ya kubahatisha. Pia hukuambia kama unapaswa kugusa VPN hata kidogo: jina linalotatuliwa hadi anwani sahihi ya faragha tayari limethibitisha njia ya kitatuzi, kwa hiyo kazi iliyobaki iko kwenye njia ya data.

Gawanya kitatuzi kutoka ndani ya handaki

Wateja wamegawanyika katika makundi mawili. Kundi moja linaweza kupewa kitatuzi na seva wakati muunganisho unaandaliwa; lingine huhifadhi mpangilio kwenye faili ya ndani ambayo hakuna lango linaloweza kuibadilisha kwa mbali.

OpenVPN liko katika kundi la kwanza. Kwenye seva, push "dhcp-option DNS 10.8.0.53" na push "dhcp-option DOMAIN corp.example" huteremka kupitia chaneli ya udhibiti, lakini tu ikiwa usanidi wa mteja bado umewezesha pull. Mteja aliyebadilishwa kwa mkono na kubeba pull-filter ignore "dhcp-option" hatawaona kamwe, na mstari huo mmoja unaeleza idadi ya kushangaza ya matukio ya «seva inaisukuma lakini kompyuta yangu haikubaliani».

WireGuard liko katika kundi la pili, kwa sababu itifaki haina mazungumzo ya chaguo kabisa. Kitatuzi na kikoa cha utafutaji huingia kwenye bloku [Interface] ya mteja mwenyewe kama DNS = 10.8.0.53, corp.example. wg-quick hutumia hiyo kupitia resolvconf au systemd-resolved, na kwenye Windows mteja rasmi husakinisha kanuni za NRPT ambazo zipo tu wakati handaki liko juu: Get-DnsClientNrptPolicy huziorodhesha, jambo linaloifanya kuwa njia ya haraka ya kuona kama mteja aliwahi kutumia faili yako.

IPsec/IKEv2 liko katikati. Programu-jalizi ya attr ya strongSwan inaweza kurudisha seva ya DNS iliyochukuliwa kutoka kwenye dimbwi, na mteja wa Windows kwa kawaida huikubali, lakini wasifu unaofunga seva yake ya majina mwenyewe hushinda chochote linalotolewa na lango. Kwenye mteja wa Linux hatua sawa ya mkono ni resolvectl dns wg0 10.8.0.53 ikifuatiwa na resolvectl domain wg0 '~corp.example'; zote mbili hutoweka pamoja na kiolesura, jambo ambalo ndilo unalotaka kwa mpangilio uliowekewa mipaka ya handaki.

Weka mipaka kwa kiambishi badala ya kumeza kila swali

Kuelekeza orodha yote ya vitatuzi vya mteja kwenye seva yako ya ndani ni rahisi na kwa kawaida si sahihi. Kisha kila jina la umma hutatuliwa kutoka kwenye njia ya kutoka ya kituo chako cha data, CDN hurudisha anwani za mbali, na hitilafu moja ya kitatuzi huondoa uvinjari wa mtumiaji pamoja nayo.

Tuma kiambishi cha faragha tu kuelekea ndani. Kwenye systemd-resolved, kikoa kinachoanza na ~ ni cha uelekezaji tu, kwa hiyo ~corp.example inamaanisha maswali chini ya kiambishi hicho huenda kwenye seva za kiungo hicho wakati kila kitu kingine kinaendelea kutumia mtandao halisi. Windows hufanya vivyo hivyo kwa kanuni za NRPT zilizowekewa mipaka ya nafasi ya majina, na macOS kwa faili ya kitatuzi ya ziada chini ya /etc/resolver/.

Majina ya multicast yanastahili jibu lao. Majina ya .local ni link-local kwa muundo (RFC 6762) na kiolesura cha tun cha hatua-kwa-hatua hakibeba kundi hilo la multicast, kwa hiyo kuongeza kitatuzi cha umma hakutayatangaza na kuuliza kitatuzi cha ndani cha unicast kuhusu hayo hurudisha NXDOMAIN. Kiakisi kama avahi katika hali ya kiakisi kinaweza kuunganisha sehemu mbili, lakini huo ni uamuzi wa upande wa seva ambao hakuna mteja anayeweza kuuomba. Ikiwa kichapishi au NAS lazima kifikike kwa jina, ipe rekodi ya A katika ukanda wako.

Thibitisha kuwa jibu linaweza kurudi

Jibu sahihi linaloelekeza kwenye anwani isiyofikika linaonekana kama tatizo la kitatuzi hadi ukague njia. Uliza kernel jibu litaenda wapi: ip route get 10.20.5.20 hutaja kiolesura na, kwa manufaa zaidi, anwani ya chanzo ambayo lingetumia.

Fuatilia anwani ya kitatuzi yenyewe. Mteja aliye na DNS = 10.8.0.53 kando ya AllowedIPs = 10.20.0.0/16 hutuma maswali yake kupitia NIC halisi, ambako hufa kimya, kwa sababu kitatuzi hakiko ndani ya kiambishi chochote kinachodaiwa na handaki. Tofauti hiyo ni hitilafu ya sababu moja inayojulikana zaidi katika eneo hili lote, na haionekani isipokuwa ulinganishe mpangilio wa DNS na viambishi vinavyoruhusiwa mstari kwa mstari.

Safu zinazopishana husababisha hitilafu kinyume. Jibu ni sahihi, njia ipo, na inaelekeza kwenye mwenyeji asiye sahihi, kwa sababu 192.168.0.0/24 nyumbani ni mahususi zaidi kuliko njia ya handaki kwenye safu hiyo hiyo. Namba upya upande mmoja au sukuma njia nyembamba zaidi, kisha thibitisha ngome ya moto na njia ya kurudi ya mwenyeji wa huduma; maelezo ya strongSwan kuhusu upelekaji yanahusu upande wa sysctl wa njia hiyo.

Vyeti ni ukaguzi tofauti wa utambulisho ambao watu huilaumu DNS. Ikiwa kivinjari kiripoti kutolingana kwa jina badala ya hitilafu ya utatuzi, utafutaji tayari ulifanya kazi na SAN kwenye cheti ndicho kinachohitaji kurekebishwa. Jaribu HTTPS dhidi ya jina, kamwe si dhidi ya IP uchi.

Jaribu tena kutoka kwa mteja, si kutoka kwa lango

Jaribu ndani ya programu ambayo mtumiaji analalamikia, kwa sababu utafutaji kwenye mstari wa amri hauthibitishi kuwa kivinjari kinapita njia hiyo hiyo. DNS salama ya Chrome na network.trr.mode ya Firefox vinaweza kukwepa kitatuzi cha mfumo kabisa, na vinapofanya hivyo, jina la faragha ama linashindwa au linavuja kwa kitatuzi cha umma. Kulinganisha resolvectl query na dig @10.8.0.53 files.corp.example iliyoendeshwa kwa mkono hukuambia ni lipi kati ya hayo mawili lililotokea.

Kisha tenganisha na unganisha tena kabla ya kusema imerekebishwa. Mipangilio iliyowekwa kwa mkono kwenye kiolesura hutoweka pamoja na kiolesura, na wasifu ulioonekana sawa tu kwa sababu ya mabadiliko ya ndani yaliyosahaulika utashindwa kwenye uanzishaji unaofuata.

Orodha fupi ya ukaguzi kwa mashine inayofuata: jina linatatuliwa kupitia kitatuzi cha handaki, kiambishi kimewekewa mipaka badala ya kimataifa, anwani ya kitatuzi iko ndani ya viambishi vinavyoruhusiwa, mwenyeji kutoka kwenye jibu hujibu kwenye mlango wa huduma, na cheti kinashughulikia jina aliloandika mtumiaji.