Pi-hole non blocca gli annunci dopo la connessione VPN: cinque controlli

Gli annunci sono ancora visibili su un client, Pi-hole si dichiara sano e il tunnel è attivo, quindi l'istinto è instradare il traffico di quel client attraverso il Pi. È la svolta sbagliata. Il filtraggio richiede le domande, non i pacchetti, e un client le cui query vanno al resolver del provider resta non filtrato ovunque scorra il suo traffico. Segui questo elenco in ordine e fermati al primo passo che fallisce, perché un passo successivo non può dirti nulla mentre uno precedente è rotto.

1. Leggi il resolver che il client usa davvero

Chiedi al client, non al router. Su Linux resolvectl status stampa i server DNS per collegamento e quale collegamento vince; /etc/resolv.conf da solo è di solito uno stub che punta a 127.0.0.53. Su Windows ipconfig /all elenca i server forniti dal DHCP per adattatore, e su macOS scutil --dns mostra lo stesso per ambito. Se la risposta non è l'indirizzo di Pi-hole, hai un problema di assegnazione e il passo 2 è dove si trova.

Due cose sconfiggono il resolver di sistema anche quando è impostato correttamente. I browser con DNS sicuro proprio (l'opzione “Use secure DNS” di Chrome, network.trr.mode di Firefox) inviano le query via HTTPS a un resolver pubblico e non aprono mai la porta 53. E un client VPN sul client stesso può installare un server DNS sulla sua interfaccia tunnel con un dominio di instradamento ~., il che rende quel collegamento autorevole per ogni nome.

Testa il percorso che fanno le applicazioni, non quello che fa uno strumento di debug. resolvectl query example.com mostra quale collegamento ha risposto, e getent hosts example.com passa per lo stesso percorso NSS di un'applicazione; su macOS dscacheutil -q host -a name example.com legge i resolver per ambito che scutil --dns elenca. Un dig nudo non lo fa: legge /etc/resolv.conf e salta la selezione per collegamento, quindi può rispondere da Pi-hole mentre ogni applicazione usa il resolver inviato, ed è esattamente il guasto per cui esiste questo elenco. Tieni dig @192.168.1.53 per testare un server specifico.

2. Conferma chi distribuisce la risposta

L'assegnazione viene da qualunque cosa risponda al DHCP. Su dnsmasq è una sola riga, dhcp-option=6,192.168.1.53; nell'interfaccia web di un router è il campo DNS nella sezione DHCP della LAN. I client devono rinnovare prima di vederlo. Un dispositivo acceso da giorni conserva ancora il vecchio lease, e un dispositivo con un resolver digitato a mano lo conserva per sempre. Rinnova su un client di prova invece di dare per scontata la propagazione.

IPv6 è la metà che viene trascurata. Gli annunci del router possono trasportare il proprio server DNS (RDNSS), e su OpenWrt questa è l'opzione ra_dns di odhcpd; un client che preferisce IPv6 usa quel server mentre l'opzione DHCPv4 appena impostata resta inutilizzata. Se non sei pronto a servire DNS su IPv6, cancella solo l'annuncio DNS: ra_dns in odhcpd, o l'opzione RDNSS in qualunque cosa risponda agli annunci del router. Disattivare l'intero annuncio rimuove anche l'indirizzamento IPv6 dalla LAN, che è un cambiamento molto più grande di quello che intendevi, mentre cancellare solo l'opzione DNS mantiene l'indirizzamento intatto e rende visibile il RDNSS mancante in una cattura di pacchetti.

3. Dimostra che la query raggiunge Pi-hole

Una query dal Pi non dimostra nulla sul percorso di rete. Eseguila dal client e leggi il codice di risposta:

dig @192.168.1.53 example.com
dig @192.168.1.53 doubleclick.net

Un timeout indica il filtraggio o una route; REFUSED indica una regola di accesso; SERVFAIL indica il resolver a monte dietro Pi-hole; una risposta corretta che non compare mai nel registro delle query significa che il client ha chiesto altro. Controlla UDP e TCP 53, perché le risposte grandi e alcuni resolver ricadono su TCP, e pubblica entrambi quando Pi-hole gira in un container. Una mappatura che copre solo UDP produce guasti intermittenti che sembrano perdita di pacchetti.

Poi la modalità di ascolto di Pi-hole decide se risponde affatto. In modalità solo locale dnsmasq ignora le query provenienti da sorgenti che non sono su una sottorete collegata direttamente, ed è esattamente l'aspetto di un client dietro un altro router o che arriva da un tunnel: il client va in timeout e la query non raggiunge mai il registro. Una query che invece compare come REFUSED è stata rifiutata da una lista di accesso o da una regola del firewall. Consentire tutte le origini è il rimedio abituale, abbinato a una regola del firewall che limita la porta 53 alle tue sottoreti.

4. Controlla se il tunnel ha sostituito o inghiottito la risposta

È il caso in cui si nascondono entrambi i sintomi. Quando il router è esso stesso un client VPN, un'opzione DNS inviata può scavalcare l'impostazione della LAN nel momento in cui il tunnel sale: i server OpenVPN inviano dhcp-option DNS, e i profili WireGuard portano la propria voce DNS. Leggi il resolver effettivo del router con il tunnel attivo, non prima, e ignora ciò che dichiara la pagina della LAN.

L'altro difetto è la raggiungibilità, non la sostituzione. Se i prefissi consentiti del tunnel includono la tua sottorete LAN, il router ha una route che manda le query per 192.168.1.53 dentro il tunnel, e l'altro lato non ha una route di ritorno: le query vanno in timeout anche se il tunnel è sano. Il contrario accade quando Pi-hole si trova su una sottorete che il tunnel non trasporta. Confronta l'indirizzo con i prefissi consentiti del tunnel e con la tabella di routing del router prima di toccare di nuovo il DNS.

Scegli una correzione, non entrambe. O tieni il tunnel lontano dal DNS — con pull-filter ignore “dhcp-option DNS” su OpenVPN e senza prefisso LAN in AllowedIPs su WireGuard —, oppure accetta il resolver inviato e rinuncia al filtraggio locale per i client dietro quel router. Qualunque cosa scegli, scrivila accanto al profilo, perché la prossima persona che lo modificherà altrimenti invertirà la decisione per sbaglio.

5. Ripeti il test dopo una riconnessione

Fai una query da un client, conferma che quel client compare nel registro di Pi-hole, poi risolvi un dominio che dovrebbe essere bloccato e verifica di ottenere la risposta di blocco invece di quella reale. Riconnetti il tunnel ed esegui le stesse due query, perché un'impostazione del resolver che dura solo fino alla prossima connessione è il risultato abituale di una correzione applicata al livello sbagliato.

Lascia un percorso resolver secondario che non dipende dal tunnel, così un'interruzione di Pi-hole degrada in navigazione non filtrata invece che in assenza di navigazione. Mantieni i valori DHCP e del resolver precedenti finché il test non passa due volte; un cambiamento che rompe l'internet di casa all'ora di cena è molto più difficile da debuggare di uno che puoi annullare in un minuto.