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 і резолвера, доки тест не пройде двічі; зміну, яка ламає домашній інтернет за вечерею, налагоджувати значно важче, ніж ту, яку ви можете відкотити за хвилину.