Спыніце дзве службы Linux, якія спаборнічаюць за /etc/resolv.conf

DNS увесь час вяртаецца да ранейшага стану, перападключэнне VPN адмяняе ваша выпраўленне, і нехта ў камандзе ўрэшце прапануе заблакаваць файл. Гэтая паслядоўнасць — сімптом, а не рашэнне: два кампаненты лічаць, што валодаюць /etc/resolv.conf, і перамагае той, хто запісвае апошнім. Блакаванне файла не вырашае канфлікт уласнасці, а толькі хавае яго, ламаючы пры гэтым кампанент, які вам быў патрэбны. Выканайце чатыры праверкі ніжэй па парадку і выпраўце ўладкаванне на ўзроўні, які валодае ім, а не на ўзроўні файла.

Праверка 1: ці гэта сімвалічная спасылка і на што

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

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

Спасылка на шлях stub systemd-resolved азначае, што змест файла генеруецца, і ручное рэдагаванне будзе перазапісана пры наступнай падзеі. Звычайны файл з радкамі nameserver звычайна запісвае той кліент або хук DHCP, які працуе пры падключэнні. Абодва варыянты законныя; важна ведаць, які з іх у вас, перш чым нешта мяняць.

Праверка 2: які дэман працуе

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

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

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

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

Праверка 3: што кліенту VPN дазволена запісваць

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

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

Чытайце хукы ўздыму і спуску кліента, а не здагадвайцеся. Некалькі радкоў shell у /etc/openvpn/up.sh або эквівалентным каталогу тлумачаць паводзіны, якія інакш выглядаюць выпадковымі, і менавіта там можна прымусіць кліент супрацоўнічаць, а не спаборнічаць.

Праверка 4: выпраўляйце ў уладальніка, а не ў файле

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

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

Там, дзе два кампаненты сапраўды павінны суіснаваць, дайце ім розныя задачы. Няхай сеткавы менеджар валодае канфігурацыяй узроўню інтэрфейса, няхай кліент VPN дадае DNS і дамены для кожнай спасылкі праз тую ж інтэграцыю, а трэці скрыпт, які напрамую запісвае файл, выдаліце. Дакументацыя systemd-resolved апісвае рэжымы, якія ён падтрымлівае, і што кожны з іх паказвае ў /etc/resolv.conf. Выберыце рэжым, які адпавядае аб'ёму палітыкі, якую трэба захаваць. Калі split DNS важны, канструкцыя stub з даменамі для кожнай спасылкі захоўвае яго, а рэжым, які капіруе вышэйшыя серверы ў файл, бязгучна яго зраўноўвае.

Правярайце пасля перападключэння, а не пасля праўкі

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

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

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

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