Дайте домашнему VPN собственные DNS-записи для nas.home.arpa
Опубликуйте одно имя из dnsmasq, направьте резолвер через WireGuard, затем выберите между передачей DNS всему клиенту и split-DNS только для home.arpa.
Когда туннель поднят, последним шагом обычно становится имя, которое работает, вместо адреса, который вы вставляете в закладку. Запись хоста в dnsmasq плюс адрес резолвера, до которого клиент может добраться, делают это двумя файлами и без multicast. Решение, которое действительно требует размышления, уже: отправляет ли клиент весь DNS через домашний резолвер или только имена под home.arpa? Всё ниже предполагает одобренную конфигурацию WireGuard с клиентом Linux и лабораторным резолвером, которым домашний администратор уже управляет.
Три способа дать клиенту резолвер
| Approach | Scope | Cost |
|---|---|---|
DNS = in the wg-quick interface | the client's general DNS while the tunnel is up | every name in the house now depends on the tunnel |
Platform split-DNS for home.arpa | only that suffix | more configuration per client platform |
Manual dig @resolver | one query at a time | fine for testing, useless for applications |
Для ноутбука, который время от времени подключается к туннелю, split-DNS — лучший вариант по умолчанию: он оставляет обычные интернет-имена на резолвере, которому машина уже доверяет. Для машины, которая существует, чтобы добираться до домашних служб, проталкивание резолвера проще, а цена охвата не имеет значения.
Опубликуйте запись на резолвере, который владеет зоной
Держите роли раздельно до того, как писать конфигурацию: адрес клиента VPN, резолвер и служба — это три разных хоста с тремя разными задачами. В этой лаборатории это 10.77.0.2 для клиента, 192.168.50.53 для dnsmasq и 192.168.50.20 для NAS, а туннель маршрутизирует домашнюю LAN.
listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20Строка host-record даёт адрес, а строка local= удерживает неизвестные вопросы о home.arpa внутри этого резолвера, вместо того чтобы пересылать их выше. Сначала прочитайте существующую конфигурацию и согласуйте всё, что уже определяет сервер, интерфейс или тот же локальный домен; наслоение фрагмента поверх противоречивого даёт резолвер, который весело загружается и отвечает неправильно. Руководство dnsmasq определяет обе директивы и управление прослушиванием.
Затем проверьте работающую службу, а не файл. Проверка конфигурации плюс перезапуск — это минимум, а действительный ответ — то, что возвращает запрос.
Маршрутизируйте резолвер, а не только веб-страницу
AllowedIPs в WireGuard решает, какие адресаты попадают в туннель. Если адрес резолвера оказывается вне его, запрос уходит обычным маршрутом и никогда не достигает dnsmasq, хотя сам NAS доступен. Включите адрес резолвера или префикс LAN, который его содержит, и проверьте политику пересылки шлюза на другой стороне.
Разрешите UDP и TCP на порту 53 из авторизованного диапазона туннеля, с обратным путём к адресу туннеля клиента. Не пересылайте порт 53 из WAN, чтобы упростить тестирование: открытый рекурсивный резолвер на домашнем подключении находят в течение нескольких часов. Привязка к интерфейсу сама по себе не является политикой доступа.
Проверьте ответ до приложения
Сначала спросите резолвер напрямую, затем систему, затем приложение. Каждый шаг изолирует одно звено в цепочке, и разница между ними — это диагноз.
dig @192.168.50.53 nas.home.arpa. A
dig +tcp @192.168.50.53 nas.home.arpa. A
getent ahostsv4 nas.home.arpa
curl -sS --max-time 5 http://nas.home.arpa/ -o /dev/null -w '%{http_code}\n'TCP-запрос стоит запустить, потому что усечённый ответ UDP вынуждает повтор, а политика, отбрасывающая TCP 53, порождает сбои, которые выглядят периодическими. Шаг getent показывает, что на самом деле делает конфигурация резолвера машины, а это не всегда то, что вы отправили.
Решите, что происходит, когда туннель опущен
Если общий DNS клиента указывает на 192.168.50.53, любое разрешение имён перестаёт работать, когда туннель не поднят. Это приемлемо на машине, которая полезна только с туннелем, и неприемлемо на ноутбуке, который также пользуется Wi-Fi в кафе. Split-DNS полностью обходит этот вопрос, потому что только поиски home.arpa зависят от домашнего резолвера.
Помните, что это за имя: home.arpa зарезервировано для жилых сетей и не является глобально уникальным, поэтому другая сеть может законно использовать то же имя. Это локальное удобство, а не надёжный идентификатор. Поддерживайте запись актуальной, когда служба переезжает, и удаляйте политику резолвера, когда лабораторию выводят из эксплуатации, вместо того чтобы оставлять ноутбук, указывающий на адрес, до которого он может добраться только через туннель, которого больше нет.