Чаму ваш запіс /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 лакальны заместнік таксама аддае імёны з базы даных hosts. Таму запыт да 127.0.0.53 не з’яўляецца незалежнай праверкай аддаленага сервера, хаця выглядае як запыт DNS і паводзіць сябе таксама. Пераканацца, што ведае развязальнік і да якіх сервераў ён будзе звяртацца, можна так:

resolvectl query build.corp.example
resolvectl status

Вывад status называе серверы DNS для кожнага звяна, і так вы даведаецеся, ці атрымала звяно VPN развязальнік наогул. Гэтае пытанне асобнае ад запісу hosts і менавіта яго варта задаваць, калі прыватнае імя не развязаецца ва ўсіх карыстальнікаў, а не ў аднаго.

Праграмы могуць дадаць яшчэ адзін пласт. Браўзер з уласнай наладай DNS-over-HTTPS, кантэйнер з уласнай канфігурацыяй развязальніка або асяроддзе выканання, якое кэшуе запыты на ўвесь час жыцця працэсу, могуць адказваць інакш, чым сістэма. Тэстуйце праграму, якая вам важная, а не мяркуйце, што адна каманда апісвае кожную праграму на машыне.

Што насамрэч дзеліць імя праз VPN

Калі прыватнае імя павінна працаваць для ўсіх, яму патрэбен уласнік, да якога можа дабрацца развязальнік кожнага. Чысты адказ — апублікаваць запіс у кіраванай зоне і зрабіць гэтую зону развязальнай праз прызначаны шлях DNS у VPN. Тады запіс мае адну крыніцу праўды, след аўдыту і жыццёвы цыкл, і нікому не трэба памятаць, які ноўтбук носіць лакальнае перавызначэнне.

Распаўсюджванне файлаў hosts — законная альтэрнатыва, і гэта кіраванне канчатковымі пунктамі, а не служба імёнаў. Калі вы выбіраеце яго, файл павінен разгортвацца, версіявацца і выдаляцца тым, што кіруе паркам, і менавіта так гэта павінна быць апісана ў дызайне. «VPN гэтым займаецца» — не апісанне гэтага працэсу.

Дынамічная рэгістрацыя DNS — трэці механізм, з уласнымі дазволамі, аўтэнтыфікацыяй абнаўлення і тэрмінам жыцця запісу. Яна не вынікае з запісу hosts і не вынікае з простага падключэння кліента, калі сервер і кліент не былі абодва наладжаны на гэта. Запіс, які з’яўляецца сам сабой, — сігнал, што хтосьці ўключыў бяспечныя абнаўленні і кліент, які рэгіструе сябе, і гэтая канфігурацыя належыць у запіс дызайну, а не ў галіну пошуку няспраўнасцей. Калі ніхто не можа назваць уласніка гэтай налады, лічыце аўтаматычны запіс неправераным і трымайце кіраваную зону як крыніцу праўды.

Развязанае імя — не маршрут

Развязанне імёнаў і дасяжнасць — розныя рэчы, і састарэлае лакальнае супастаўленне — класічны спосаб іх зблытаць. Запіс hosts, які паказвае на адрас, што пераехаў, будзе выбіраць састарэлы хост яшчэ доўга пасля выпраўлення DNS, і сімптом выглядае як збой маршрутызацыі на імені, якое добра развязаецца.

Таму калі справаздача гучыць як «імя развязаецца, але служба недасяжная», параўнайце сістэмны пошук з відавочным запытам да сервера DNS VPN, затым праверце адрас, які вы атрымалі, супраць таго, які служба фактычна выкарыстоўвае. Даведка па systemd-resolved апісвае лакальныя крыніцы, да якіх ён звяртаецца, і гэта мапа, патрэбная для такога параўнання.

Затым выпраўце перавызначэнне праз яго ўласніка. Выдаленне радка з вашага ўласнага файла hosts нічога не дае дванаццаці ноўтбукам, якія атрымалі той жа радок з сцэнара разгортвання, і гэта менавіта тая версія гэтай праблемы, якая ў людзей ёсць.