Pourquoi Pi-hole v6 ignore les requêtes DNS des clients WireGuard

Pi-hole v6 reçoit une requête DNS sur le port 53, puis décide si le paquet arrivé peut recevoir une réponse. Sur un hôte WireGuard, cette seconde décision est généralement la raison pour laquelle un client subit un délai d’attente alors que le résolveur semble sain depuis le LAN. Le port est ouvert, FTL tourne, et pourtant rien ne revient de 10.90.0.1. Trois éléments interagissent avant qu’une réponse ne parte : dns.interface, dns.listeningMode et le pare-feu devant les deux.

Le socket d’écoute ne décide pas qui reçoit une réponse

FTL ouvre des écouteurs UDP et TCP sur le port 53. Dans la configuration par défaut, le socket est souvent wildcard, donc ss -lunp | grep :53 affiche 0.0.0.0:53 et [::]:53, que des clients VPN soient servis ou non. Un socket wildcard accepte le paquet, puis FTL applique ses règles d’interface et de source avant de répondre. C’est pourquoi « le port écoute » ne prouve presque rien sur un client de tunnel.

Lisez la configuration en cours plutôt que le fichier que vous croyez actif. pihole-FTL --config dns.interface et pihole-FTL --config dns.listeningMode affichent les valeurs effectives, et elles peuvent différer du fichier de l’hôte lorsqu’un conteneur, une variable d’environnement ou un gestionnaire de déploiement possède le réglage. La référence de configuration de Pi-hole FTL liste les modes et lequel d’entre eux repose sur l’interface.

LOCAL demande quel sous-réseau, SINGLE demande quelle interface

LOCAL, le mode par défaut, répond aux requêtes dont l’adresse source appartient à un sous-réseau configuré sur l’une des interfaces de l’hôte. Un simple wg0 avec 10.90.0.1/24 passe ce test, car le client à 10.90.0.2 se trouve à l’intérieur du sous-réseau du tunnel. Un client routé de l’autre côté d’un pair, ou un client caché derrière NAT dans un autre préfixe, ne le passe pas alors que le paquet est arrivé sur wg0, et aucune requête n’apparaît dans le journal.

SINGLE change la question. Il accepte les requêtes qui arrivent sur l’interface nommée dans dns.interface, loopback inclus, et ignore le sous-réseau source. C’est le mode qui survit à une topologie VPN chaînée ou routée. Définissez les deux clés ensemble, car un mode sans interface nommée n’est pas une instruction complète :

sudo pihole-FTL --config dns.interface "wg0"
sudo pihole-FTL --config dns.listeningMode "SINGLE"

BIND change le socket, et cela a un coût

BIND ne filtre pas un socket wildcard ; il lie le port 53 uniquement aux adresses qui existent sur l’interface nommée, si bien que le noyau refuse les paquets qui arrivent ailleurs. Il est plus strict que SINGLE et n’en est pas synonyme. Le coût apparaît au démarrage : si wg0 n’est pas montée quand FTL démarre, il peut n’y avoir aucune adresse à lier, et le résolveur peut tourner sans écouteur jusqu’à ce que l’interface apparaisse et que FTL redémarre.

Choisissez BIND lorsque vous maîtrisez l’ordre de démarrage, par exemple une unité systemd ordonnée après l’interface WireGuard, et lorsque vous voulez que le noyau rejette les paquets errants avant que FTL ne les voie. Choisissez SINGLE lorsque le tunnel va et vient, ou lorsque l’interface est créée par un outil qui démarre après FTL.

Le pare-feu est la seconde porte

Un mode FTL correct échoue encore si le pare-feu de l’hôte rejette le port 53 sur wg0. Autorisez la plage source du VPN pour les deux protocoles et gardez le côté Internet fermé. Dans nftables, avec la chaîne input existante dans la table inet filter, les règles ressemblent à ceci :

sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 udp dport 53 accept
sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 tcp dport 53 accept

Ajoutez des règles IPv6 correspondantes si le tunnel transporte de l’IPv6, et placez-les avant la politique de rejet de la chaîne. Si l’hôte utilise ufw ou firewalld, exprimez la même correspondance dans ce gestionnaire au lieu de mélanger les outils. Ne transférez pas le port 53 depuis le routeur Internet ; les clients doivent joindre l’adresse VPN du résolveur à travers le tunnel.

Deux chemins restent séparés. Les requêtes des clients se terminent sur FTL. Les recherches amont de FTL sortent selon la table de routage de l’hôte, qui peut ou non utiliser le tunnel, donc un résolveur qui répond mais ne renvoie rien d’utile est un problème amont. L’administration web et l’API écoutent sur leurs propres ports et ont besoin de leur propre restriction.

Vérifiez la réponse et le refus

Depuis un client VPN, interrogez l’adresse du résolveur avec les deux protocoles : dig @10.90.0.1 example.com et dig +tcp @10.90.0.1 example.com. Vérifiez ensuite le journal des requêtes dans l’interface d’administration pour confirmer que FTL a enregistré la requête. Un délai d’attente du client sans entrée dans le journal pointe vers le pare-feu ou le filtre d’interface ; une entrée sans réponse pointe vers la résolution amont.

Testez le chemin négatif depuis un hôte hors du VPN. dig @10.90.0.1 example.com devrait expirer, et ss -lunp sur le résolveur ne devrait pas montrer le port 53 lié à une adresse publique. Redémarrez le service une fois, puis redémarrez l’hôte et confirmez que le résolveur répond toujours lorsque wg0 réapparaît. Une requête qui ne fonctionne que jusqu’au prochain redémarrage n’est pas un changement terminé.