Pi-hole не блокирует рекламу после подключения VPN: пять проверок

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

1. Прочитайте резолвер, который клиент действительно использует

Спросите клиента, а не роутер. В Linux resolvectl status печатает DNS-серверы по каждому подключению и то, какое подключение побеждает; /etc/resolv.conf сам по себе обычно является заглушкой, указывающей на 127.0.0.53. В Windows ipconfig /all перечисляет серверы, выданные по DHCP, по каждому адаптеру, а в macOS scutil --dns показывает то же самое по области. Если ответ не адрес Pi-hole, у вас проблема с назначением, и шаг 2 — это место, где она находится.

Две вещи побеждают системный резолвер даже при правильной настройке. Браузеры с собственным безопасным DNS (опция “Use secure DNS” в Chrome, network.trr.mode в Firefox) отправляют запросы через HTTPS публичному резолверу и никогда не открывают порт 53. А VPN-клиент на самом клиенте может установить DNS-сервер на своём туннельном интерфейсе с доменом маршрутизации ~., что делает это подключение авторитетным для каждого имени.

Проверяйте путь, которым идут приложения, а не путь, которым идёт инструмент отладки. resolvectl query example.com показывает, какое подключение ответило, а getent hosts example.com идёт тем же путём NSS, что и приложение; в macOS dscacheutil -q host -a name example.com читает резолверы по области, которые перечисляет scutil --dns. Голый dig так не делает: он читает /etc/resolv.conf и пропускает выбор по подключению, поэтому может ответить из Pi-hole, пока каждое приложение использует проталкиваемый резолвер, и это ровно та неисправность, для которой существует этот список. Оставьте dig @192.168.1.53 для проверки одного конкретного сервера.

2. Подтвердите, кто раздаёт ответ

Назначение приходит от того, что отвечает на DHCP. В dnsmasq это одна строка, dhcp-option=6,192.168.1.53; в веб-интерфейсе роутера это поле DNS в разделе DHCP локальной сети. Клиенты должны обновить аренду, прежде чем увидят это. Устройство, работающее днями, всё ещё держит старую аренду, а устройство с вручную вписанным резолвером держит её вечно. Обновите на тестовом клиенте вместо того, чтобы предполагать распространение.

IPv6 — та половина, которую упускают. Объявления роутера могут нести собственный DNS-сервер (RDNSS), и в OpenWrt это опция ra_dns в odhcpd; клиент, предпочитающий IPv6, использует этот сервер, пока только что заданная опция DHCPv4 остаётся неиспользованной. Если вы не готовы обслуживать DNS по IPv6, очистите только объявление DNS: ra_dns в odhcpd или опцию RDNSS в том, что отвечает на объявления роутера. Отключение всего объявления также убирает адресацию IPv6 из локальной сети, что является куда большим изменением, чем задумано, тогда как очистка только опции DNS сохраняет адресацию нетронутой и делает отсутствующий RDNSS видимым в перехвате пакетов.

3. Докажите, что запрос доходит до Pi-hole

Запрос с Pi ничего не доказывает о сетевом пути. Запустите его с клиента и прочитайте код ответа:

dig @192.168.1.53 example.com
dig @192.168.1.53 doubleclick.net

Тайм-аут указывает на фильтрацию или на маршрут; REFUSED указывает на правило доступа; SERVFAIL указывает на вышестоящий резолвер за Pi-hole; правильный ответ, который никогда не появляется в журнале запросов, означает, что клиент спросил что-то другое. Проверьте UDP и TCP 53, потому что большие ответы и некоторые резолверы откатываются на TCP, и публикуйте оба, когда Pi-hole работает в контейнере. Сопоставление, покрывающее только UDP, даёт периодические сбои, похожие на потерю пакетов.

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

4. Проверьте, подменил ли туннель ответ или поглотил его

Это случай, в котором прячутся оба симптома. Когда роутер сам является VPN-клиентом, проталкиваемая опция DNS может переопределить настройку локальной сети в момент поднятия туннеля: серверы OpenVPN проталкивают dhcp-option DNS, а профили WireGuard несут собственную запись DNS. Читайте действующий резолвер роутера при поднятом туннеле, а не до него, и игнорируйте то, что утверждает страница локальной сети.

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

Выберите одно исправление, а не оба. Либо держите туннель подальше от DNS — с pull-filter ignore “dhcp-option DNS” в OpenVPN и без префикса локальной сети в AllowedIPs в WireGuard —, либо примите проталкиваемый резолвер и откажитесь от локальной фильтрации для клиентов за этим роутером. Что бы вы ни выбрали, запишите это рядом с профилем, иначе следующий человек, который его отредактирует, случайно развернёт решение.

5. Повторите тест после переподключения

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

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