Прасунуты DNS ад OpenVPN ігнаруецца: які кампанент яго ўжывае

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

Прасунутая опцыя — гэта прапанова, а не ўсталяванне

На серверы дзве дырэктывы апісваюць намер, а не эфект:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

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

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

Пераканайцеся, што push дайшоў, і знайдзіце ўладальніка

Пачніце з назвы запускальніка: голы openvpn загад, асобнік systemd, NetworkManager або кліент пастаўшчыка. Гэта вызначае, дзе можа жыць хук. На хаспе з systemd-resolved resolvectl status пералічвае кожнае звяно з DNS-серверамі і пошукавымі даменамі, якія яно фактычна выкарыстоўвае, а звяно тунеля не заўсёды называецца tun0.

Калі прасунуты адрас ёсць у журнале, але няма ні на адным звяне, інтэграцыі не хапае. Калі ён ёсць на звяне, а запыты ўсё яшчэ сыходзяць кудысьці яшчэ, праблема ў тым, якія запыты выбіраюць гэтае звяно. NetworkManager dns=dnsmasq у файле /etc/NetworkManager/NetworkManager.conf запальвае лакальны перанакіравальнік, які наўмысна рэалізуе раздвоены DNS: імёны ўсярэдзіне дамена VPN ідуць да рэзалвера VPN, а ўсё астатняе захоўвае ранейшы шлях. Такія паводзіны выглядаюць як няспраўнасць, калі вы чакалі, што ўвесь трафік пераедзе; праверце налады для кожнага злучэння праз nmcli connection show "My VPN", дзе ipv4.dns і ipv4.dns-search трымаюць значэнні, якія стаяць за тым, што паведамляе прылада, перш чым называць гэта паламаным. Калі ўсе запыты сапраўды павінны дасягаць рэзалвера VPN, прыбярыце dns=dnsmasq з NetworkManager.conf і перазапусціце NetworkManager, што верне развязанне імёнаў наладам злучэння; інакш пакіньце раздвоены DNS і выпраўце прасунуты спіс даменаў.

Linux: перадайце опцыі рэзалверу

Дыстрыбутыўныя пакеты нясуць хук для гэтага, і кліенту павінна быць дазволена яго запускаць. Тыповая схема на хаспе без systemd-resolved:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

З systemd-resolved стары скрыпт resolv.conf можа не змяніць нічога істотнага, бо stub-рэзалвер трымае стан для кожнага звяна. update-systemd-resolved дапаможнік дакументуе форму хука, якая выкарыстоўвае up-restart і down-pre, што важна, калі інтэрфейс перажывае адну спробу злучэння. Што б вы ні выбралі, адзін кампанент павінен валодаць станам. Даданне непатрэбнага хука побач з NetworkManager дае двух пісьменнікаў аднаму звяну, і вынік тады залежыць ад парадку, а не ад вашай канфігурацыі.

Ёсць і выпадак, калі NetworkManager цалкам ігнараваў прасунутую опцыю, пакуль адрас сервера не ўвялі ў налады IPv4 злучэння, пасля чаго стан рэзалвера паказаў, што яна ўжываецца. Гэта варта паспрабаваць перад перапісваннем скрыптоў, бо яно пераносіць праблему з shell-хука ў профіль злучэння, які ўжо нясе тунель.

Windows і macOS ужываюць розныя часткі

Кліент Windows сапраўды задае DNS-серверы VPN-адаптара, але Windows усё яшчэ выбірае інтэрфейс па метрыцы і ўсё яшчэ патрабуе суфікса, каб разгарнуць кароткае імя. Праверце стан адаптара, а не профіль:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Калі адрас адсутнічае, задайце яго з Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, затым дадайце суфікс да ўласцівасцей IPv4 адаптара, каб fileserver стаў fileserver.corp.example. Значэнне SearchList на ўзроўні машыны пад Tcpip\Parameters робіць тое ж самае. Там, дзе доўгае імя развязваецца, а голае не, рэзалвер ужо слушны і вінаваты пошукавы спіс. Выпраўленні па парадку: прасуньце DOMAIN каб кліент даведаўся суфікс, дадайце гэты суфікс у пошукавы спіс адаптара або злучэння, і як часовую меру замацуйце імя ў hosts, або LMHOSTS на Windows; агляд NetBIOS не перасякае роўтар, таму шырокавяшчальны запыт, які знаходзіць кароткае імя ў офіснай LAN, ніколі не даходзіць да кліента тунеля.

block-outside-dns block-outside-dns — гэта паводзіны кліента Windows, а не пераносны радок профілю, і капіяванне яго ў профіль Linux або macOS не ўзнаўляе яго там. Калі публічныя імёны працуюць, а ўнутраныя на Windows не, параўнайце парадак адаптараў у Advanced settings з ipconfig /all. На macOS парадак рэзалвераў для кожнай службы належыць сістэме, таму выкарыстайце scutil --dns , каб убачыць, які рэзалвер апытваецца для якога дамена, і стаўцеся да любой адзіночнай парады выправіць профіль як да залежнай ад кліента, а не агульнай.

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

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

Дакажыце, куды пайшоў запыт

Захоп падчас аднаго пошуку вырашае спрэчку: tcpdump -ni eth0 port 53 паказвае запыты на фізічным інтэрфейсе, значыць яны выходзяць па-за тунель і рэзалвер ніколі не перамыкаўся. dig @10.8.0.1 name.corp.example затым раздзяляе два астатнія выпадкі. Калі прамы запыт адказвае, рэзалвер працуе і кліент ім не карыстаецца; калі сканчаецца час, рэзалвер недасяжны праз тунель і ніякая лакальная змена не дапаможа.

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

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

Трымайце аднаго ўладальніка і правярайце па парадку

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

Замкніце цыкл чатырма праверкамі: прасунуты адрас прысутны на звяне тунеля, унутранае імя развязваецца як поўнае кваліфікаванае імя, тое ж імя развязваецца без суфікса, і абодва слушныя пасля аднаго перападлучэння. Адзін захоп скажа, якая з чатырох правалілася. Дапаможнік OpenVPN 2.6 пералічвае dhcp-option і дырэктывы скрыптоў з заўвагамі для платформ.