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 в секцията LAN DHCP. Клиентите трябва да подновят, преди да го видят. Устройство, което работи от дни, все още държи стария наем, а устройство с ръчно въведен резолвер го държи завинаги. Подновете на тестов клиент, вместо да предполагате разпространение.

IPv6 е половината, която се пропуска. Съобщенията от рутера могат да носят свой DNS сървър (RDNSS), а в OpenWrt това е опцията ra_dns на odhcpd; клиент, който предпочита IPv6, използва този сървър, докато опцията DHCPv4, която току-що зададохте, остава неизползвана. Ако не сте готови да обслужвате DNS по IPv6, изчистете само DNS съобщението: ra_dns в odhcpd или опцията RDNSS в това, което отговаря на съобщенията от рутера. Изключването на цялото съобщение също премахва адресирането по IPv6 от LAN, което е много по-голяма промяна от тази, която сте имали предвид, докато изчистването само на 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 опция може да отмени LAN настройката в момента, в който тунелът се вдигне: OpenVPN сървърите изпращат dhcp-option DNS, а профилите на WireGuard носят свой собствен DNS запис. Четете ефективния резолвер на рутера с вдигнат тунел, а не преди това, и игнорирайте това, което твърди LAN страницата.

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

Изберете едно решение, а не и двете. Или дръжте тунела далеч от DNS — с pull-filter ignore “dhcp-option DNS” в OpenVPN и без LAN префикс в AllowedIPs в WireGuard, — или приемете изпратения резолвер и се откажете от локално филтриране за клиентите зад този рутер. Кое и да изберете, запишете го до профила, защото следващият човек, който ще го редактира, иначе ще обърне решението по случайност.

5. Повторете теста след повторно свързване

Направете заявка от клиент, потвърдете, че този клиент се появява в журнала на Pi-hole, след което резолвирайте домейн, който трябва да бъде блокиран, и проверете, че получавате блокиращия отговор вместо истинския. Свържете отново тунела и изпълнете същите две заявки, защото настройка на резолвера, която издържа само до следващото свързване, е обичайният резултат от поправка, приложена на грешен слой.

Оставете вторичен път за резолвера, който не зависи от тунела, така че прекъсване на Pi-hole да води до нефилтрирано сърфиране, вместо до никакво сърфиране. Запазете предишните стойности за DHCP и резолвера, докато тестът мине два пъти; промяна, която счупва интернета на домакинството на вечеря, е много по-трудна за отстраняване от тази, която можете да върнете за минута.