Faire pointer les clients OpenVPN vers un résolveur Pi-hole sur un autre hôte

Mettre une adresse Pi-hole dans un profil OpenVPN ne crée pas de chemin vers elle, n’accorde pas le droit de l’interroger et ne garantit pas que le client l’utilise. Avec Pi-hole sur une machine distincte du LAN, quatre choses doivent s’aligner : la route depuis le client, le transfert depuis la passerelle, le chemin de retour vers le pool et la politique de réception sur Pi-hole lui-même. Chaque échec se présente différemment dans un journal. Les traiter dans cet ordre est plus rapide que de corriger le dernier en premier. Le raccourci habituel, ouvrir la récursion à toutes les origines, échange un petit problème contre un problème permanent.

Ce que fait et ne fait pas l’option DNS poussée

Le serveur annonce un résolveur avec la directive ci-dessous, en supposant que 192.168.50.53 est l’hôte Pi-hole. Le client reçoit l’option et, selon sa plateforme et son intégration de résolveur , l’applique à l’interface du tunnel ou l’ignore au profit d’un stub local. La ligne de route compte autant que la ligne DNS, car un résolveur que le client ne peut pas joindre n’est pas un résolveur du tout. Rien de tout cela n’est visible depuis le serveur.

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

Recevoir une option n’est pas la même chose que l’utiliser. Un client Linux doté d’un gestionnaire de résolveur peut accepter le serveur poussé et n’envoyer que certains domaines vers lui ; un client qui gère lui-même le DNS peut écraser entièrement le réglage. Les routes poussées sont aussi restreintes sur certaines plateformes, ce qui laisse le résolveur injoignable alors que l’option a été acceptée. Vérifiez sur le client quel serveur répond, et non sur le serveur ce qui a été envoyé.

L’option ne dit rien non plus du côté serveur. Le trafic DNS doit toujours voyager du client vers la passerelle, puis de la passerelle vers Pi-hole, avant qu’une option ne compte. Une route manquante et une requête refusée se ressemblent depuis le client : confirmez donc d’abord le transfert sur la passerelle.

Le chemin de retour de Pi-hole vers le pool

Si l’adresse source du client est préservée, Pi-hole répond à une adresse située dans le pool VPN. Sa propre table de routage ne connaît probablement rien de ce pool, aussi la réponse part-elle vers sa passerelle par défaut et disparaît. Le journal des requêtes montre une requête sans réponse correspondante, ce qu’on confond facilement avec un problème de pare-feu.

Donnez au routeur du LAN une route statique pour le pool, avec la passerelle OpenVPN comme saut suivant, ou traduisez la source sur la passerelle avant de transférer vers Pi-hole. La première solution garde les adresses de chaque client visibles dans le journal des requêtes de Pi-hole. La seconde supprime l’exigence de route de retour mais fait ressembler chaque requête à une requête de la passerelle. Aucune n’est fausse ; elles répondent à des questions différentes.

Si le rapport ou la politique par client importent, la route statique est le meilleur compromis. Si le LAN est géré par quelqu’un d’autre et qu’aucune route n’est disponible, la traduction est l’option pragmatique, avec la perte de l’identité du client consignée. Notez laquelle vous avez choisie, car chaque question de journal ultérieure en dépend.

Le mode d’écoute de Pi-hole pour les clients routés

La liste déroulante du comportement d’écoute des interfaces, sur la page des réglages sous DNS, décide des sources auxquelles Pi-hole répond. Son option la plus stricte n’accepte que les clients des réseaux directement rattachés ; l’option qui autorise les appareils à un saut au plus étend cela aux sous-réseaux derrière un routeur adjacent, ce qui est exactement l’allure d’un client VPN routé. Le paquet arrive bien sur l’interface du LAN, mais son adresse source appartient à un autre sous-réseau. C’est un refus de politique et non une défaillance de routage, et la différence compte quand on lit les journaux.

Le guide d’écoute de Pi-hole sépare les sources rattachées localement des origines routées, et l’interface d’arrivée n’est pas le critère. Choisissez un mode qui autorise le pool VPN sans autoriser tout l’internet, puis associez-le à une règle de pare-feu qui n’accepte le DNS que depuis le pool.

Ouvrir la récursion à toutes les origines pour faire fonctionner la première requête est la mauvaise réparation. Cela transforme un résolveur privé en résolveur ouvert, et la correction consiste en une permission ciblée plutôt que globale.

Faire correspondre la réponse au journal des requêtes

Interrogez le client, puis vérifiez le serveur, et comparez les deux. Sur un client systemd-resolved, les commandes ci-dessous indiquent quel résolveur a produit une réponse et quels serveurs sont configurés par lien. Utilisez un nom que seul Pi-hole connaît, car une requête directe vers l’adresse Pi-hole prouve la joignabilité, pas la configuration.

resolvectl query intranet.example.lan
resolvectl dns

La réponse attendue nomme 192.168.50.53 comme serveur et renvoie une adresse que seul ce résolveur connaîtrait. Regardez ensuite la vue propre à Pi-hole : pihole -t suit le journal des requêtes en direct, et chaque ligne porte l’adresse source. Si la source est l’adresse de tunnel du client, la route du pool est intacte. Si c’est l’adresse LAN de la passerelle, une traduction de source est en jeu et l’adresse propre du client n’apparaîtra jamais.

Si rien n’apparaît du tout dans le journal, la requête n’a jamais atteint Pi-hole et le transfert sur la passerelle est la chose à vérifier ensuite. Si la requête apparaît et qu’aucune réponse ne revient, le chemin de retour est le problème, c’est-à-dire la section précédente. Scinder l’échec de cette façon empêche de prendre une faute de routage pour une règle de pare-feu.

Vérifier la règle de transfert de la passerelle

La passerelle doit transférer les paquets DNS du client vers Pi-hole, et la règle qui s’en charge mérite d’être lue plutôt que supposée. Les commandes ci-dessous listent les règles qui touchent le port 53 avec leurs compteurs, sur un hôte nftables et sur un hôte iptables. Une règle qui existe mais affiche zéro correspondance est le signal que le trafic est abandonné avant d’être traduit.

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

Lisez les compteurs, pas seulement les règles. Une règle qui ne correspond jamais signifie que le paquet sort par une autre interface, ou que le client ne l’a jamais envoyé. Une règle qui correspond à chaque requête signifie que le transfert fonctionne et que le problème se trouve plus loin sur le chemin.

Quel que soit l’outil utilisé par l’hôte, gardez la vérification étroite : le pool comme source, le port 53 comme destination et Pi-hole comme seule cible autorisée. Une règle de transfert large qui autorise aussi le port 80 est un autre problème qui attend de survenir.