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

Праверка першая: як пачынаецца злучэнне

Уладальнік злучэння вызначае, хто можа ўжыць налады рэзалвера. Прамая каманда openvpn з абалонкі не валодае нічым, акрамя свайго працэсу, а модуль systemd, NetworkManager ці кліент пастаўшчыка кожны мае свой спосаб публікацыі DNS. Прачытайце спіс працэсаў і назву модуля, перш чым меркаваць нешта з гэтага.

Працэс каманднага радка не абавязкова з'яўляецца злучэннем NetworkManager, а злучэнне NetworkManager не абавязкова тое, што запісала resolv.conf. Гэтыя два меркаванні тлумачаць большасць марна выдаткаваных гадзін у гэтым даследаванні. Спытайцеся, які кампанент апублікаваў бы DNS для інтэрфейсу, які вы сапраўды бачыце.

Запішыце ўладальніка, перш чым працягваць. Кожная наступная праверка залежыць ад яго.

Праверка другая: што насамрэч утрымлівае сувязь рэзалвера

На хосте з systemd-resolved resolvectl status пералічвае кожную сувязь з яе DNS-серверамі і даменамі. Знайдзіце сувязь тунеля і прачытайце яе запісы, і не меркуйце, што інтэрфейс завецца tun0, бо нумарацыя ідзе ў парадку стварэння. Калі перададзенага адраса няма ў сувязі, то не адбылася перадача, а не запыт.

Калі адрас ёсць, наступнае пытанне — якія дамены прэтэндуе гэтая сувязь. Сувязь без спісу даменаў адказвае толькі на імёны, пра якія яе пытаюцца напрамую, а гэта рэдка тое, чаго хоча разгортванне split-DNS. Адрас сам па сабе неабходны, але недастатковы.

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

Праверка трэцяя: ці выбірае прастора імён гэтую сувязь

Рэзалвер можа ўтрымліваць правільны сервер і ўсё ж не выкарыстоўвацца. Дамен на кожную сувязь вырашае, якія запыты куды ідуць, а без маршрутнага дамена прыватная прастора імён вяртаецца да таго, што кажа сувязь па змаўчанні. Таму resolvectl query для ўнутранага імя можа атрымацца, пакуль праграма ўсё яшчэ падае. Праграма можа выкарыстоўваць зусім іншы шлях рэзалвера.

Праверце прызначэнне дамена, а не толькі адрас сервера. Дамен, запісаны як ~corp.example, з'яўляецца маршрутным даменам, і тыльда змяняе спосаб супастаўлення імені.

Калі ў праграмы ўласны рэзалвер, правярайце тым жа механізмам, які яна выкарыстоўвае, а не сістэмным сродкам. Інструмент запытаў, які абынае сістэмны рэзалвер, атрымае поспех незалежна ад стану сувязі.

Праверка чацвёртая: адзін уладальнік, а не два

Калі NetworkManager ужо кіруе VPN і станам рэзалвера, даданне непавязанага скрыпта-прычэпкі стварае канкуруючых пісараў. Прычэпка, якую пастаўляе пакет для systemd-resolved, — гэта падтрыманая інтэграцыя, і яна чакае пэўнага жыццёвага цыкла: script-security 2, шлях up, up-restart, шлях down і down-pre. Гэтыя опцыі прымушаюць рэгістрацыю і выдаленне адбывацца ў правільныя моманты, а не толькі пры першым злучэнні.

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

Рэдагаванне скрыпта рэзалвера дыстрыбутыва для змены мэты вываду фіксуе абыход для аднаго хоста. Гэта не агульнае рамантаванне.

Праверка пятая: той жа вынік пасля перападключэння

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

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

Падобныя артыкулы