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 описывает использованные выше элементы управления прослушиванием и запросами, и это правильное место, чтобы подтвердить поведение для установленной версии.

Следующий шаг: добавьте повышение серийного номера зоны и проверочные команды в вашу процедуру изменений, чтобы правка записи не могла попасть в продакшн непроверенной.

Похожие статьи