Зашто ваш унос у /etc/hosts не стиже до DNS-а VPN-а

Додали сте име у /etc/hosts, повезали се са VPN-ом и очекивали да се запис појави свима. То се не дешава, а изненађење обично долази са другим симптомом: име се разрешава на вашем рачунару, а код колеге не, што изгледа као покварена DNS услуга VPN-а, а заправо датотека hosts ради управо оно за шта је направљена. Датотека hosts је локална конфигурација разрешавања имена, не ажурирање зоне, и ништа у нормалној VPN вези је не отпрема.

Hosts је локално преписивање, не ажурирање зоне

Датотека је списак мапирања које библиотеке службе имена прегледају пре или уместо питања DNS сервера. Линија као 10.40.0.20 build.corp.example мења шта закључују апликације на том једном рачунару. Она не ствара запис, не путује кроз тунел, а DNS сервер на који тунел показује не зна да она постоји.

Зато је неуспех асиметричан. Ваш клијент добија одговор из датотеке. Други клијент пита DNS сервер VPN-а, који ништа не враћа, и апликација пријављује да име не постоји. Оба рачунара се понашају исправно; само један има преписивање које други никада није видео.

Две команде, две различите компоненте

Најбржи начин да зауставите расправу јесте да разлику учините видљивом у две команде, обе извршене на клијенту који има унос hosts:

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

Прва пита сопствени пут претраге система, који на типичном glibc систему чита локалне датотеке пре DNS-а. Друга шаље DNS упит директно серверу на тој адреси и уопште не консултује локалне датотеке. Када прва врати ваш унос, а друга NXDOMAIN, доказали сте да запис не постоји у DNS-у и да ваш рачунар одговара из локалног преписивања.

Редослед је конфигурабилан и вреди га проверити пре него што закључите било шта о одређеној дистрибуцији. Погледајте линију hosts: у /etc/nsswitch.conf; 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 сваког може да стигне. Чист одговор је објавити запис у управљаној зони и учинити ту зону разрешивом кроз предвиђени DNS пут VPN-а. Тада запис има један извор истине, траг ревизије и животни циклус, и нико не мора да памти који лаптоп носи локално преписивање.

Дистрибуција датотека hosts је легитимна алтернатива и то је управљање крајњим тачкама, а не служба имена. Ако је изаберете, датотеку мора да распореди, верзионише и уклони оно што управља флотом, и тако то треба описати у пројекту. „VPN се тиме бави“ није опис тог процеса.

Динамичка DNS регистрација је трећи механизам, са сопственим дозволама, аутентификацијом ажурирања и животним веком записа. Она не произилази из уноса hosts и не произилази ни из пуког повезивања клијента, осим ако су сервер и клијент оба конфигурисани за то. Запис који се сам појави сигнал је да је неко омогућио безбедна ажурирања и клијент који се сам региструје, и та конфигурација припада пројектном запису, а не нити за решавање проблема. Ако нико не може да наведе ко поседује то подешавање, третирајте аутоматски запис као непроверен и држите управљану зону као извор истине.

Разрешено име није рута

Разрешавање имена и достижност су одвојени, а застарело локално мапирање је класичан начин да их помешате. Унос hosts који показује на адресу која се преселила наставиће да бира застарели хост дуго након што је DNS исправљен, а симптом изгледа као грешка рутирања на имену које се добро разрешава.

Зато када извештај каже „име се разрешава, али услуга није доступна“, упоредите системску претрагу са експлицитним упитом ка DNS серверу VPN-а, а затим проверите добијену адресу са оном коју услуга заиста користи. Референца за systemd-resolved документује локалне изворе које прегледа, и то је мапа која вам је потребна за то поређење.

Затим исправите преписивање преко његовог власника. Уклањање линије из ваше сопствене датотеке hosts не чини ништа за дванаест лаптопа који су исту линију добили из скрипте за распоређивање, и то је верзија овог проблема коју људи заиста имају.