/etc/hosts жазбаңыз неге VPN-нің DNS-іне жетпейді

Сіз /etc/hosts-ке атау қостыңыз, VPN-ге қосылдыңыз және жазбаның бәріне көрінетінін күттіңіз. Олай болмайды, және таңырқау әдетте екінші симптоммен бірге келеді: атау сіздің машинаңызда шешіледі, әріптесіңіздің машинасында шешілмейді, бұл бұзылған VPN DNS қызметіне ұқсайды, ал шын мәнінде hosts файлы дәл сол үшін жасалған істі істеп жатыр. hosts файлы — жергілікті атау шешу конфигурациясы, аймақ жаңартуы емес, және қалыпты VPN қосылымында ештеңе оны жүктемейді.

Hosts — жергілікті басып жазу, аймақ жаңартуы емес

Файл — атау қызметі кітапханалары DNS серверінен сұрамас бұрын немесе оның орнына қарайтын сәйкестіктер тізімі. 10.40.0.20 build.corp.example сияқты жол сол бір машинадағы қолданбалардың қандай қорытындыға келетінін өзгертеді. Ол жазба жасамайды, туннельден өтпейді, және туннель сілтейтін DNS сервері оның бар екенін білмейді.

Сондықтан сәтсіздік асимметриялы. Сіздің клиентіңіз файлдан жауап алады. Басқа клиент VPN-нің DNS серверінен сұрайды, ол ештеңе қайтармайды, және қолданба атаудың жоқ екенін хабарлайды. Екі машина да дұрыс әрекет етеді; тек біреуінде ғана екіншісі ешқашан көрмеген басып жазу бар.

Екі команда, екі түрлі құрамдас

Бұл дауды тоқтатудың ең жылдам жолы — айырмашылықты екі командада көрнекі ету, екеуі де hosts жазбасы бар клиентте орындалады:

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

Біріншісі жүйенің өз іздеу жолынан сұрайды, ол қарапайым glibc жүйесінде DNS-тен бұрын жергілікті файлдарды оқиды. Екіншісі DNS сұрауын тікелей сол мекенжайдагы серверге жібереді және жергілікті файлдарға мүлдем қарамайды. Біріншісі сіздің жазбаңызды қайтарса, екіншісі NXDOMAIN қайтарса, сіз жазбаның DNS-те жоқ екенін және машинаңыз жергілікті басып жазудан жауап беретінін дәлелдедіңіз.

Тәртіп конфигурацияланады, және нақты дистрибутив туралы қандай да бір қорытынды жасамас бұрын оны тексерген жөн. /etc/nsswitch.conf ішіндегі hosts: жолын қараңыз; hosts: files dns алдымен файлдарға қарайды. Тек тәртіпті өзгерту үшін бұл мысалды жұмыс істеп тұрған конфигурацияға көшірмеңіз, өйткені нақты жүйелер мысалда жоқ қосымша көздер мен шартты қызмет жазбаларын жиі тізіп жатады.

systemd-resolved тестінің анықтығын бұзады

systemd-resolved пайдаланатын жүйеде жергілікті stub hosts дерекқорынан да атауларды ұсынады. Сондықтан 127.0.0.53-ке сұрау жасау қашықтағы сервердің тәуелсіз тесті емес, бұл DNS сұрауына ұқсайды және солай әрекет етсе де. Resolver не білетінін және қай серверлерден сұрайтынын мынамен растай аласыз:

resolvectl query build.corp.example
resolvectl status

status шығысы әр байланыс үшін DNS серверлерін атайды, осылайша VPN байланысы resolver алды ма, жоқ па соны білесіз. Бұл сұрақ hosts жазбасынан бөлек және жеке атау бір адамға емес, барлық пайдаланушыға шешілмегенде қоюға тұрарлық сұрақ.

Қолданбалар тағы бір қабат қоса алады. Өз DNS-over-HTTPS параметрі бар браузер, өз resolver конфигурациясы бар контейнер немесе процестің бүкіл өмірінде іздеулерді кэштегітін орындалу ортасы жүйеден бөлек жауап бере алады. Бір команда машинадағы әрбір бағдарламаны сипаттайды деп болжаудың орнына өзіңізге маңызды қолданбаны сынап көріңіз.

VPN арқылы атауды шын мәнінде не бөліседі

Жеке атау бәріне жұмыс істеуі керек болса, оған барлығының resolver-ы жете алатын иесі керек. Таза жауап — жазбаны басқарылатын аймақта жариялау және сол аймақты VPN-нің көзделген DNS жолы арқылы шешілетін ету. Сонда жазбаның бір ғана шындық көзі, аудит ізі және өмірлік циклі болады, және ешкім қай ноутбукта жергілікті басып жазу бар екенін есте сақтауға мәжбүр емес.

hosts файлдарын тарату — заңды балама, және бұл атау қызметі емес, соңғы нүктелерді басқару. Егер оны таңдасаңыз, файлды флотты басқаратын нәрсе орналастыруы, нұсқалауы және жоюы керек, және дизайнда дәл солай сипатталуы тиіс. «VPN мұны реттейді» — бұл процестің сипаттамасы емес.

Динамикалық DNS тіркеу — үшінші механизм, оның өз рұқсаттары, жаңарту аутентификациясы және жазбаның өмірлік мерзімі бар. Ол hosts жазбасынан туындамайды, және клиенттің жай ғана қосылуынан да туындамайды, егер сервер мен клиент екеуі де бұған конфигурацияланбаса. Өздігінен пайда болатын жазба — біреудің қауіпсіз жаңартуларды қосқанының және клиенттің өзін тіркейтінінің белгісі, және бұл конфигурация ақаулықтарды жою тақырыбында емес, дизайн жазбасында болуы керек. Егер бұл параметрдің иесін ешкім атай алмаса, автоматты жазбаны расталмаған деп қарастырыңыз және басқарылатын аймақты шындық көзі ретінде ұстаныңыз.

Шешілген атау — маршрут емес

Атауларды шешу мен қолжетімділік бөлек нәрселер, және ескірген жергілікті сәйкестік оларды шатастырудың классикалық жолы. Көшкен мекенжайға сілтейтін hosts жазбасы DNS түзетілгеннен көп кейін де ескірген хостты таңдауды жалғастырады, және симптом жақсы шешілетін атаудағы маршруттау ақауына ұқсайды.

Сондықтан есеп «атау шешіледі, бірақ қызмет қолжетімсіз» десе, жүйелік іздеуді VPN-нің DNS серверіне айқын сұраумен салыстырыңыз, содан кейін алған мекенжайды қызмет шын мәнінде пайдаланатын мекенжаймен тексеріңіз. systemd-resolved анықтамасы ол қарайтын жергілікті көздерді құжаттайды, және бұл салыстыру үшін керек карта сол.

Содан кейін басып жазуды оның иесі арқылы түзетіңіз. Өз hosts файлыңыздан бір жолды жою орналастыру скриптінен сол жолды алған он екі ноутбукке ештеңе істемейді, және адамдарда шын мәнінде осы мәселенің сол нұсқасы бар.