Bakit hindi umabot sa DNS ng VPN ang iyong entry sa /etc/hosts

Nagdagdag ka ng pangalan sa /etc/hosts, kumonekta sa VPN at inaasahan mong lalabas ang record para sa lahat. Hindi ito nangyayari, at ang sorpresa ay kadalasang dumarating kasama ng pangalawang sintomas: ang pangalan ay nareresolba sa iyong makina at nabibigo sa makina ng katrabaho, na mukhang sirang serbisyo ng DNS ng VPN at sa katunayan ang file na hosts ay ginagawa lamang ang eksaktong disenyo nito. Ang file na hosts ay lokal na configuration ng resolusyon ng pangalan, hindi update ng zone, at walang anuman sa normal na koneksyon sa VPN ang nag-a-upload nito.

Ang hosts ay lokal na pagpapalit, hindi update ng zone

Ang file ay isang listahan ng mga mapping na kinokonsulta ng mga library ng serbisyo ng pangalan bago, o sa halip na, magtanong sa isang DNS server. Ang isang linya tulad ng 10.40.0.20 build.corp.example ay nagbabago ng konklusyon ng mga application sa nag-iisang makinang iyon. Hindi ito gumagawa ng record, hindi ito naglalakbay sa tunnel, at ang DNS server na tinuturo ng tunnel ay walang ideya na mayroon ito.

Kaya nga ang pagkabigo ay asimetriko. Nakakakuha ng sagot ang iyong client mula sa file. Ang ibang client ay nagtatanong sa DNS server ng VPN, na walang ibinabalik, at iniuulat ng application na wala ang pangalan. Pareho ang tamang pag-uugali ng dalawang makina; isa lang ang may pagpapalit na hindi pa nakita ng isa.

Dalawang utos, dalawang magkaibang bahagi

Ang pinakamabilis na paraan upang wakasan ang debate ay gawing nakikita ang pagkakaiba sa dalawang utos, parehong pinapatakbo sa client na may entry sa hosts:

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

Ang una ay nagtatanong sa sariling landas ng paghahanap ng system, na sa karaniwang sistemang glibc ay nagbabasa ng lokal na mga file bago ang DNS. Ang pangalawa ay nagpapadala ng DNS query nang direkta sa server sa address na iyon at hindi tumitingin sa lokal na mga file. Kapag ibinalik ng una ang iyong entry at ibinalik ng pangalawa ang NXDOMAIN, napatunayan mong wala ang record sa DNS at ang iyong makina ay sumasagot mula sa lokal na pagpapalit.

Ang pagkakasunud-sunod ay maaaring i-configure, at sulit itong suriin bago ka maghinuha ng anuman tungkol sa isang partikular na distribusyon. Tingnan ang linyang hosts: sa /etc/nsswitch.conf; ang hosts: files dns ay unang tumitingin sa mga file. Huwag kopyahin ang halimbawang iyon sa isang gumaganang configuration para lang baguhin ang pagkakasunud-sunod, dahil ang mga totoong system ay madalas na naglilista ng karagdagang pinagmulan at kondisyonal na entry ng serbisyo na wala sa halimbawa.

Ang systemd-resolved ay nagpapalabo ng pagsubok

Sa sistemang gumagamit ng systemd-resolved, ang lokal na stub ay nagseserbisyo rin ng mga pangalan mula sa database ng hosts. Kaya ang pagtatanong sa 127.0.0.53 ay hindi independiyenteng pagsubok ng malayong server, kahit mukhang DNS query ito at ganoon ang pag-uugali. Mabeberipika mo kung ano ang alam ng resolver at kung aling mga server ang tatanungin nito sa pamamagitan ng:

resolvectl query build.corp.example
resolvectl status

Pinangalanan ng output ng status ang mga DNS server bawat link, at sa ganoong paraan mo malalaman kung nakatanggap ng resolver ang link ng VPN. Ang tanong na iyon ay hiwalay sa entry sa hosts at iyon ang sulit itanong kapag ang pribadong pangalan ay nabibigo para sa lahat ng user at hindi para sa isa.

Ang mga application ay maaaring magdagdag ng isa pang layer. Ang browser na may sariling setting ng DNS-over-HTTPS, ang container na may sariling configuration ng resolver, o ang runtime na nag-cache ng mga paghahanap sa buong buhay ng proseso ay maaaring tumugon nang iba sa system. Subukan ang application na mahalaga sa iyo sa halip na ipagpalagay na inilalarawan ng isang utos ang bawat programa sa makina.

Ano ang tunay na nagbabahagi ng pangalan sa VPN

Kung ang pribadong pangalan ay kailangang gumana para sa lahat, kailangan nito ng may-ari na maabot ng resolver ng lahat. Ang malinaw na sagot ay i-publish ang record sa pinamamahalaang zone at gawing nareresolba ang zone na iyon sa nilalayong landas ng DNS ng VPN. Pagkatapos, ang record ay may isang pinagmulan ng katotohanan, bakas ng audit at lifecycle, at walang kailangang tandaan kung aling laptop ang may lokal na pagpapalit.

Ang pamamahagi ng mga file na hosts ay lehitimong alternatibo, at ito ay pamamahala ng endpoint hindi serbisyo ng pangalan. Kung pipiliin mo ito, ang file ay dapat i-deploy, i-version at alisin ng kung ano man ang namamahala sa fleet, at dapat ilarawan ito nang gayon sa disenyo. Ang “pinangangasiwaan ito ng VPN” ay hindi paglalarawan ng prosesong iyon.

Ang dynamic na pagpaparehistro ng DNS ay ikatlong mekanismo, na may sariling mga pahintulot, pagpapatotoo ng update at tagal ng record. Hindi ito nagmumula sa entry sa hosts, at hindi rin ito nagmumula sa client na kumonekta lang, maliban kung ang server at client ay parehong naka-configure para gawin ito. Ang record na kusang lumilitaw ay senyales na may nag-enable ng secure na mga update at isang client na nagrerehistro sa sarili nito, at ang configuration na iyon ay kabilang sa design record at hindi sa thread ng troubleshooting. Kung walang makapagsabi kung sino ang may-ari ng setting na iyon, ituring ang awtomatikong record na hindi beripikado at panatilihin ang pinamamahalaang zone bilang pinagmulan ng katotohanan.

Ang naresolbang pangalan ay hindi ruta

Ang resolusyon ng pangalan at maabot ay magkaibang bagay, at ang lumang lokal na mapping ang klasikong paraan upang paghalo-haluin ang mga ito. Ang entry sa hosts na tumuturo sa address na lumipat ay patuloy na pipili ng lumang host matagal pagkatapos na maitama ang DNS, at ang sintomas ay mukhang pagkabigo ng routing sa isang pangalan na maayos na nareresolba.

Kaya kapag ang ulat ay “nareresolba ang pangalan ngunit hindi maabot ang serbisyo”, ihambing ang paghahanap ng system sa isang tahasang query sa DNS server ng VPN, pagkatapos ay suriin ang address na nakuha mo laban sa address na aktuwal na ginagamit ng serbisyo. Ang sanggunian ng systemd-resolved ay nagdodokumento ng lokal na pinagmulan na kinokonsulta nito, at iyon ang mapa na kailangan mo para sa paghahambing na iyon.

Pagkatapos ay ayusin ang pagpapalit sa pamamagitan ng may-ari nito. Ang pag-alis ng isang linya mula sa iyong sariling file na hosts ay walang ginagawa para sa labindalawang laptop na nakatanggap ng parehong linya mula sa isang script ng deployment, at iyon ang bersyon ng problemang ito na talagang nararanasan ng mga tao.