Comment The Social Dork crée un bloqueur de publicités Pi-hole avec ZimaBoard 2

Merci à The Social Dork | Cybersécurité d’avoir partagé un projet Pi-hole et Tailscale qui filtre les requêtes DNS à la maison et depuis un téléphone hors du domicile. ZimaBoard 2 exécute les services, Pi-hole vérifie les domaines demandés et Tailscale fournit une connexion privée au serveur. Regardez le tutoriel vidéo original sur YouTube pour voir la démonstration complète.

À regarder avant de lire : cette vidéo de huit minutes est utile si vous souhaitez comprendre le rôle du filtrage publicitaire au niveau du réseau avant de modifier les paramètres DNS de votre domicile. Le créateur installe Pi-hole dans ZimaOS, teste un client Windows, ajoute des listes de blocage, puis connecte un téléphone via Tailscale.

Le résultat utile est un service de filtrage DNS réutilisable. Le créateur montre moins de publicités visibles sur un site Web de démonstration et l’activité des requêtes depuis le téléphone distant. Ces observations montrent que le filtrage fonctionne dans cette configuration ; elles ne prouvent pas que toutes les publicités, tous les traceurs ou toutes les connexions malveillantes seront bloqués.

Comprendre ce que Pi-hole filtre avant de choisir le matériel

L’explication commence par un site Web qui charge du contenu depuis plusieurs domaines. Pi-hole reçoit les requêtes DNS du client et vérifie les noms demandés par rapport à la politique configurée. Les noms autorisés peuvent être résolus par l’intermédiaire d’un résolveur amont ; les noms bloqués reçoivent une réponse de blocage. Le point de contrôle essentiel est la requête DNS, avant que le client tente de récupérer du contenu depuis ce domaine.

Cette portée définit aussi les limites. Un filtre DNS ne peut pas distinguer une publicité d’un contenu souhaité lorsque les deux utilisent le même nom d’hôte. Les clients qui utilisent un autre résolveur peuvent contourner le chemin choisi. Considérez le titre de la vidéo, « bloquer toutes les publicités », comme la motivation du projet, et non comme un résultat universel. Le filtrage du contenu par le navigateur et le filtrage DNS interviennent à des niveaux différents et peuvent se compléter.

Suivez une requête DNS de bout en bout avant de modifier tout un réseau. Un client demande un nom d’hôte ; Pi-hole applique sa politique ; une requête autorisée peut atteindre le résolveur amont ; la réponse revient au client. La connexion Web qui suit constitue un flux distinct. Cela explique pourquoi le compteur de domaines bloqués est un indicateur utile de l’activité DNS, mais ne mesure pas toutes les connexions établies par une application.

Assurez au service DNS une place stable sur le réseau domestique

The Social Dork utilise ZimaBoard 2 et installe Pi-hole depuis la boutique d’applications ZimaOS montrée dans la vidéo. Le créateur mentionne également un ordinateur portable existant comme autre option d’hébergement. En pratique, il faut une machine qui reste disponible chaque fois que les appareils dépendent d’elle pour le DNS ; la démonstration ne justifie pas l’achat de l’option de mémoire la plus élevée pour le simple filtrage.

Connectez l’hôte, attribuez une adresse stable au point de terminaison DNS ou réservez-lui une adresse DHCP, puis confirmez que le service est accessible depuis un appareil de test. La mise en réseau des conteneurs et les mappages de ports déterminent l’adresse que les appareils doivent utiliser. Vérifiez que votre installation répond réellement aux requêtes DNS à ce point de terminaison, au lieu de supposer qu’une page d’administration accessible signifie que le service DNS est prêt.

Notez les adresses avant de modifier la configuration d’un appareil

Pour une installation en conteneur, vérifiez l’accessibilité du service DNS via TCP et UDP. L’exemple officiel Docker de Pi-hole expose les deux protocoles sur le port 53 et conserve son répertoire de configuration. Ces détails comptent même lorsqu’une boutique d’applications masque la configuration du conteneur derrière un bouton Installer. Consultez la configuration réelle de l’application avant de modifier un service hôte susceptible d’utiliser déjà le même port.

La vidéo montre l’installation depuis la boutique d’applications ZimaOS du créateur. Votre version actuelle de l’application et votre mode réseau peuvent différer. Conservez les paramètres qui expliquent comment l’application accède au réseau : son adresse, les ports publiés, l’emplacement de stockage, le résolveur en amont et le comportement au redémarrage. Cette petite fiche facilitera la vérification d’une migration ou d’une réinstallation ultérieure.

Testez un appareil avant de modifier le DNS pour tout le foyer

Dans le tutoriel, un ordinateur portable Windows reste connecté au Wi-Fi domestique tandis que son paramètre DNS IPv4 est remplacé par l’adresse Pi-hole. Le créateur vérifie ensuite l’activité des requêtes. C’est un premier test facile à gérer : si la navigation cesse de fonctionner, il suffit de rétablir la configuration sur ce seul appareil, tandis que le reste du foyer conserve ses paramètres actuels.

Pour étendre la couverture, le guide de post-installation de Pi-hole explique comment le DHCP peut communiquer l’adresse DNS de Pi-hole aux clients. Renouvelez le bail du client ou reconnectez-vous, puis vérifiez le résolveur qu’il utilise réellement. Vérifiez également le DNS IPv6 ainsi que les paramètres DNS chiffrés du navigateur ou du système d’exploitation ; modifier un seul champ IPv4 ne garantit pas que toutes les requêtes l’empruntent.

Un second résolveur non filtré peut également compromettre le résultat attendu. Les clients peuvent en utiliser un autre au lieu de le garder strictement en secours. Déterminez si votre priorité est la continuité du service ou la cohérence du filtrage, puis testez le comportement lorsque l’hôte Pi-hole est indisponible. Conservez les paramètres d’origine afin de pouvoir facilement annuler l’expérience DNS.

Effectuer un test reproductible en local

1. Notez la configuration DNS actuelle de l’ordinateur portable et l’adresse prévue pour Pi-hole.
2. Envoyez explicitement à Pi-hole une requête autorisée, puis repérez-la dans son journal.
3. Testez un domaine figurant dans votre propre liste de blocage active et vérifiez qu’il est bien bloqué.
4. Définissez Pi-hole comme serveur DNS habituel du client, puis répétez le test sans sélectionner explicitement de résolveur.
5. Testez quelques services courants, notamment un processus de connexion, avant de déployer la modification par DHCP.

Par exemple, nslookup example.com PIHOLE_LAN_IP interroge un serveur DNS nommé ; remplacez PIHOLE_LAN_IP par l’adresse de votre serveur. Cette requête explicite vérifie le serveur lui-même. Une commande nslookup example.com lancée ensuite vérifie le chemin de résolution DNS habituel du système. Aucun de ces tests ne prouve à lui seul qu’un navigateur utilisant ses propres paramètres DNS emprunte le même chemin ; vérifiez donc aussi une nouvelle requête effectuée depuis cette application.

Pour rechercher la cause d’une panne, distinguez l’accessibilité des adresses de la résolution des noms. Un appareil peut rester connecté au Wi-Fi tout en ne parvenant pas à ouvrir des sites si son serveur DNS est hors ligne. Conservez les paramètres d’origine du client jusqu’à ce que le nouveau résolveur fonctionne de manière fiable. Après une modification du DHCP, renouvelez le bail ou reconnectez-vous, puis vérifiez les paramètres effectivement reçus par le client.

Ajoutez des listes de blocage de façon à pouvoir résoudre les problèmes

Le créateur importe ensuite d’autres listes de blocage et montre l’augmentation du nombre de domaines bloqués. Ce nombre décrit la base de données des règles, et non la qualité de la navigation. Une liste plus longue peut inclure davantage de domaines indésirables, mais elle peut aussi perturber les processus de connexion, les lecteurs multimédias ou d’autres fonctionnalités qui dépendent d’un service partagé.

Ajoutez une liste maintenue à la fois, actualisez la base de données de filtrage, puis retestez les services que vous utilisez réellement. En cas de panne, utilisez le journal des requêtes pour identifier le nom concerné et testez une entrée d’autorisation ciblée. La documentation sur la base de données des domaines de Pi-hole explique les interactions entre les entrées d’autorisation et de blocage. Évitez de résoudre un problème de connexion isolé en autorisant largement une collection de domaines sans rapport.

Conservez la raison de chaque nouvelle liste ou exception avec la modification. Une politique bien conçue doit tenir une semaine d’utilisation normale, et pas seulement produire une capture d’écran réussie. Si vous gérez le filtre pour d’autres personnes, donnez-leur un moyen de décrire un service en panne et l’heure approximative de la panne. C’est plus utile qu’un signalement général indiquant que « l’internet est en panne ».

Utilisez Tailscale pour accéder au même filtre hors de chez vous

Dans la seconde moitié, Tailscale est installé sur le serveur et un téléphone. Dans les paramètres DNS du tailnet, The Social Dork saisit l’adresse Tailscale du serveur comme serveur de noms, puis connecte le téléphone et vérifie à nouveau l’activité de Pi-hole. Le point de terminaison DNS reste à la maison, tandis que le téléphone autorisé peut y accéder via le réseau privé.

Le guide officiel d’intégration de Pi-hole de Tailscale fournit les dernières instructions de configuration. Vérifiez que Pi-hole accepte les requêtes arrivant par l’interface privée prévue et que la politique d’accès du tailnet autorise le trafic DNS. Si vous souhaitez que les clients compatibles privilégient le serveur de noms configuré pour le tailnet, consultez le comportement du remplacement DNS de Tailscale et vérifiez le paramètre sur le client concerné.

L’utilisation d’un résolveur DNS domestique via Tailscale n’achemine pas automatiquement tout le trafic Web par la connexion domestique. La sortie Internet complète via un nœud de sortie domestique nécessite une configuration distincte. Ce projet nécessite uniquement une route privée vers le service DNS ; il n’est pas nécessaire d’exposer un résolveur DNS public ni sa page d’administration sur Internet.

Valider le chemin DNS privé par étapes

1. Vérifiez que le serveur et le téléphone sont inscrits dans le tailnet prévu et peuvent communiquer entre eux.
2. Ajoutez le point de terminaison Pi-hole accessible comme serveur de noms prévu pour le tailnet.
3. Vérifiez l’utilisation de Tailscale DNS par le client et le paramètre de remplacement du serveur de noms pour obtenir le comportement souhaité.
4. Vérifiez que l’écouteur Pi-hole et la politique d’accès autorisent les requêtes DNS provenant de ce chemin privé.
5. Désactivez le Wi-Fi domestique et répétez depuis votre téléphone une requête autorisée et une requête bloquée.

Un écouteur configuré pour n’accepter que les requêtes provenant d’un réseau local donné peut expliquer pourquoi les appareils connectés au réseau domestique fonctionnent, alors qu’un appareil connecté via Tailscale échoue. La référence de configuration de l’écouteur DNS de Pi-hole décrit les modes disponibles. Choisissez un mode compatible avec votre conteneur et votre réseau privé, tout en limitant l’accès entrant aux appareils prévus. Des paramètres d’écoute plus larges nécessitent des règles de pare-feu tout aussi claires.

Distinguez également les paramètres DNS du trafic sortant vers Internet. Un serveur de noms peut filtrer les requêtes sans devenir un nœud de sortie. Si vous activez séparément un nœud de sortie, vérifiez à nouveau son comportement DNS ; Tailscale explique cette interaction dans sa référence DNS et serveurs de noms. Un test réussi sur le Wi-Fi domestique ne remplace pas le test du même téléphone sur le réseau mobile.

Faites porter le test final sur le chemin, pas uniquement sur un compteur

Répétez le test depuis une autre connexion, par exemple en utilisant les données mobiles avec le Wi-Fi désactivé. Vérifiez qu’une nouvelle requête depuis le téléphone apparaît dans Pi-hole, qu’un site autorisé s’ouvre toujours et que le nom bloqué choisi reçoit une réponse de filtrage. Une hausse du total à elle seule peut inclure les requêtes d’autres appareils ; utilisez le client concerné et les horodatages pour relier l’observation à votre test.

La prochaine étape de la série de ce créateur est un pare-feu OPNsense avec DNS Pi-hole pour les clients sans fil. Pour un exemple plus général d’organisation des applications et de l’accès à distance, la configuration de homelab modulaire de kabuto montre comment ces services peuvent s’intégrer à une installation physique bien entretenue. Commencez par un client fonctionnel, puis élargissez la politique de filtrage après avoir vérifié les chemins local et distant. Revenez à la démonstration de Pi-hole et Tailscale par The Social Dork pour retrouver la séquence d’origine.

Diagnostiquer la première couche défaillante

Considérez ce service comme une dépendance du foyer dès que d’autres appareils l’utilisent. Sauvegardez sa configuration, conservez un ensemble fonctionnel de sources de filtrage et testez toute mise à jour d’abord avec un seul client. Après le redémarrage de l’hôte, vérifiez à nouveau une requête autorisée et une requête bloquée. Le retour de l’icône de l’application au tableau de bord n’est que le début de cette vérification.

La documentation sur la configuration des conteneurs de Pi-hole explique les options de persistance et de réseau. Conservez ces informations opérationnelles avec la configuration que vous avez choisie plutôt que de vous fier à une capture d’écran de l’adresse de quelqu’un d’autre.

FAQ

Pi-hole supprimera-t-il toutes les publicités YouTube ?

Le filtrage DNS ne peut pas distinguer de façon fiable les vidéos souhaitées de la publicité lorsqu’elles partagent le même nom d’hôte. Considérez ce projet comme du filtrage par domaine et vérifiez le fonctionnement des applications que vous utilisez au lieu de promettre l’absence de publicité partout.

Tous les appareils du foyer doivent-ils utiliser Tailscale ?

Les appareils domestiques peuvent utiliser un point d’accès Pi-hole sur le réseau local en configurant leurs paramètres DNS. Dans ce projet, Tailscale fournit une connexion privée aux appareils qui doivent utiliser le même résolveur lorsqu’ils sont hors de la maison.

Ai-je besoin d’un nœud de sortie Tailscale pour cette configuration ?

Pas seulement pour accéder au service DNS privé. Un nœud de sortie modifie l’acheminement du trafic Internet et constitue une configuration distincte, avec son propre comportement DNS.

Pourquoi la page Pi-hole s’ouvre-t-elle alors que le DNS ne fonctionne pas ?

L’interface web et le service DNS utilisent des ports différents et peuvent avoir des mappages de ports ou des règles d’accès distincts dans le conteneur. Envoyez directement une requête DNS à l’adresse prévue et vérifiez l’entrée correspondante dans le journal.

Pourquoi un autre serveur DNS peut-il contourner le filtrage ?

Les clients ne considèrent pas forcément un deuxième serveur de noms configuré comme un simple secours en cas d’urgence. Si la cohérence du filtrage est importante, vérifiez tous les résolveurs annoncés et le comportement réel du client.

Que dois-je enregistrer avant de mettre l’application à jour ?

Enregistrez la configuration fonctionnelle de l’application, les emplacements des données persistantes, les sources de filtrage et les paramètres client utilisés pour un test concluant. Après la mise à jour, répétez ce test et vérifiez que les paramètres ont été conservés.

Conclusion

Le projet de The Social Dork relie trois décisions : où le DNS s’exécute, quels clients l’utilisent et comment un téléphone autorisé y accède depuis un autre réseau. Une installation efficace rend ces décisions visibles et vérifiables. Les meilleurs éléments de preuve sont une requête client correspondante, la réponse de filtrage attendue et une navigation ordinaire qui fonctionne toujours.

Commencez avec un seul client, passez au DHCP une fois le test local réussi et vérifiez Tailscale depuis une connexion réellement distincte. Ensuite, gérez le filtrage comme un service dont le foyer dépend. Gardez la vidéo sur Pi-hole et Tailscale d’origine pour suivre la séquence du créateur, ainsi que la documentation officielle à jour correspondant aux versions que vous avez installées.