Порядок записів у 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.

Виведіть його через компонент, який його реєструє, потім підтвердьте, що каталог записів його більше не містить.

Запишіть ім'я постачальника, змінений шаблон і два виконані запити. Наступній людині ці імена потрібніші за історію.