DNS праз VPN працуе, але імёны .local усё яшчэ не развязваюцца: хто іх развязвае?

Дзве машыны ў адным VPN, адно імя хоста, і толькі адна з іх развязвае яго: розніца звычайна не ў тунелі, а ў тым, які рэзалвер адказаў. На працоўным стале Linux гэтае імя можа прайсці праз пераключальнік службы імёнаў, праз заглушку systemd-resolved або праз рэзалвер, які прыкладанне прынесла з сабой, і кожны з іх прымяняе сваё правіла да аднаго і таго ж суфікса. Менавіта на суфіксе правілы разыходзяцца, бо .local не з’яўляецца нейтральнай меткай. Вызначце, які шлях насамрэч праходзіць праграма, што памыляецца, перш чым змяняць парадак, у якім што-небудзь запушчана.

Два рэзалверы, два розныя адказы

Традыцыйны пошук glibc ідзе па радку hosts: у nsswitch.conf і пытаецца ў кожнага модуля па чарзе, пакуль адзін не адкажа. Кліент, які размаўляе з systemd-resolved праз заглушку-слухач, пытаецца замест гэтага ў аднаго працэса, і гэты працэс прымяняе палітыку для кожнага злучэння плюс свае ўласныя асаблівыя выпадкі. Прыкладанне, якое пастаўляе свой рэзалвер або звязвае бібліятэку, што робіць гэта, можа абысці абодва. Такім чынам, адно імя хоста можа мець трох гаспадароў на адной машыне, і толькі адзін з іх ведае, што меў на ўвазе VPN.

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

Якая каманда насамрэч спытала ваш рэзалвер

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

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

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

Чаму .local абыходзіць вашу зону unicast

даведка systemd-resolved кажа, што шматметкавыя імёны, якія заканчваюцца на .local, звычайна ідуць у multicast DNS, калі mDNS уключаны, а не ў звычайны unicast DNS. RFC 6762 адводзіць гэтую прастору імёнаў для link-local multicast, таму карпаратыўная зона можа трымаць правільны запіс, да якога для гэтага суфікса ніколі не звяртаюцца. Тунель можа ідэальна маршрутызаваць рэзалвер і ўсё роўна прайграць гонку. Паспяховы ping з кэша нічога не кажа пра пошук, які толькі што адбыўся.

Ёсць дакументаванае выключэнне, і яно вырашае большасць такіх выпадкаў: калі злучэнне абвяшчае гэты суфікс як пошукавы дамен або дамен маршрутызацыі, дэман трымае яго на шляху unicast і прапускае асаблівы выпадак multicast. Гэта палітыка для кожнага злучэння, а не глабальная перавага. Дзве машыны з адным серверам VPN могуць паводзіць сябе па-рознаму, калі адзін профіль сеткі абвяшчае дамен, а другі не, таму чытайце актыўны профіль, а не той, які вы памятаеце як адрэдагаваны.

Вузкае выключэнне лепш за глабальную перастаноўку

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

Яно таксама перажывае адключэнне, бо палітыка злучэння прымяняецца зноў, калі злучэнне вяртаецца. Рэдагаванне агульнага nsswitch.conf — спакуслівая і больш дарагая альтэрнатыва, бо яно змяняе паводзіны пошуку для кожнага імя на машыне, уключаючы мясцовае выяўленне. Адключэнне дэмана multicast таксама не эквівалентнае: яно прыбірае мясцовыя паводзіны, не вучачы ніводны рэзалвер пра карпаратыўную зону. Калі служба новая, а не ўспадкаваная, змясціце яе ў паддамен, які кантралюе ваша арганізацыя, і цалкам прапусціце спаборніцтва. Выбірайце вузкае выключэнне, калі імя зафіксавана ў прашыўцы або надрукавана на этыкетцы, і выбірайце новы паддамен, калі вы ўсё яшчэ кантралюеце кліента.

Што даказаць пасля змены

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

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

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