Pi-hole nie blokuje reklam po połączeniu z VPN: pięć kontroli

Reklamy nadal pojawiają się na kliencie, Pi-hole zgłasza się jako zdrowy, a tunel jest aktywny, więc odruch każe skierować ruch tego klienta przez Pi. To zły zakręt. Filtrowanie potrzebuje pytań, a nie pakietów, a klient, którego zapytania idą do resolvera dostawcy, pozostaje niefiltrowany, gdziekolwiek płynie jego ruch. Przejdź tę listę po kolei i zatrzymaj się na pierwszym kroku, który zawiedzie, bo późniejszy krok nic ci nie powie, dopóki wcześniejszy jest zepsuty.

1. Przeczytaj resolver, którego klient naprawdę używa

Zapytaj klienta, nie router. W Linuksie resolvectl status wypisuje serwery DNS na łącze i to, które łącze wygrywa; /etc/resolv.conf sam zwykle jest stubem wskazującym na 127.0.0.53. W Windowsie ipconfig /all wymienia serwery dostarczone przez DHCP na adapter, a w macOS scutil --dns pokazuje to samo według zakresu. Jeśli odpowiedź nie jest adresem Pi-hole, masz problem z przypisaniem, a krok 2 to miejsce, w którym on mieszka.

Dwie rzeczy pokonują resolver systemowy nawet wtedy, gdy jest ustawiony poprawnie. Przeglądarki z własnym bezpiecznym DNS (opcja “Use secure DNS” w Chrome, network.trr.mode w Firefoksie) wysyłają zapytania przez HTTPS do publicznego resolvera i nigdy nie otwierają portu 53. A klient VPN na samym kliencie może zainstalować serwer DNS na swoim interfejsie tunelu z domeną routingu ~., co czyni to łącze autorytatywnym dla każdej nazwy.

Testuj drogę, którą pokonują aplikacje, a nie drogę, którą pokonuje narzędzie debugowania. resolvectl query example.com pokazuje, które łącze odpowiedziało, a getent hosts example.com idzie tą samą ścieżką NSS co aplikacja; w macOS dscacheutil -q host -a name example.com czyta resolvery zakresowe, które wymienia scutil --dns. Goły dig tego nie robi: czyta /etc/resolv.conf i pomija wybór według łącza, więc może odpowiedzieć z Pi-hole, podczas gdy każda aplikacja używa wypchniętego resolvera, i to jest dokładnie ten błąd, dla którego istnieje ta lista. Zachowaj dig @192.168.1.53 do testowania jednego konkretnego serwera.

2. Potwierdź, kto rozdaje odpowiedź

Przypisanie pochodzi od tego, co odpowiada na DHCP. W dnsmasq to jedna linia, dhcp-option=6,192.168.1.53; w interfejsie web routera to pole DNS w sekcji DHCP sieci LAN. Klienci muszą odnowić, zanim to zobaczą. Urządzenie chodzące od dni wciąż trzyma starą dzierżawę, a urządzenie z ręcznie wpisanym resolverem trzyma ją na zawsze. Odnów na kliencie testowym zamiast zakładać propagację.

IPv6 to ta połowa, która bywa pomijana. Ogłoszenia routera mogą nieść własny serwer DNS (RDNSS), a w OpenWrt to opcja ra_dns w odhcpd; klient preferujący IPv6 używa tego serwera, podczas gdy właśnie ustawiona opcja DHCPv4 pozostaje nieużywana. Jeśli nie jesteś gotowy serwować DNS przez IPv6, wyczyść tylko ogłoszenie DNS: ra_dns w odhcpd albo opcję RDNSS w tym, co odpowiada na ogłoszenia routera. Wyłączenie całego ogłoszenia usuwa też adresację IPv6 z LAN-u, co jest znacznie większą zmianą niż zamierzona, podczas gdy wyczyszczenie tylko opcji DNS zachowuje adresację nietkniętą i czyni brakujący RDNSS widocznym w przechwyceniu pakietów.

3. Udowodnij, że zapytanie dociera do Pi-hole

Zapytanie z Pi niczego nie dowodzi o ścieżce sieciowej. Uruchom je z klienta i odczytaj kod odpowiedzi:

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

Przekroczenie czasu wskazuje na filtrowanie albo trasę; REFUSED wskazuje na regułę dostępu; SERVFAIL wskazuje na nadrzędny resolver za Pi-hole; poprawna odpowiedź, która nigdy nie pojawia się w logu zapytań, oznacza, że klient zapytał o coś innego. Sprawdź UDP i TCP 53, bo duże odpowiedzi i niektóre resolvery przechodzą na TCP, i publikuj oba, gdy Pi-hole działa w kontenerze. Mapowanie obejmujące tylko UDP daje sporadyczne awarie, które wyglądają jak utrata pakietów.

Potem tryb nasłuchu Pi-hole decyduje, czy w ogóle odpowiada. W trybie tylko lokalnym dnsmasq ignoruje zapytania ze źródeł, które nie są w bezpośrednio podłączonej podsieci, a dokładnie tak wygląda klient za innym routerem albo przychodzący przez tunel: klient kończy się przekroczeniem czasu, a zapytanie nigdy nie trafia do logu. Zapytanie, które mimo to pojawia się jako REFUSED, zostało odrzucone przez listę dostępu albo regułę firewalla. Zezwolenie na wszystkie źródła to zwykła poprawka, w parze z regułą firewalla ograniczającą port 53 do twoich własnych podsieci.

4. Sprawdź, czy tunel zastąpił albo połknął odpowiedź

To przypadek, w którym ukrywają się oba objawy. Gdy router sam jest klientem VPN, wypchnięta opcja DNS może nadpisać ustawienie LAN w chwili, gdy tunel się podnosi: serwery OpenVPN wypychają dhcp-option DNS, a profile WireGuard niosą własny wpis DNS. Czytaj efektywny resolver routera z podniesionym tunelem, nie przedtem, i ignoruj to, co twierdzi strona LAN.

Inny defekt to osiągalność, a nie zastąpienie. Jeśli dozwolone prefiksy tunelu obejmują twoją podsieć LAN, router ma trasę, która wysyła zapytania o 192.168.1.53 do tunelu, a druga strona nie ma trasy powrotnej: zapytania kończą się przekroczeniem czasu, choć tunel jest zdrowy. Odwrotnie dzieje się, gdy Pi-hole siedzi w podsieci, której tunel nie przenosi. Porównaj adres z dozwolonymi prefiksami tunelu i tablicą tras routera, zanim znowu dotkniesz DNS.

Wybierz jedną poprawkę, nie obie. Albo trzymaj tunel z dala od DNS — z pull-filter ignore “dhcp-option DNS” na OpenVPN i bez prefiksu LAN w AllowedIPs na WireGuard —, albo zaakceptuj wypchnięty resolver i zrezygnuj z lokalnego filtrowania dla klientów za tym routerem. Cokolwiek wybierzesz, zapisz to obok profilu, bo następna osoba, która go edytuje, inaczej przypadkiem odwróci decyzję.

5. Powtórz test po ponownym połączeniu

Zapytaj z klienta, potwierdź, że ten klient pojawia się w logu Pi-hole, następnie rozwiąż domenę, która powinna być zablokowana, i sprawdź, czy dostajesz odpowiedź blokującą zamiast prawdziwej. Połącz tunel ponownie i wykonaj te same dwa zapytania, bo ustawienie resolvera, które wytrzymuje tylko do następnego połączenia, to zwykły wynik poprawki zastosowanej w złej warstwie.

Zostaw drugorzędną ścieżkę resolvera, która nie zależy od tunelu, aby awaria Pi-hole degraduła do przeglądania bez filtrowania, a nie do braku przeglądania. Zachowaj poprzednie wartości DHCP i resolvera, dopóki test nie przejdzie dwa razy; zmiana, która psuje internet domowników przy kolacji, jest znacznie trudniejsza do zdebugowania niż taka, którą cofniesz w minutę.