Pi-hole blokkeert geen advertenties nadat de VPN verbindt: vijf controles

Advertenties verschijnen nog steeds op een client, Pi-hole meldt zich gezond en de tunnel is actief, dus het instinct is om het verkeer van die client via de Pi te leiden. Dat is de verkeerde afslag. Filtering heeft de vragen nodig, niet de pakketten, en een client waarvan de query's naar de resolver van de provider gaan, blijft ongefilterd waar zijn verkeer ook stroomt. Loop deze lijst op volgorde door en stop bij de eerste stap die mislukt, want een latere stap kan je niets vertellen zolang een eerdere kapot is.

1. Lees de resolver die de client werkelijk gebruikt

Vraag het de client, niet de router. Op Linux drukt resolvectl status de DNS-servers per link af en welke link wint; /etc/resolv.conf alleen is meestal een stub die naar 127.0.0.53 wijst. Op Windows somt ipconfig /all de door DHCP geleverde servers per adapter op, en op macOS toont scutil --dns hetzelfde per bereik. Als het antwoord niet het adres van Pi-hole is, heb je een toewijzingsprobleem en stap 2 is waar dat zit.

Twee dingen verslaan de systeemresolver zelfs als die correct is ingesteld. Browsers met hun eigen beveiligde DNS (de optie “Use secure DNS” van Chrome, network.trr.mode van Firefox) sturen query's via HTTPS naar een publieke resolver en openen nooit poort 53. En een VPN-client op de client zelf kan een DNS-server op zijn tunnelinterface installeren met een routeringsdomein van ~., waardoor die link gezaghebbend wordt voor elke naam.

Test het pad dat applicaties nemen, niet het pad dat een debugtool neemt. resolvectl query example.com laat zien welke link antwoordde, en getent hosts example.com gaat via hetzelfde NSS-pad als een applicatie; op macOS leest dscacheutil -q host -a name example.com de bereikresolvers die scutil --dns opsomt. Een kale dig doet dit niet: die leest /etc/resolv.conf en slaat de selectie per link over, dus kan hij antwoorden vanuit Pi-hole terwijl elke applicatie de geduwde resolver gebruikt, en dat is precies de fout waarvoor deze lijst bestaat. Houd dig @192.168.1.53 achter de hand om één specifieke server te testen.

2. Bevestig wie het antwoord uitdeelt

De toewijzing komt van wat er op DHCP antwoordt. Op dnsmasq is dat één regel, dhcp-option=6,192.168.1.53; in de webinterface van een router is het het DNS-veld in de LAN-DHCP-sectie. Clients moeten vernieuwen voordat ze het zien. Een apparaat dat al dagen aan staat, houdt nog de oude lease, en een apparaat met een handmatig getypte resolver houdt die voor altijd. Vernieuw op een testclient in plaats van verspreiding aan te nemen.

IPv6 is de helft die wordt vergeten. Routeradvertenties kunnen hun eigen DNS-server meedragen (RDNSS), en op OpenWrt is dat de optie ra_dns van odhcpd; een client die IPv6 verkiest, gebruikt die server terwijl de DHCPv4-optie die je net instelde ongebruikt blijft. Als je nog geen IPv6-DNS kunt aanbieden, wis dan alleen de DNS-advertentie: ra_dns in odhcpd, of de RDNSS-optie in wat routeradvertenties beantwoordt. De hele advertentie uitschakelen haalt ook IPv6-adressering uit het LAN, wat een veel grotere wijziging is dan je bedoelde, terwijl alleen de DNS-optie wissen de adressering intact laat en de ontbrekende RDNSS zichtbaar maakt in een pakketopname.

3. Bewijs dat de query Pi-hole bereikt

Een query vanaf de Pi bewijst niets over het netwerkpad. Voer hem uit vanaf de client en lees de responscode:

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

Een time-out wijst op filtering of op een route; REFUSED wijst op een toegangsregel; SERVFAIL wijst op de upstreamresolver achter Pi-hole; een correct antwoord dat nooit in het querylog verschijnt, betekent dat de client iets anders vroeg. Controleer UDP en TCP 53, omdat grote antwoorden en sommige resolvers terugvallen op TCP, en publiceer beide wanneer Pi-hole in een container draait. Een mapping die alleen UDP dekt, levert onregelmatige fouten op die op pakketverlies lijken.

Daarna bepaalt de luistermodus van Pi-hole of hij überhaupt antwoordt. In de modus alleen lokaal negeert dnsmasq query's van bronnen die niet op een direct aangesloten subnet zitten, en precies zo ziet een client achter een andere router of een die via een tunnel binnenkomt eruit: de client loopt in een time-out en de query bereikt nooit het log. Een query die toch als REFUSED opduikt, is geweigerd door een toegangslijst of een firewallregel. Alle oorsprongen toestaan is de gebruikelijke oplossing, samen met een firewallregel die poort 53 tot je eigen subnetten beperkt.

4. Controleer of de tunnel het antwoord heeft vervangen of opgeslokt

Dit is het geval waarin beide symptomen zich verschuilen. Wanneer de router zelf een VPN-client is, kan een geduwde DNS-optie de LAN-instelling overschrijven op het moment dat de tunnel opkomt: OpenVPN-servers duwen dhcp-option DNS, en WireGuard-profielen dragen hun eigen DNS-entry. Lees de effectieve resolver van de router met de tunnel actief, niet ervoor, en negeer wat de LAN-pagina beweert.

De andere fout is bereikbaarheid, niet vervanging. Als de toegestane prefixen van de tunnel je LAN-subnet omvatten, heeft de router een route die query's voor 192.168.1.53 de tunnel in stuurt, en de andere kant heeft geen route terug: query's lopen in een time-out terwijl de tunnel gezond is. Het omgekeerde gebeurt wanneer Pi-hole op een subnet zit dat de tunnel niet draagt. Vergelijk het adres met de toegestane prefixen van de tunnel en de routetabel van de router voordat je DNS opnieuw aanraakt.

Kies één oplossing, niet beide. Houd de tunnel uit de buurt van DNS — met pull-filter ignore “dhcp-option DNS” op OpenVPN en zonder LAN-prefix in AllowedIPs op WireGuard —, of accepteer de geduwde resolver en geef lokale filtering voor clients achter die router op. Wat je ook kiest, schrijf het naast het profiel, want de volgende persoon die het bewerkt, draait de beslissing anders per ongeluk om.

5. Herhaal de test na een herverbinding

Query vanaf een client, bevestig dat die client in het log van Pi-hole verschijnt, los dan een domein op dat geblokkeerd zou moeten worden en controleer dat je het blokkeringsantwoord krijgt in plaats van het echte. Herverbind de tunnel en voer dezelfde twee query's uit, want een resolverinstelling die alleen tot de volgende verbinding standhoudt, is het gebruikelijke resultaat van een oplossing op de verkeerde laag.

Laat een secundair resolverpad achter dat niet van de tunnel afhangt, zodat een storing bij Pi-hole uitmondt in ongefilterd browsen in plaats van helemaal geen browsen. Bewaar de vorige DHCP- en resolverwaarden tot de test twee keer slaagt; een wijziging die het internet van het huishouden bij het avondeten breekt, is veel moeilijker te debuggen dan een die je in een minuut terugdraait.