WireGuard не передає DNS: обслуговування приватної зони BIND

Рукостискання несе ключі та дозволені IP, але ніколи не несе резолвер. Ось готова приватна зона BIND 9 і клієнтська політика для кожного з'єднання, яка змушує її розв'язуватися.

Ви підняли WireGuard, тунель пропускає трафік, а внутрішнє ім'я досі не розв'язується. Наступний крок зазвичай — шукати налаштування DNS у конфігурації WireGuard, ніби партнер може проштовхнути резолвер, як роблять деякі інші VPN. Не може. Рукостискання несе ключі, адреси інтерфейсу та дозволені IP, і в ньому немає поля для DNS-серверів або доменів пошуку. Політика резолвера живе на клієнті, і саме там місце виправленню.

Тунель і резолвер — окремі договори

WireGuard навмисно малий. Він переміщує пакети для адрес, які ви перелічите, і автентифікує партнерів; усе вище цього шару — ваш дизайн. OpenVPN може проштовхнути dhcp-option DNS, бо його канал керування несе конфігурацію, і ця різниця спотикає тих, хто переходить між ними.

Отже, робочий тунель нічого не каже про розв'язування імен. Клієнт може мати ідеальний маршрут до 10.90.0.1 і все одно надсилати запити публічному резолверу, тому симптом виглядає як «VPN зламав DNS», хоча DNS ніколи не був спрямований на VPN.

Обслуговуйте зону, не стаючи рекурсивним резолвером

Бік сервера — невелика авторитетна зона, а не загальний резолвер. У цьому прикладі шлюз 10.90.0.1, клієнти 10.90.0.0/24, а потрібний вам застосунок відповідає на 10.60.0.20.

Об'єднайте ці налаштування в наявному блоці options замість створення другого:

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

Потім оголосіть зону та її файл:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};
$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

Перевірте перед перезавантаженням, бо синтаксична помилка під час завантаження валить увесь сервер для кожної зони, яку він обслуговує:

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

Відкрийте UDP і TCP 53 лише на інтерфейсі VPN. Публікація приватного авторитету на публічному інтерфейсі запрошує і запити, і перелічення, а allow-transfer має залишатися закритим, якщо вторинний справді не потребує.

Спрямуйте клієнт на неї, для кожного з'єднання

Припустіть, що з'єднанням володіє NetworkManager, а резолвер — systemd-resolved. Спершу прочитайте наявну політику, особливо будь-який кореневий домен маршрутизації, бо запис ~. переважить те, що ви збираєтеся додати.

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

Тильда — важливий символ. Вона позначає домен як лише-маршрут: імена під corp.example ідуть до DNS-сервера цього з'єднання, і домен не додається як суфікс пошуку коротких імен. Без неї введення portal починає розв'язувати portal.corp.example, що зручно вам і несподівано для всіх інших. Тримайте тильду всередині лапок, бо без лапок вона — розкриття оболонки, яке чекає, щоб указати на вашу домашню теку.

Застосуйте зміну через менеджер, що володіє інтерфейсом, потім перепідключіть з'єднання. Не запускайте другий екземпляр wg-quick для того самого інтерфейсу; два власники будуть сперечатися за маршрути, і один із них переможе в найгірший момент.

Перевірте шлях раніше за ім'я

Запитайте ім'я з клієнта і підтвердьте і відповідь, і сервер, який її видав:

resolvectl query portal.corp.example

Якщо це повертає 10.60.0.20, договір DNS виконано. Якщо час вичерпується, спершу перевірте маршрут до 10.90.0.1, потім правило брандмауера, потім allow-query на сервері. Збої розв'язування імен у такій конфігурації майже завжди пов'язані з доступністю або ACL, а не з файлом зони. Працюйте від клієнта назовні, бо сервер не може сказати, чому запит так і не надійшов.

Пам'ятайте, що застосунку все ще потрібен власний маршрут і власний дозвіл на сервіс. Розв'язане ім'я, що вказує на недосяжну адресу, — це інша несправність у тому самому вбранні.

Що все ще не автоматизовано

Застосунки з власною логікою резолвера повністю ігнорують системний резолвер, і жодна кількість nmcli цього не змінить. Розгортання, які перевіряють DNSSEC, потребують явного проєкту довіреного якоря для приватної зони; відповідь — не загальна інструкція вимкнути перевірку. Тестуйте тим самим клієнтським ПЗ, яке запускають ваші користувачі, а не інструментом, що випадково використовує системний резолвер. Різниця між цими двома і є весь звіт про помилку.

Флоти можуть автоматизувати цю клієнтську політику через свою систему провізіонінгу, але політика залишається окремим об'єктом із власником. Довідник BIND 9 описує використані вище контролі прослуховування та запитів, і це правильне місце, щоб підтвердити поведінку для встановленої версії.

Наступний крок: додайте підвищення серійного номера зони та перевірні команди до вашої процедури змін, щоб правка запису не могла потрапити в продакшн неперевіреною.

Схожі статті