OpenVPN перадае DNS, але рэзалвер можа яго не ўбачыць

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

Сімптом: журнал паказвае DNS, а імёны ўсё яшчэ не працуюць

OpenVPN dhcp-option перадае звесткі пра DNS і дамен, а кліент запісвае атрыманае. У некаторых рэалізацыях кліент ужывае гэтыя налады ўнутры; у іншых ён экспартуе іх для скрыпта інтэграцыі або сеткавай службы. Радок журнала апісвае толькі першую палову гісторыі. Другая палова адбываецца там, дзе кліент не кантралюе. Менавіта там звычайна і жыве збой.

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

Атрымана — не азначае ўжыта

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

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

Знайдзіце ўладальніка рэзалвера для кожнай платформы

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

Чытайце фактычны стан інструментам, які сапраўды адказвае на запыты: resolvectl query internal.example.net на хосце з systemd-resolved або эквівалент платформы. Затым параўнайце гэты адказ з DNS-серверам, які, паводле журнала кліента, быў перададзены.

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

Скрыпты і foreign_option

OpenVPN экспартуе перададзеныя параметры ў скрыпты праз зменныя з імёнамі foreign_option_N, і скрыпт можа пераўтварыць іх у каманды рэзалвера. Гэтая схема — падтрыманая інтэграцыя, а не аўтаматычныя паводзіны, і яе трэба ўсталяваць і выклікаць на кліенце.

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

Тэстуйце імя, а не журнал

Запрасіце ў кліента імя хоста, даступнае толькі ўнутры, пасля падключэння, затым запрасіце публічнае імя, затым праверце, які сервер адказаў. У працоўнай наладзе два адказы прыходзяць з розных месцаў, і абодва павінны адпавядаць праекту.

Калі імя вырашаецца, але служба церпіць збой, пераходзьце да маршрутызацыі і доступу да праграм, а не змяняйце DNS зноў. Дапаможнік OpenVPN апісвае dhcp-option і асяроддзе скрыптоў; выкарыстайце яго, каб пацвердзіць, што ваш кліент павінен ужыць, перш чым рэдагаваць чарговы файл рэзалвера.