Come The Social Dork crea un blocco pubblicità Pi-hole con ZimaBoard 2

Grazie a The Social Dork | Cyber Security per aver condiviso un progetto con Pi-hole e Tailscale che filtra le richieste DNS a casa e da un telefono fuori casa. ZimaBoard 2 esegue i servizi, Pi-hole verifica i domini richiesti e Tailscale fornisce una connessione privata al server. Guarda il tutorial originale su YouTube per la dimostrazione completa.

Guarda prima di leggere: questo video di otto minuti è utile se vuoi capire quale ruolo abbia il filtraggio degli annunci a livello di rete prima di modificare le impostazioni DNS di casa. Il creatore installa Pi-hole in ZimaOS, testa un client Windows, aggiunge liste di blocco e poi connette un telefono tramite Tailscale.

Il risultato utile è un servizio di filtraggio DNS riutilizzabile. Il creatore mostra meno annunci visibili su un sito di esempio e l'attività delle richieste dal telefono remoto. Queste osservazioni dimostrano che il percorso di filtraggio funziona in quella configurazione; non dimostrano che verranno bloccati tutti gli annunci, i tracker o le connessioni dannose.

Scopri cosa filtra Pi-hole prima di scegliere l'hardware

La spiegazione parte da un sito web che carica contenuti da diversi domini. Pi-hole riceve le richieste DNS del client e verifica i nomi richiesti rispetto alla policy configurata. I nomi consentiti possono essere risolti tramite un resolver upstream; i nomi bloccati ricevono una risposta di blocco. Il punto di controllo importante è la richiesta DNS, prima che il client provi a recuperare contenuti da quel dominio.

Questo ambito definisce anche il limite. Un filtro DNS non può distinguere un annuncio da contenuti desiderati quando entrambi usano lo stesso nome host. I client che usano un altro resolver possono aggirare il percorso scelto. Considera il titolo del video, «bloccare tutti gli annunci», come la motivazione del progetto, non come un risultato universale. Il filtro dei contenuti del browser e il filtro DNS operano a livelli diversi e possono integrarsi a vicenda.

Segui una singola richiesta di risoluzione attraverso il sistema prima di modificare un'intera rete. Un client richiede un nome host; Pi-hole applica la propria policy; una richiesta consentita può raggiungere il resolver upstream; la risposta torna al client. La successiva connessione web è un flusso distinto. Questo spiega perché il contatore dei domini bloccati è un'indicazione utile dell'attività DNS, ma non misura tutte le connessioni effettuate da un'applicazione.

Assegna al servizio DNS una posizione stabile sulla rete domestica

The Social Dork usa ZimaBoard 2 e installa Pi-hole dall’app store di ZimaOS mostrato nel video. Il creator cita anche un laptop già disponibile come host alternativo. Il requisito pratico è una macchina che possa rimanere disponibile ogni volta che i client dipendono da essa per il DNS; la dimostrazione non giustifica l’acquisto dell’opzione con la memoria più ampia solo per il filtraggio.

Collega l’host, assegna all’endpoint DNS un indirizzo stabile o una prenotazione DHCP e verifica che il servizio sia raggiungibile da un client di prova. La rete del container e le mappature delle porte influiscono sull’indirizzo da usare per i client. Verifica che la tua installazione risponda effettivamente alle query DNS su quell’endpoint, anziché presumere che una pagina di amministrazione accessibile dimostri che il servizio DNS è pronto.

Annota gli indirizzi prima di modificare un client

In un’installazione in container, verifica che il servizio DNS sia raggiungibile sia tramite TCP sia tramite UDP. L’esempio ufficiale di Docker di Pi-hole espone entrambi i protocolli sulla porta 53 e mantiene persistente la directory di configurazione. Questi dettagli sono importanti anche quando un app store nasconde la configurazione del container dietro un pulsante Installa. Leggi la configurazione effettiva dell’app prima di modificare un servizio host che potrebbe già usare la stessa porta.

Il video mostra l’installazione dall’app store di ZimaOS del creator. La versione attuale dell’app e la modalità di rete potrebbero essere diverse. Conserva le impostazioni che spiegano come l’app accede alla rete: indirizzo, porte pubblicate, posizione di archiviazione, resolver upstream e comportamento al riavvio. Questa breve registrazione renderà più semplice verificare una migrazione o una reinstallazione futura.

Prova con un client prima di modificare il DNS per tutta la casa

Nel tutorial, un laptop Windows resta connesso al Wi-Fi di casa mentre l’impostazione DNS IPv4 viene modificata inserendo l’indirizzo di Pi-hole. L’autore controlla poi l’attività delle query. È un primo test gestibile: se la navigazione si interrompe, basta ripristinare le impostazioni di quel client, mentre il resto della famiglia mantiene la configurazione esistente.

Per una copertura più ampia, la guida post-installazione di Pi-hole spiega come il DHCP possa comunicare ai client l’indirizzo DNS di Pi-hole. Rinnova il lease del client o riconnettiti, quindi verifica quale resolver utilizza effettivamente. Controlla anche le impostazioni DNS IPv6 e quelle di DNS crittografato del browser o del sistema operativo; modificare un solo campo IPv4 non dimostra che tutte le query passino da lì.

Anche un secondo resolver senza filtri può compromettere il risultato previsto. I client potrebbero usare un altro resolver configurato anziché limitarlo strettamente ai casi di emergenza. Decidi se la priorità è la continuità del servizio o l’applicazione coerente dei filtri, quindi prova cosa accade quando l’host Pi-hole non è disponibile. Conserva una copia delle impostazioni originali, così sarà facile annullare l’esperimento DNS.

Esegui un test ripetibile in locale

1. Annota la configurazione DNS attuale del laptop e l’endpoint Pi-hole previsto.
2. Invia a Pi-hole una query consentita specificando il resolver, quindi cerca la query corrispondente nel log.
3. Prova un dominio presente nella tua denylist attiva e verifica che venga bloccato.
4. Imposta Pi-hole come DNS preferito del client e ripeti il test senza specificare esplicitamente un resolver.
5. Prova alcuni servizi di uso comune, inclusa una procedura di accesso, prima di distribuire la modifica tramite DHCP.

Ad esempio, nslookup example.com PIHOLE_LAN_IP interroga un resolver specifico; sostituisci PIHOLE_LAN_IP con l’indirizzo del tuo server. Questa query esplicita verifica direttamente l’endpoint. Un successivo nslookup example.com controlla il normale percorso di risoluzione del sistema. Nessuno dei due test, da solo, dimostra che un browser con impostazioni DNS proprie segua lo stesso percorso, quindi controlla anche una nuova richiesta da quell’applicazione.

Quando cerchi la causa di un guasto, distingui la raggiungibilità dell’indirizzo dalla risoluzione dei nomi. Un dispositivo può restare connesso al Wi-Fi e non riuscire comunque ad aprire i siti perché il suo server DNS non è disponibile. Mantieni a portata di mano le impostazioni originali del client finché il nuovo resolver non funziona in modo costante. Dopo una modifica al DHCP, rinnova il lease o riconnettiti e controlla le impostazioni effettivamente ricevute dal client.

Aggiungi gli elenchi di blocco in modo da poter individuare e risolvere i problemi

Il creator importa poi altri elenchi di blocco e mostra l’aumento del totale dei domini bloccati. Quel numero descrive il database delle policy, non la qualità dell’esperienza di navigazione. Un elenco più ampio può includere più domini indesiderati, ma può anche interferire con le procedure di accesso, i lettori multimediali o altre funzioni che dipendono da un servizio condiviso.

Aggiungi un elenco aggiornato alla volta, aggiorna il database di filtraggio e riprova i servizi che usi davvero. Se qualcosa smette di funzionare, usa il log delle query per individuare il nome interessato e prova una voce di lista consentita circoscritta. La documentazione del database dei domini di Pi-hole spiega come interagiscono le voci di autorizzazione e blocco. Evita di risolvere un singolo problema di accesso autorizzando in modo troppo ampio una raccolta di domini non correlati.

Conserva la motivazione di un nuovo elenco o di un’eccezione insieme alla modifica. Una policy sensata dovrebbe resistere a una settimana di utilizzo normale, non solo a un singolo screenshot riuscito. Se gestisci il filtro per altre persone, dai loro un modo per descrivere un servizio che non funziona e indicare l’ora approssimativa in cui si è verificato il problema. È più utile di una segnalazione generica come «internet non funziona».

Usa Tailscale per raggiungere lo stesso filtro anche fuori casa

Nella seconda parte, Tailscale viene aggiunto al server e a un telefono. Nelle impostazioni DNS del tailnet, The Social Dork inserisce l’indirizzo Tailscale del server come nameserver, poi collega il telefono e controlla di nuovo l’attività di Pi-hole. L’endpoint DNS resta a casa, mentre il telefono autorizzato può raggiungerlo tramite la rete privata.

La guida ufficiale all’integrazione di Pi-hole di Tailscale fornisce i dettagli aggiornati per la configurazione. Verifica che Pi-hole accetti le richieste provenienti dall’interfaccia privata prevista e che i criteri di accesso del tailnet consentano il traffico DNS. Se vuoi che i client supportati preferiscano il nameserver configurato per il tailnet, consulta il comportamento dell’override DNS di Tailscale e verifica l’impostazione sul client effettivo.

Usare un resolver DNS domestico tramite Tailscale non inoltra automaticamente tutto il traffico web attraverso la connessione di casa. L’uscita completa su Internet tramite un nodo di uscita domestico richiede una configurazione separata. Per questo progetto serve solo un percorso privato verso il servizio DNS; non è necessario esporre su Internet un resolver DNS pubblico o la relativa pagina di amministrazione.

Verifica il percorso DNS privato per fasi

1. Verifica che il server e il telefono siano registrati nel tailnet previsto e possano comunicare tra loro.
2. Aggiungi l’endpoint Pi-hole raggiungibile come nameserver previsto del tailnet.
3. Controlla l’uso del DNS Tailscale da parte del client e l’impostazione di override del nameserver, in base al comportamento desiderato.
4. Verifica che il listener e i criteri di accesso di Pi-hole accettino richieste DNS provenienti da quel percorso privato.
5. Disconnetti il Wi-Fi di casa e ripeti dal telefono una ricerca consentita e una bloccata.

Un listener configurato per accettare richieste solo da una specifica rete locale può spiegare perché i dispositivi di casa funzionano mentre un client Tailscale no. Il riferimento alla configurazione del listener DNS di Pi-hole descrive le modalità disponibili. Scegli una modalità compatibile con il tuo container e la tua rete privata, limitando al contempo l’accesso in entrata ai client previsti. Configurazioni del listener più ampie richiedono un limite altrettanto chiaro imposto dal firewall.

Distingui anche le impostazioni DNS dall'uscita verso Internet. Un nameserver può filtrare le query senza fungere da nodo di uscita. Se attivi separatamente un nodo di uscita, controlla di nuovo il comportamento DNS: Tailscale documenta questa interazione nel suo riferimento DNS e nameserver. Un test riuscito sulla rete Wi-Fi di casa non sostituisce la prova con lo stesso telefono sulla rete dati mobile.

Concentrati sul percorso nell'ultimo test, non solo sul contatore

Ripeti il test da una connessione diversa, per esempio usando la rete dati mobile con il Wi-Fi disattivato. Verifica che una nuova query dal telefono compaia in Pi-hole, che un sito consentito si apra ancora e che il nome bloccato selezionato riceva una risposta di filtraggio. Un totale in aumento può includere richieste di altri dispositivi; usa il client pertinente e gli orari per collegare l'osservazione al tuo test.

Il prossimo passaggio della serie di questo creator è un firewall OPNsense con DNS Pi-hole per i client wireless. Per un esempio più ampio di organizzazione delle applicazioni e dell'accesso remoto, la configurazione modulare dell'homelab di kabuto mostra come questi servizi possano integrarsi in una configurazione fisica gestita. Inizia con un client funzionante, poi amplia la policy di filtraggio dopo aver verificato i percorsi locale e remoto. Torna alla dimostrazione di Pi-hole e Tailscale di The Social Dork per la sequenza originale.

Individua il primo livello che non funziona

Considera il servizio una risorsa da cui dipende la famiglia una volta che viene usato da altri dispositivi. Fai un backup della configurazione, conserva un insieme di fonti delle regole funzionante e prova gli aggiornamenti prima con un client. Dopo il riavvio dell’host, verifica di nuovo una query consentita e una bloccata. La ricomparsa dell’icona dell’app nel dashboard è solo l’inizio della verifica.

La documentazione sulla configurazione dei container di Pi-hole spiega le opzioni di persistenza e di rete. Conserva queste informazioni operative insieme alla configurazione che hai scelto, anziché affidarti allo screenshot dell’indirizzo di qualcun altro.

Domande frequenti

Pi-hole rimuove ogni annuncio di YouTube?

Il filtraggio DNS non può distinguere in modo affidabile i video desiderati dalla pubblicità quando condividono lo stesso hostname. Valuta questo progetto come un sistema di filtraggio dei domini e verifica le applicazioni che usi, senza aspettarti che elimini la pubblicità ovunque.

Tutti i dispositivi di casa devono avere Tailscale?

I dispositivi di casa possono usare un endpoint Pi-hole della LAN raggiungibile tramite le relative impostazioni DNS. In questo progetto, Tailscale fornisce la connessione privata ai dispositivi che devono usare lo stesso resolver quando sono fuori casa.

Per questa configurazione serve un nodo di uscita Tailscale?

Non solo per raggiungere il servizio DNS privato. Un nodo di uscita modifica il percorso del traffico internet ed è una configurazione separata, con un proprio comportamento DNS.

Perché la pagina di Pi-hole si apre mentre il DNS non funziona?

L’interfaccia web e il servizio DNS usano porte diverse e potrebbero avere mappature dei container o regole di accesso differenti. Esegui direttamente una query DNS all’indirizzo previsto e controlla la voce corrispondente nel log.

Perché un altro server DNS può aggirare il filtro?

I client non usano necessariamente un secondo nameserver configurato solo come soluzione di emergenza. Se il filtraggio uniforme è importante, verifica tutti i resolver annunciati e il comportamento effettivo del client.

Cosa devo salvare prima di aggiornare l’app?

Salva la configurazione funzionante dell’app, i percorsi dei dati persistenti, le fonti delle regole e le impostazioni del client usate per un test riuscito. Dopo l’aggiornamento, ripeti il test e verifica che le impostazioni siano state mantenute.

Conclusione

Il progetto di The Social Dork collega tre decisioni: dove eseguire il DNS, quali client lo usano e come un telefono autorizzato può raggiungerlo da un’altra rete. Una configurazione efficace rende queste decisioni visibili e verificabili. Le prove più solide sono una richiesta DNS del client corrispondente, la risposta prevista dalle regole e la normale navigazione che continua a funzionare.

Inizia con un client, passa al DHCP solo dopo aver verificato che il test locale sia riuscito e controlla Tailscale da una connessione davvero separata. Poi mantieni il filtro come servizio su cui fa affidamento la famiglia. Tieni disponibile il video su Pi-hole e Tailscale originale per seguire la sequenza del creator, insieme alla documentazione ufficiale aggiornata per le versioni installate.