Порядок записей в resolvconf Debian: поставьте запись VPN первой

DNS-сервер VPN постоянно оказывается ниже LAN, а правка /etc/resolv.conf исправляет это на несколько минут. Этот файл генерируется, поэтому исправление никогда не сохраняется. В resolvconf Debian входом порядка служит /etc/resolvconf/interface-order, и он сортирует имена записей, а не адреса DNS. Прежде чем трогать любой из двух файлов, подтвердите, какой стек resolver действительно главный.

Подтвердите, что выводом владеет resolvconf

Начните с вопроса, что записало текущий файл и что запишет его снова. Пакет resolvconf описывает себя как основу для динамической настройки resolver, и хост с systemd-resolved или resolver под управлением NetworkManager может снаружи выглядеть так же, но использовать совсем другую политику.

readlink -f /etc/resolv.conf
dpkg -l resolvconf 2>/dev/null | tail -n 1

Если разрешённый путь не ведёт в рабочий каталог resolvconf, остановитесь здесь: это руководство относится к другому стеку.

Только после этой проверки стоит перечислить записи, которые resolvconf держит сейчас.

Прочитайте записи, прежде чем писать шаблоны

interface-order сопоставляется с именами записей поставщиков, а не с адресами и не с именами интерфейсов ядра. Перечислите, что зарегистрировано, чтобы шаблоны ссылались на существующие записи.

ls /run/resolvconf/interfaces
cat /etc/resolvconf/interface-order

Имя записи обычно несёт суффикс, обозначающий её поставщика, поэтому запись туннеля и запись DHCP могут делить префикс интерфейса и всё же сортироваться по-разному. Копируйте точные имена из листинга каталога. Не выводите имя из имени интерфейса, потому что именно интеграция клиента решает, что регистрировать. Придуманное имя никогда не совпадёт, и запись провалится в шаблон-перехватчик без какого-либо сообщения об ошибке.

Запишите порядок как шаблоны первого совпадения

Файл — это список шаблонов shell glob, по одному в строке. Запись занимает позицию первого шаблона, которому соответствует, поэтому широкий шаблон выше конкретного делает конкретную строку недостижимой.

# /etc/resolvconf/interface-order
lo*
tun_work.*
enp*
*

Поставьте конкретный шаблон туннеля выше перехватчика и выше шаблона физического интерфейса.

Сохраните остальные строки, которые уже были в файле. Замена всей политики примером — это способ, которым несвязанные поставщики тихо смещаются; измените одну строку, перегенерируйте и сравните. Шаблоны не могут содержать пробелы, слэши или начальную точку либо тильду, а пустые строки и комментарии с решёткой игнорируются.

Перегенерируйте и проверьте результат

Порядок применяется, когда скрипты обновления перестраивают файл. Запустите поддерживаемый путь обновления вместо правки сгенерированного вывода, затем прочитайте, что resolver действительно получил.

resolvconf -u
cat /etc/resolv.conf

Проверьте два запроса, а не один: приватное имя, которое должно разрешаться через туннель, и публичное контрольное имя. Если приватное имя по-прежнему не разрешается, хотя порядок выглядит верным, проблема в маршрутизации пространства имён, а не в приоритете записей, и никакая перестановка это не исправит. Сравнивайте каждый ответ с сервером, который его вернул, а не только с успехом. Приватное имя, на которое ответил не тот resolver, — всё ещё сбой, и для пользователя это выглядит как отказ DNS.

Выведите устаревшую запись из эксплуатации вместо понижения её приоритета

Устаревшая запись VPN, которая снова появляется после отключения, — это ошибка жизненного цикла в интеграции клиента. Перемещение её вниз скрывает симптом и оставляет в списке мёртвый resolver.

Выведите её через компонент, который её регистрирует, затем подтвердите, что каталог записей её больше не содержит.

Запишите имя поставщика, изменённый шаблон и два выполненных запроса. Следующему человеку эти имена нужнее, чем история.