Pi-hole ne bloque pas les publicités après la connexion VPN : cinq vérifications

Les publicités s'affichent encore sur un client, Pi-hole se déclare sain et le tunnel est actif, donc le réflexe est d'acheminer le trafic de ce client à travers le Pi. C'est le mauvais virage. Le filtrage a besoin des questions, pas des paquets, et un client dont les requêtes vont au résolveur du fournisseur reste non filtré, quel que soit le chemin de son trafic. Parcourez cette liste dans l'ordre et arrêtez-vous à la première étape qui échoue, car une étape ultérieure ne peut rien vous dire tant qu'une précédente est cassée.

1. Lisez le résolveur que le client utilise réellement

Interrogez le client, pas le routeur. Sous Linux, resolvectl status affiche les serveurs DNS par lien et le lien qui gagne ; /etc/resolv.conf seul est généralement un stub qui pointe vers 127.0.0.53. Sous Windows, ipconfig /all liste les serveurs fournis par DHCP par adaptateur, et sous macOS scutil --dns montre la même chose par portée. Si la réponse n'est pas l'adresse de Pi-hole, vous avez un problème d'attribution et l'étape 2 est l'endroit où il se trouve.

Deux choses défont le résolveur du système même lorsqu'il est correctement configuré. Les navigateurs dotés de leur propre DNS sécurisé (l'option “Use secure DNS” de Chrome, network.trr.mode de Firefox) envoient des requêtes via HTTPS à un résolveur public et n'ouvrent jamais le port 53. Et un client VPN sur le client lui-même peut installer un serveur DNS sur son interface de tunnel avec un domaine de routage ~., ce qui rend ce lien autoritaire pour tous les noms.

Testez le chemin que prennent les applications, pas celui que prend un outil de débogage. resolvectl query example.com montre quel lien a répondu, et getent hosts example.com passe par le même chemin NSS qu'une application ; sous macOS, dscacheutil -q host -a name example.com lit les résolveurs par portée que scutil --dns liste. Un dig nu ne le fait pas : il lit /etc/resolv.conf et ignore la sélection par lien, il peut donc répondre depuis Pi-hole alors que chaque application utilise le résolveur poussé, et c'est exactement la panne pour laquelle cette liste existe. Gardez dig @192.168.1.53 pour tester un serveur précis.

2. Confirmez qui distribue la réponse

L'attribution vient de ce qui répond au DHCP. Sur dnsmasq, c'est une seule ligne, dhcp-option=6,192.168.1.53 ; dans l'interface web d'un routeur, c'est le champ DNS de la section DHCP du LAN. Les clients doivent renouveler avant de le voir. Un appareil allumé depuis des jours conserve encore l'ancien bail, et un appareil avec un résolveur saisi à la main le conserve pour toujours. Renouvelez sur un client de test au lieu de supposer la propagation.

IPv6 est la moitié qui est oubliée. Les annonces de routeur peuvent transporter leur propre serveur DNS (RDNSS), et sous OpenWrt c'est l'option ra_dns d'odhcpd ; un client qui préfère IPv6 utilise ce serveur pendant que l'option DHCPv4 que vous venez de régler reste inutilisée. Si vous n'êtes pas prêt à servir du DNS en IPv6, effacez uniquement l'annonce DNS : ra_dns dans odhcpd, ou l'option RDNSS dans ce qui répond aux annonces de routeur. Désactiver toute l'annonce retire aussi l'adressage IPv6 du LAN, ce qui est un changement bien plus important que celui que vous vouliez faire, tandis qu'effacer seulement l'option DNS garde l'adressage intact et rend le RDNSS manquant visible dans une capture de paquets.

3. Prouvez que la requête atteint Pi-hole

Une requête depuis le Pi ne prouve rien sur le chemin réseau. Lancez-la depuis le client et lisez le code de réponse :

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

Un délai d'attente pointe vers le filtrage ou vers une route ; REFUSED pointe vers une règle d'accès ; SERVFAIL pointe vers le résolveur amont derrière Pi-hole ; une réponse correcte qui n'apparaît jamais dans le journal des requêtes signifie que le client a demandé autre chose. Vérifiez UDP et TCP 53, car les grandes réponses et certains résolveurs retombent sur TCP, et publiez les deux quand Pi-hole tourne dans un conteneur. Une correspondance qui ne couvre qu'UDP produit des défaillances intermittentes qui ressemblent à une perte de paquets.

Ensuite, le mode d'écoute de Pi-hole décide s'il répond tout court. En mode local uniquement, dnsmasq ignore les requêtes venant de sources qui ne sont pas sur un sous-réseau directement connecté, et c'est exactement à quoi ressemble un client derrière un autre routeur ou qui arrive par un tunnel : le client expire et la requête n'atteint jamais le journal. Une requête qui apparaît tout de même en REFUSED a été rejetée par une liste d'accès ou une règle de pare-feu. Autoriser toutes les origines est le correctif habituel, associé à une règle de pare-feu qui limite le port 53 à vos propres sous-réseaux.

4. Vérifiez si le tunnel a remplacé ou avalé la réponse

C'est le cas où se cachent les deux symptômes. Quand le routeur est lui-même un client VPN, une option DNS poussée peut remplacer le réglage du LAN à l'instant où le tunnel monte : les serveurs OpenVPN poussent dhcp-option DNS, et les profils WireGuard portent leur propre entrée DNS. Lisez le résolveur effectif du routeur avec le tunnel actif, pas avant, et ignorez ce que prétend la page du LAN.

L'autre défaut est l'accessibilité, pas le remplacement. Si les préfixes autorisés du tunnel incluent votre sous-réseau LAN, le routeur a une route qui envoie les requêtes pour 192.168.1.53 dans le tunnel, et l'autre côté n'a pas de route de retour : les requêtes expirent alors que le tunnel est sain. L'inverse se produit quand Pi-hole se trouve sur un sous-réseau que le tunnel ne transporte pas. Comparez l'adresse avec les préfixes autorisés du tunnel et la table de routage du routeur avant de retoucher au DNS.

Choisissez un correctif, pas les deux. Soit gardez le tunnel à l'écart du DNS — avec pull-filter ignore “dhcp-option DNS” sur OpenVPN et sans préfixe LAN dans AllowedIPs sur WireGuard —, soit acceptez le résolveur poussé et renoncez au filtrage local pour les clients derrière ce routeur. Quel que soit votre choix, écrivez-le à côté du profil, car la personne suivante qui le modifiera inversera sinon la décision par accident.

5. Répétez le test après une reconnexion

Faites une requête depuis un client, confirmez que ce client apparaît dans le journal de Pi-hole, puis résolvez un domaine qui devrait être bloqué et vérifiez que vous obtenez la réponse de blocage au lieu de la vraie. Reconnectez le tunnel et exécutez les deux mêmes requêtes, car un réglage de résolveur qui ne tient que jusqu'à la prochaine reconnexion est le résultat habituel d'un correctif appliqué à la mauvaise couche.

Laissez un chemin de résolveur secondaire qui ne dépend pas du tunnel, pour qu'une panne de Pi-hole se dégrade en navigation non filtrée plutôt qu'en absence de navigation. Gardez les valeurs DHCP et de résolveur précédentes jusqu'à ce que le test passe deux fois ; un changement qui casse l'internet du foyer à l'heure du dîner est bien plus difficile à déboguer qu'un changement que vous pouvez annuler en une minute.