Perché Pi-hole v6 ignora le query DNS dei client WireGuard

Pi-hole v6 riceve una query DNS sulla porta 53 e poi decide se al pacchetto arrivato è consentito rispondere. Su un host WireGuard questa seconda decisione è di solito il motivo per cui un client va in timeout mentre il resolver sembra sano dalla LAN. La porta è aperta, FTL è in esecuzione, eppure non torna nulla da 10.90.0.1. Tre cose interagiscono prima che una risposta esca: dns.interface, dns.listeningMode e il firewall davanti a entrambe.

Il socket in ascolto non decide chi riceve una risposta

FTL apre listener UDP e TCP sulla porta 53. Nella configurazione predefinita il socket è spesso wildcard, quindi ss -lunp | grep :53 mostra 0.0.0.0:53 e [::]:53 indipendentemente dal fatto che i client VPN siano serviti. Un socket wildcard accetta il pacchetto, poi FTL applica le sue regole di interfaccia e di origine prima di rispondere. Per questo "la porta è in ascolto" dimostra molto poco su un client in tunnel.

Leggi la configurazione in esecuzione invece del file che credi attivo. pihole-FTL --config dns.interface e pihole-FTL --config dns.listeningMode stampano i valori effettivi, e possono differire dal file dell’host quando un container, una variabile d’ambiente o un gestore di distribuzione possiede l’impostazione. La riferimento di configurazione di Pi-hole FTL elenca le modalità e quale di esse dipende dall’interfaccia.

LOCAL chiede quale sottorete, SINGLE chiede quale interfaccia

LOCAL, la modalità predefinita, risponde alle query il cui indirizzo di origine appartiene a una sottorete configurata su una delle interfacce dell’host. Un semplice wg0 con 10.90.0.1/24 supera quel test, perché il client su 10.90.0.2 si trova dentro la sottorete del tunnel. Un client instradato dall’altra parte di un peer, o uno nascosto dietro NAT in un prefisso diverso, non lo supera anche se il pacchetto è arrivato su wg0, e nel registro non compare alcuna query.

SINGLE cambia la domanda. Accetta le query che arrivano sull’interfaccia indicata in dns.interface, loopback incluso, e ignora la sottorete di origine. È la modalità che sopravvive a una topologia VPN concatenata o instradata. Imposta entrambe le chiavi insieme, perché una modalità senza interfaccia indicata non è un’istruzione completa:

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

BIND cambia il socket, e questo ha un costo

BIND non filtra un socket wildcard; lega la porta 53 solo agli indirizzi che esistono sull’interfaccia indicata, così il kernel rifiuta i pacchetti che arrivano altrove. È più rigoroso di SINGLE e non ne è un sinonimo. Il costo compare all’avvio: se wg0 non è attiva quando FTL parte, potrebbe non esserci alcun indirizzo a cui legarsi, e il resolver può funzionare senza listener finché l’interfaccia non appare e FTL non si riavvia.

Scegli BIND quando controlli l’ordine di avvio, per esempio un’unità systemd ordinata dopo l’interfaccia WireGuard, e quando vuoi che il kernel scarti i pacchetti vaganti prima che FTL li veda. Scegli SINGLE quando il tunnel va e viene, o quando l’interfaccia è creata da uno strumento che parte dopo FTL.

Il firewall è la seconda porta

Una modalità FTL corretta fallisce comunque se il firewall dell’host scarta la porta 53 su wg0. Consenti l’intervallo di origine della VPN per entrambi i protocolli e mantieni chiuso il lato Internet. In nftables, con la catena input esistente nella tabella inet filter, le regole sono così:

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

Aggiungi regole IPv6 corrispondenti se il tunnel trasporta IPv6, e mettile prima della politica di scarto della catena. Se l’host usa ufw o firewalld, esprimi la stessa corrispondenza in quel gestore invece di mescolare strumenti. Non inoltrare la porta 53 dal router Internet; i client devono raggiungere l’indirizzo VPN del resolver attraverso il tunnel.

Due percorsi restano separati. Le query dei client terminano su FTL. Le ricerche upstream di FTL escono secondo la tabella di routing dell’host, che può usare o meno il tunnel, quindi un resolver che risponde ma non restituisce nulla di utile è un problema upstream. L’amministrazione web e l’API ascoltano sulle proprie porte e necessitano di una propria restrizione.

Verifica la risposta e il rifiuto

Da un client VPN, interroga l’indirizzo del resolver con entrambi i protocolli: dig @10.90.0.1 example.com e dig +tcp @10.90.0.1 example.com. Poi controlla il registro delle query nell’interfaccia di amministrazione per confermare che FTL abbia registrato la query. Un timeout del client senza voce nel registro punta al firewall o al filtro di interfaccia; una voce senza risposta punta alla risoluzione upstream.

Prova il percorso negativo da un host fuori dalla VPN. dig @10.90.0.1 example.com dovrebbe scadere, e ss -lunp sul resolver non dovrebbe mostrare la porta 53 legata a un indirizzo pubblico. Riavvia il servizio una volta, poi riavvia l’host e conferma che il resolver risponda ancora quando wg0 riappare. Una query che funziona solo fino al prossimo riavvio non è una modifica conclusa.