DNS OpenVPN на шлюзе: dnsmasq и охват межсетевого экрана

Запустите dnsmasq на адресе туннеля, разрешите DNS только из пула клиентов, протолкните резолвер, затем проверьте прямые запросы и собственный поиск приложения.

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

Слушатель — это локальная служба с двумя направлениями

На входе клиент отправляет запрос на адрес туннеля шлюза через порт 53. На выходе демон пересылает этот запрос своему настроенному вышестоящему серверу. Обе половины должны работать, и они отказывают по-разному.

Тайм-аут, о котором сообщает клиент, и тайм-аут, видимый на шлюзе, — не одна и та же неисправность.

Привяжите адрес туннеля, а не каждый адрес

Отдельный экземпляр dnsmasq для этой задачи требует явного адреса прослушивания, режима привязки, который терпит появление туннеля после запуска, и одного ясного вышестоящего сервера. Это самая маленькая версия, которую я использую:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic привязывает отдельные адреса и справляется, когда tun0 появляется позже, что важно на хосте, где служба VPN перезапускается. Перечисление loopback сохраняет работу локальных инструментов, не добавляя публичного слушателя. no-resolv не даёт демону наследовать вышестоящие серверы из конфигурации резолвера хоста, а no-hosts не даёт этому экземпляру публиковать файл hosts шлюза. Ни один из этих вариантов не даёт никому права опрашивать службу.

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

Разрешите вход DNS, а не транзит туннеля

Правила межсетевого экрана, которые это обеспечивают, — локальные правила входа, ограниченные интерфейсом туннеля, пулом клиентов, адресом шлюза и портом 53. Двух правил, по одному на протокол, достаточно:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS работает по TCP так же, как по UDP, поэтому правило только для UDP оставляет большие ответы отказывающими так, что это выглядит периодически. Это не ufw route разрешения, и они не должны стать широким разрешением на tun0. Порядок важен не меньше содержимого: более раннее правило, отбрасывающее весь вход с tun0, всё равно побеждает, а добавление разрешения ниже окончательного сброса ничего не создаёт.

Если DNS шлюза теперь часть проекта, осознанно пересмотрите ту прежнюю политику и запишите почему.

Вышестоящая половина — отдельный путь

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

Не добавляйте неограниченный выход туннеля, чтобы ответы работали; отслеживаемые ответы в этом не нуждаются.

Протолкните параметр, затем проверьте передачу

Сервер может объявить резолвер клиентам протолкнутым параметром. Это параметр, а не инструкция, которой операционная система обязана подчиняться:

push "dhcp-option DNS 10.90.0.1"

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

Цель — один владелец конфигурации резолвера клиента, и проталкивание обычно является этим владельцем только когда платформа клиента согласна.

Проверьте то, что вы действительно построили

Запросите одно частное полное доменное имя и одно разрешённое внешнее имя напрямую по адресу туннеля, через UDP и TCP. Затем повторите обычным путём поиска приложения.

Если прямые запросы работают, а приложение всё ещё отказывает, неисправность в передаче, а не на сервере:

  • Клиент так и не применил протолкнутый параметр.
  • Позже был задан другой резолвер, и он выиграл гонку.
  • Приложение использует собственную библиотеку резолвера или кешированный ответ.

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

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