Puntare i client OpenVPN su un resolver Pi-hole su un altro host

Mettere un indirizzo Pi-hole in un profilo OpenVPN non crea un percorso verso di esso, non concede il permesso di interrogarlo né garantisce che il client lo usi. Con Pi-hole su una macchina separata della LAN, quattro cose devono allinearsi: la rotta dal client, l’inoltro dal gateway, il percorso di ritorno verso il pool e la politica di ricezione su Pi-hole stesso. Ogni guasto si presenta diversamente in un log. Affrontarli in quest’ordine è più rapido che correggere per primo l’ultimo. La scorciatoia abituale, aprire la ricorsione a ogni origine, scambia un piccolo problema con uno permanente.

Cosa fa e cosa non fa l’opzione DNS inviata

Il server annuncia un resolver con la direttiva seguente, supponendo che 192.168.50.53 sia l’host Pi-hole. Il client riceve l’opzione e, a seconda della piattaforma e dell’integrazione del resolver , la applica all’interfaccia del tunnel oppure la ignora in favore di uno stub locale. La riga della rotta conta quanto quella DNS, perché un resolver che il client non riesce a raggiungere non è affatto un resolver. Nulla di questo è visibile dal lato server.

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"

Ricevere un’opzione non è lo stesso che usarla. Un client Linux con un gestore di resolver può accettare il server inviato e mandargli solo certi domini; un client che gestisce il DNS da sé può sovrascrivere del tutto l’impostazione. Anche le rotte inviate sono limitate su alcune piattaforme, il che lascia il resolver irraggiungibile anche se l’opzione è stata accettata. Controlla sul client quale server risponde, non sul server cosa è stato inviato.

L’opzione non dice nulla nemmeno sul lato server. Il traffico DNS deve comunque viaggiare dal client al gateway e dal gateway a Pi-hole prima che qualsiasi opzione conti. Una rotta mancante e una query rifiutata sembrano uguali dal client, quindi conferma prima l’inoltro sul gateway.

Il percorso di ritorno da Pi-hole al pool

Se l’indirizzo sorgente del client viene preservato, Pi-hole risponde a un indirizzo interno al pool VPN. La sua tabella di routing probabilmente non sa nulla di quel pool, quindi la risposta va al suo gateway predefinito e sparisce. Il log delle query mostra una richiesta senza risposta corrispondente, cosa facile da fraintendere come problema di firewall.

Assegna al router della LAN una rotta statica per il pool con il gateway OpenVPN come next hop, oppure traduci la sorgente sul gateway prima di inoltrare a Pi-hole. La prima soluzione mantiene gli indirizzi di ogni client visibili nel log delle query di Pi-hole. La seconda elimina il requisito della rotta di ritorno ma fa sembrare ogni query proveniente dal gateway. Nessuna delle due è sbagliata; rispondono a domande diverse.

Se contano il reporting o le policy per client, la rotta statica è lo scambio migliore. Se la LAN è gestita da altri e una rotta non è disponibile, la traduzione è l’opzione pragmatica, con la perdita dell’identità del client messa per iscritto. Annota quale hai scelto, perché ogni domanda successiva sui log dipende da questo.

La modalità di ascolto di Pi-hole per i client instradati

Il menu a tendina del comportamento di ascolto delle interfacce, nella pagina delle impostazioni sotto DNS, decide a quali sorgenti Pi-hole risponde. L’opzione più restrittiva accetta solo client su reti direttamente collegate; l’opzione che consente dispositivi ad al massimo un hop lo estende alle sottoreti dietro un router adiacente, ed è esattamente l’aspetto di un client VPN instradato. Il pacchetto arriva davvero sull’interfaccia LAN, ma il suo indirizzo sorgente appartiene a un’altra sottorete. È un rifiuto di policy e non un guasto di routing, e la differenza conta quando leggi i log.

La guida all’ascolto di Pi-hole separa le sorgenti collegate localmente dalle origini instradate, e l’interfaccia di arrivo non è il criterio. Scegli una modalità che consenta il pool VPN senza consentire tutto internet, poi abbinala a una regola di firewall che accetti DNS solo dal pool.

Aprire la ricorsione a tutte le origini per far funzionare la prima query è la riparazione sbagliata. Trasforma un resolver privato in uno aperto, e la correzione è un permesso circoscritto anziché globale.

Far combaciare la risposta con il log delle query

Interroga il client, poi controlla il server e confronta i due. Su un client systemd-resolved i comandi seguenti riportano quale resolver ha prodotto una risposta e quali server sono configurati per collegamento. Usa un nome che conosce solo Pi-hole, perché una query diretta all’indirizzo Pi-hole dimostra la raggiungibilità, non la configurazione.

resolvectl query intranet.example.lan
resolvectl dns

La risposta attesa indica 192.168.50.53 come server e restituisce un indirizzo che solo quel resolver conoscerebbe. Poi guarda la vista di Pi-hole: pihole -t segue il log delle query in diretta, e ogni riga porta l’indirizzo sorgente. Se la sorgente è l’indirizzo di tunnel del client, la rotta del pool è intatta. Se è l’indirizzo LAN del gateway, è in gioco la traduzione della sorgente e l’indirizzo del client non apparirà mai.

Se nel log non appare nulla, la query non ha mai raggiunto Pi-hole e l’inoltro sul gateway è la cosa successiva da controllare. Se la query appare e non torna alcuna risposta, il problema è il percorso di ritorno, cioè la sezione precedente. Dividere il guasto in questo modo impedisce di scambiare un errore di routing per una regola di firewall.

Controllare la regola di inoltro del gateway

Il gateway deve inoltrare i pacchetti DNS del client verso Pi-hole, e la regola che lo fa vale la pena di leggerla invece di darla per scontata. I comandi seguenti elencano le regole che toccano la porta 53 con i contatori, su un host nftables e su un host iptables. Una regola che esiste ma mostra zero corrispondenze è il segnale che il traffico viene scartato prima di essere tradotto.

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

Leggi i contatori, non solo le regole. Una regola che non corrisponde mai significa che il pacchetto esce da un’altra interfaccia, oppure che il client non l’ha mai inviato. Una regola che corrisponde a ogni query significa che l’inoltro funziona e che il problema è più avanti lungo il percorso.

Qualunque strumento usi l’host, mantieni il controllo stretto: il pool come sorgente, la porta 53 come destinazione e Pi-hole come unico bersaglio consentito. Una regola di inoltro ampia che consente anche la porta 80 è un altro problema in attesa di accadere.