Направить клиентов OpenVPN на резолвер Pi-hole на другом хосте

Вписать адрес Pi-hole в профиль OpenVPN не значит создать путь к нему, дать право его опрашивать или гарантировать, что клиент им воспользуется. Когда Pi-hole стоит на отдельной машине в LAN, должны совпасть четыре вещи: маршрут от клиента, перенаправление от шлюза, обратный путь к пулу и политика приёма на самом Pi-hole. Каждый сбой выглядит в журнале по-своему. Пройти их в этом порядке быстрее, чем сначала чинить последний. Обычное упрощение, открыть рекурсию для любого источника, меняет маленькую проблему на постоянную.

Что делает и чего не делает проталкиваемая опция DNS

Сервер объявляет резолвер директивой ниже, предполагая, что 192.168.50.53 — хост Pi-hole. Клиент получает опцию и, в зависимости от платформы и интеграции резолвера , применяет её к интерфейсу туннеля или игнорирует в пользу локального stub. Строка маршрута важна не меньше строки DNS, потому что резолвер, до которого клиент не дотягивается, — вовсе не резолвер. Ничего из этого не видно со стороны сервера.

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

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

Опция также ничего не говорит о стороне сервера. DNS-трафик всё равно должен пройти от клиента к шлюзу и от шлюза к Pi-hole, прежде чем любая опция начнёт что-то значить. Отсутствующий маршрут и отклонённый запрос выглядят со стороны клиента одинаково, поэтому сначала подтвердите перенаправление на шлюзе.

Обратный путь от Pi-hole к пулу

Если адрес источника клиента сохраняется, Pi-hole отвечает на адрес внутри пула VPN. Его собственная таблица маршрутизации, вероятно, ничего не знает об этом пуле, поэтому ответ уходит на его шлюз по умолчанию и пропадает. Журнал запросов показывает запрос без подходящего ответа, что легко принять за проблему брандмауэра.

Дайте LAN-роутеру статический маршрут к пулу со шлюзом OpenVPN в качестве следующего перехода или транслируйте источник на шлюзе до перенаправления к Pi-hole. Первое оставляет адреса каждого клиента видимыми в журнале запросов Pi-hole. Второе убирает требование обратного маршрута, но заставляет каждый запрос выглядеть пришедшим от шлюза. Ни одно не является неправильным; они отвечают на разные вопросы.

Если важны отчёты или политика по каждому клиенту, статический маршрут — лучший обмен. Если LAN управляется кем-то другим и маршрута нет, трансляция — прагматичный вариант, с зафиксированной потерей идентичности клиента. Запишите, какой вариант вы выбрали, потому что каждый последующий вопрос по журналам зависит от этого.

Режим прослушивания Pi-hole для маршрутизируемых клиентов

Раскрывающийся список поведения прослушивания интерфейсов на странице настроек в разделе DNS решает, каким источникам отвечает Pi-hole. Самый строгий вариант принимает только клиентов в непосредственно подключённых сетях; вариант, разрешающий устройства не дальше одного перехода, распространяет это на подсети за соседним маршрутизатором, и именно так выглядит маршрутизируемый клиент VPN. Пакет действительно приходит на интерфейс LAN, но его адрес источника принадлежит другой подсети. Это отказ по политике, а не сбой маршрутизации, и разница важна при чтении журналов.

Руководство Pi-hole по прослушиванию отделяет локально подключённые источники от маршрутизируемых и не считает интерфейс прихода критерием. Выберите режим, который разрешает пул VPN, не разрешая весь интернет, и дополните его правилом брандмауэра, принимающим DNS только из пула.

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

Сопоставьте ответ с журналом запросов

Спросите клиента, затем проверьте сервер и сравните оба. На клиенте с systemd-resolved команды ниже показывают, какой резолвер дал ответ и какие серверы настроены для каждого соединения. Используйте имя, которое знает только Pi-hole, потому что прямой запрос на адрес Pi-hole доказывает доступность, а не конфигурацию.

resolvectl query intranet.example.lan
resolvectl dns

Ожидаемый ответ называет 192.168.50.53 сервером и возвращает адрес, который знал бы только этот резолвер. Затем посмотрите на собственное представление Pi-hole: pihole -t следит за журналом запросов в реальном времени, и каждая строка несёт адрес источника. Если источник — туннельный адрес клиента, маршрут пула цел. Если это адрес LAN шлюза, работает трансляция источника, и собственный адрес клиента никогда не появится.

Если в журнале вообще ничего не появляется, запрос так и не дошёл до Pi-hole, и следующее, что нужно проверить, — перенаправление на шлюзе. Если запрос появляется, а ответ не возвращается, проблема в обратном пути, то есть в предыдущем разделе. Такое разделение сбоя не даёт принять ошибку маршрутизации за правило брандмауэра.

Проверьте правило перенаправления шлюза

Шлюз должен перенаправлять DNS-пакеты клиента к Pi-hole, и правило, которое это делает, стоит прочитать, а не предполагать. Команды ниже перечисляют правила, затрагивающие порт 53, со счётчиками, на хосте nftables и на хосте iptables. Правило, которое существует, но показывает ноль совпадений, — сигнал, что трафик отбрасывается до трансляции.

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

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

Каким бы инструментом ни пользовался хост, держите проверку узкой: пул как источник, порт 53 как назначение и Pi-hole как единственная разрешённая цель. Широкое правило перенаправления, разрешающее ещё и порт 80, — другая проблема, которая только ждёт своего часа.