Якое звяно адказвае: дамены маршрутызацыі для DNS у VPN з раздзеленым тунэлем

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

Крок першы: аддзяліце маршрут ад разрознівальніка

ipv4.never-default адказвае на пытанне маршрутызацыі, не даючы NetworkManager усталяваць гэтае злучэнне як шлях для ўсяго трафіку IPv4. Дамен маршрутызацыі DNS адказвае на іншае пытанне: якія серверы імёнаў якога звяна атрымліваюць запыт для адпаведнага суфікса. Ні адно не вынікае з другога, і профіль можа гадамі несці адно, не маючы другога. Толькі маршрут азначае, што тунэль нясе падсеткі кампаніі і яго разрознівальнік адказвае на назвы кампаніі, а ўсё астатняе пакідаецца як ёсць.

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

Крок другі: дадайце дамен толькі маршрутызацыі ў профіль

Мяркуйце, што злучэнне называецца corp-vpn, суфікс кампаніі — internal.example, а разрознівальнік тунэля ўжо дасягальны. Спачатку прачытайце бягучыя значэнні, бо каманды ніжэй змяняюць уласцівасці, якія могуць ужо мець запісы.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

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

Тыльда ў пачатку пазначае дамен толькі маршрутызацыі, таму адпаведныя запыты ідуць на серверы гэтага звяна, а суфікс не дадаецца да кароткіх імёнаў. Прыбярыце тыльду — і той жа радок таксама стане суфіксам пошуку, што з’яўляецца іншым вынікам, якога людзі рэдка хочуць. Абедзве налады вышэй — IPv4, таму профіль з двума стэкамі патрабуе ipv6.never-default і таго ж дамена маршрутызацыі ў ipv6.dns-search, інакш бок IPv6 працягвае выкарыстоўваць маршрут па змаўчанні, і ўнутраныя назвы там не разрозніваюцца.

Крок трэці: спытайце resolvectl, якое звяно адказала

Выканайце resolvectl status і прачытайце DNS-серверы і дамены кожнага звяна, затым выканайце resolvectl query host.internal.example для рэальнай унутранай назвы, якую вам дазволена запытваць. Другая каманда — адзіны прамы доказ таго, што дамен маршрутызацыі робіць сваю працу, бо яна называе звяно, якое адказала. Адзін спіс стану даказвае канфігурацыю; запыт даказвае разрозніванне.

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

Калі звяно VPN зусім не пералічвае DNS-сервер, кліент ніколі яго не зарэгістраваў. Дамен маршрутызацыі без сервера за ім падае інакш, чым адсутны дамен, таму спачатку выпраўце рэгістрацыю.

Крок чацвёрты: калі назва разрозніваецца, але служба — не

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

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

Крок пяты: не замяняйце разрознівальнік, каб выправіць адсутны дамен

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

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