Спрете две Linux услуги, които се състезават за /etc/resolv.conf

DNS непрекъснато се връща към старото състояние, повторното свързване на VPN отменя поправката ви и някой в екипа в крайна сметка предлага файлът да бъде заключен. Тази последователност е симптом, а не решение: два компонента смятат, че притежават /etc/resolv.conf, и печели този, който запише последен. Заключването на файла не решава конфликта за собствеността, а само го скрива, като същевременно чупи компонента, който всъщност ви е нужен. Изпълнете четирите проверки по-долу по ред и поправете подредбата на нивото, което я притежава, а не на файла.

Проверка 1: символна връзка ли е и към какво

Започнете със самия файл, защото пътят, който редактирате, може изобщо да не е файлът. Символната връзка към работната директория на resolver се държи напълно различно от обикновен файл, който клиентски скрипт презаписва:

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

Връзка към stub път на systemd-resolved означава, че съдържанието на файла се генерира, и ръчното редактиране ще бъде презаписано при следващото събитие. Обикновен файл с редове nameserver обикновено се записва от клиента или DHCP hook-а, който работи при свързване. И двете са законни; важното е да знаете кой от двата имате, преди да промените нещо.

Проверка 2: кой демон работи

Разберете какво всъщност е активно, а не какво е инсталирано. В съвременна дистрибуция може да има няколко resolver-а и отговаря този, който държи порт 53 на loopback интерфейса:

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

Изходът от статуса показва DNS сървърите за всяка връзка и маршрутизиращите домейни — това е картата, която ви трябва за split DNS. Ако вътрешните имена трябва да отиват към вътрешен сървър, а всичко останало към публичен, тази политика живее в домейните за всяка връзка и изравняването ѝ до статичен списък с nameserver във файла тихо губи разликата.

Собствената конфигурация на NetworkManager решава кой от тези backend-и използва. Настройката dns= в главния конфигурационен файл избира между вътрешния resolver, dnsmasq, systemd-resolved и none, и дистрибуцията може да е избрала вместо вас. Прочетете тази настройка, преди да решите какво означава „поправяне на DNS“ на този хост.

Проверка 3: какво е позволено да записва VPN клиентът

Тук обикновено живее конфликтът. VPN клиент, който презаписва файла на resolver-а директно, ще се бори с всяка услуга, която също го поддържа, и губещият е този, който работи пръв. Новите издания на OpenVPN могат да предават DNS настройки на systemd-resolved вместо да презаписват файла — това е кооперативното поведение, което искате; по-старите скриптове и ръчно написаните hook-ове често извикват остарял помощен инструмент или просто презаписват файла.

Ситуацията с WireGuard е подобна по форма: самата конфигурация на интерфейса не управлява DNS — това правят инструментите около нея, чрез resolver helper или интеграцията с resolved. Ако са инсталирани два такива помощника, и двата ще се опитат да приложат своята представа за света при свързване.

Четете hook-овете за вдигане и сваляне на клиента, вместо да гадаете. Няколко реда shell в /etc/openvpn/up.sh или еквивалентна директория обясняват поведение, което иначе изглежда случайно, и точно там можете да накарате клиента да си сътрудничи, вместо да се състезава.

Проверка 4: поправете го при собственика, не във файла

След като знаете собственика, конфигурирайте DNS през поддържания от него интерфейс. За systemd-resolved това означава настройки за всяка връзка и маршрутизиращи домейни вместо статичен файл; за NetworkManager означава DNS настройките на профила за връзка и избрания backend; за дистрибуция с интеграция на resolvconf означава писане през този помощник.

Не правете файла неизменяем. Атрибутът за неизменяемост спира законните подновявания на DHCP и обновяванията на VPN заедно с тези, с които сте се борили, и оставя системата в състояние, в което следващото обновяване на пакет или повторно свързване предизвиква отказ, който никой не може да обясни от конфигурацията. Той прикрива конфликта за собствеността — точно нещото, което сте се опитвали да решите.

Когато два компонента наистина трябва да съществуват заедно, дайте им различни задачи. Нека мрежовият мениджър притежава конфигурацията на ниво интерфейс, нека VPN клиентът добавя DNS и домейни за всяка връзка чрез същата интеграция, и премахнете третия скрипт, който записва файла директно. Документацията на systemd-resolved описва режимите, които поддържа, и какво показва всеки от тях в /etc/resolv.conf. Изберете режима, който отговаря на обема политика, който трябва да запазите. Ако split DNS е важен, stub подредбата с домейни за всяка връзка го запазва, докато режимът, който копира upstream сървърите във файла, тихо го изравнява.

Проверявайте след повторно свързване, а не след редакцията

Файл, който изглежда правилен веднага след промяната ви, не доказва нищо, защото следващото събитие още не се е случило. Задействайте последователността, която преди го чупеше: свалете и вдигнете тунела, подновете DHCP lease или превключете интерфейса, после прочетете същите стойности отново.

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

След това потвърдете разликата, която има значение: вътрешното име се решава през вътрешния сървър, докато публичното име все още работи. Конфигурация, която изпраща всичко към вътрешния сървър, изглежда наред, докато някой не се опита да стигне до интернет през тунела, а конфигурация, която изпраща всичко към публичния, изтича вътрешни имена.

Запишете собственика, backend-а и режима на символната връзка в бележките за внедряване. Този единствен абзац превръща бъдещо обновяване на пакет от инцидент в пункт за преглед и спира следващия човек да преоткрие същия конфликт с команда chattr.