Cómo The Social Dork crea un bloqueador de anuncios Pi-hole con ZimaBoard 2

Gracias a The Social Dork | Ciberseguridad por compartir un proyecto de Pi-hole y Tailscale que filtra solicitudes DNS en casa y desde un teléfono fuera de casa. ZimaBoard 2 ejecuta los servicios, Pi-hole comprueba los dominios solicitados y Tailscale proporciona una conexión privada con el servidor. Mira la guía original de YouTube para ver la demostración completa.

Ver antes de leer: Este video de ocho minutos es útil si quieres entender dónde encaja el filtrado de anuncios a nivel de red antes de cambiar la configuración DNS de tu hogar. El creador instala Pi-hole en ZimaOS, prueba un cliente Windows, añade listas de bloqueo y luego conecta un teléfono mediante Tailscale.

El resultado práctico es un servicio de filtrado DNS reutilizable. El creador muestra menos anuncios visibles en un sitio web de ejemplo y la actividad de consultas del teléfono remoto. Esas observaciones demuestran que la ruta de filtrado funciona en esa configuración; no prueban que se bloqueen todos los anuncios, rastreadores o conexiones maliciosas.

Entiende qué filtra Pi-hole antes de elegir el hardware

La explicación comienza con un sitio web que carga contenido de varios dominios. Pi-hole recibe las solicitudes DNS del cliente y comprueba los nombres solicitados según la política configurada. Los nombres permitidos pueden resolverse mediante un solucionador ascendente; los nombres bloqueados reciben una respuesta de bloqueo. El punto de control importante es la consulta DNS, antes de que el cliente intente recuperar contenido de ese dominio.

Ese alcance también marca el límite. Un filtro DNS no puede distinguir un anuncio del contenido deseado cuando ambos usan el mismo nombre de host. Los clientes que usan otro solucionador pueden eludir la ruta elegida. Considera el título del video, «bloquear todos los anuncios», como la motivación del proyecto, no como un resultado universal. El filtrado de contenido del navegador y el filtrado DNS funcionan en capas distintas y pueden complementarse.

Sigue una consulta a través del sistema antes de cambiar toda una red. Un cliente solicita un nombre de host; Pi-hole aplica su política; una solicitud permitida puede llegar al solucionador ascendente; la respuesta vuelve al cliente. La conexión web posterior es un flujo independiente. Esto explica por qué un contador de dominios bloqueados es una prueba útil de actividad DNS, pero no mide todas las conexiones que realiza una aplicación.

Asigna al servicio DNS un lugar estable en la red doméstica

The Social Dork usa ZimaBoard 2 e instala Pi-hole mediante la tienda de aplicaciones ZimaOS que aparece en el video. El creador también menciona que una laptop existente puede servir como host. En la práctica, se necesita una máquina que pueda permanecer disponible siempre que los clientes dependan de ella para usar DNS; la demostración no justifica comprar la opción con más memoria solo para filtrar.

Conecta el host, asigna al punto de conexión DNS una dirección estable o una reserva DHCP y confirma que se pueda acceder al servicio desde un cliente de prueba. La red del contenedor y las asignaciones de puertos determinan qué dirección deben usar los clientes. Comprueba que tu instalación responda realmente a las consultas DNS en ese punto de conexión, en lugar de suponer que una página de administración accesible significa que el servicio DNS está listo.

Anota las direcciones antes de cambiar un cliente

En una instalación en contenedor, comprueba que se pueda acceder al servicio DNS tanto por TCP como por UDP. El ejemplo oficial de Docker de Pi-hole expone ambos protocolos en el puerto 53 y conserva su directorio de configuración. Esos detalles importan incluso cuando una tienda de aplicaciones oculta la configuración del contenedor tras un botón de instalación. Lee la configuración real de la aplicación antes de cambiar un servicio del host que quizá ya esté usando el mismo puerto.

El video muestra la instalación desde la tienda de aplicaciones ZimaOS del creador. La versión actual de la aplicación y el modo de red pueden ser diferentes. Conserva los ajustes que explican cómo la aplicación se conecta a la red: su dirección, los puertos publicados, la ubicación del almacenamiento, el resolver ascendente y el comportamiento al reiniciarse. Ese pequeño registro facilita verificar una migración o reinstalación posterior.

Prueba con un cliente antes de cambiar el DNS de toda la casa

En el tutorial, un portátil con Windows permanece conectado al Wi-Fi de casa mientras se cambia su configuración de DNS de IPv4 a la dirección de Pi-hole. Después, el creador comprueba la actividad de consultas. Es una primera prueba manejable: si la navegación deja de funcionar, solo hay que restaurar la configuración de ese cliente, mientras el resto de la casa conserva la configuración que ya tenía.

Para ampliar la cobertura, la guía de configuración posterior a la instalación de Pi-hole explica cómo DHCP puede anunciar la dirección DNS de Pi-hole a los clientes. Renueva la concesión del cliente o vuelve a conectarte y comprueba qué servidor de resolución utiliza realmente. Revisa también el DNS de IPv6 y la configuración de DNS cifrado del navegador o del sistema operativo; cambiar un campo de IPv4 no demuestra que todas las consultas sigan esa ruta.

Un segundo servidor de resolución sin filtrar también puede impedir el resultado esperado. Los clientes podrían usar otro servidor configurado en vez de reservarlo estrictamente como alternativa de emergencia. Decide si priorizas la continuidad o un filtrado uniforme y prueba qué ocurre cuando el host de Pi-hole no está disponible. Conserva un registro de la configuración original para que sea fácil revertir cualquier experimento con DNS.

Usa una prueba local reproducible

1. Anota la configuración DNS actual del portátil y la dirección prevista de Pi-hole.
2. Envía explícitamente a Pi-hole una consulta permitida y luego busca la consulta correspondiente en su registro.
3. Prueba un dominio que aparezca en tu propia lista de bloqueo activa y confirma que se bloquea.
4. Configura Pi-hole como servidor DNS preferido habitual del cliente y repite la prueba sin seleccionar explícitamente un servidor de resolución.
5. Prueba algunos servicios habituales, incluido un proceso de inicio de sesión, antes de aplicar el cambio mediante DHCP.

Por ejemplo, nslookup example.com PIHOLE_LAN_IP prueba un servidor de resolución específico; sustituye PIHOLE_LAN_IP por la dirección de tu servidor. Esa consulta explícita comprueba el propio servidor. A continuación, nslookup example.com comprueba la ruta habitual del sistema para las consultas DNS. Ninguna de las dos pruebas demuestra por sí sola que un navegador con su propia configuración de DNS siga la misma ruta, así que revisa también una solicitud nueva desde esa aplicación.

Al investigar un fallo, separa la accesibilidad de las direcciones de la resolución de nombres. Un dispositivo puede seguir conectado al Wi-Fi y, aun así, no poder abrir sitios porque su servidor DNS está desconectado. Conserva la configuración original del cliente hasta que el nuevo servidor de resolución funcione de forma constante. Después de cambiar DHCP, renueva la concesión o vuelve a conectarte y revisa la configuración que recibió realmente el cliente.

Añade listas de bloqueo de forma que puedas solucionar problemas

A continuación, el creador importa listas de bloqueo adicionales y muestra cómo aumenta el total de dominios bloqueados. Esa cifra describe la base de datos de políticas, no la calidad de la experiencia de navegación. Una lista más extensa puede incluir más dominios no deseados, pero también puede interferir con los flujos de inicio de sesión, los reproductores multimedia u otras funciones que dependen de un servicio compartido.

Añade una lista mantenida cada vez, actualiza la base de datos de filtrado y vuelve a probar los servicios que realmente usas. Cuando algo deje de funcionar, identifica el nombre afectado en el registro de consultas y prueba una entrada de lista de permitidos con un alcance limitado. La documentación de la base de datos de dominios de Pi-hole explica cómo interactúan las entradas de permitidos y bloqueados. Evita solucionar un único problema de inicio de sesión permitiendo de forma general una colección de dominios no relacionada.

Conserva el motivo de cada lista nueva o excepción junto con el cambio. Una política sensata debería funcionar durante una semana de uso normal, no solo para una captura de pantalla en la que todo haya salido bien. Si mantienes el filtro para otras personas, dales una forma de describir un servicio que no funciona y la hora aproximada en que falló. Eso permite actuar mejor que un informe general como «no hay internet».

Usa Tailscale para acceder al mismo filtro fuera de casa

En la segunda mitad se añade Tailscale al servidor y a un teléfono. En la configuración de DNS de la red tailnet, The Social Dork introduce la dirección de Tailscale del servidor como servidor de nombres, luego conecta el teléfono y vuelve a comprobar la actividad de Pi-hole. El endpoint DNS permanece en casa, mientras que el teléfono autorizado puede acceder a él a través de la red privada.

La guía oficial de integración de Pi-hole de Tailscale incluye los detalles de configuración actuales. Confirma que Pi-hole acepte las consultas que llegan por la interfaz privada prevista y que la política de acceso de la red tailnet permita el tráfico DNS. Si quieres que los clientes compatibles prefieran el servidor de nombres configurado para la red tailnet, consulta el comportamiento de anulación de DNS de Tailscale y verifica la opción en el propio cliente.

Usar un resolvedor DNS doméstico a través de Tailscale no envía automáticamente todo el tráfico web a través de la conexión de casa. El tráfico de salida completo a Internet a través de un nodo de salida doméstico requiere una configuración aparte. Este proyecto solo necesita una ruta privada al servicio DNS; no requiere exponer a Internet un resolvedor DNS público ni su página de administración.

Valida por etapas la ruta DNS privada

1. Confirma que el servidor y el teléfono estén inscritos en la red tailnet prevista y puedan comunicarse.
2. Añade el endpoint de Pi-hole accesible como servidor de nombres previsto de la red tailnet.
3. Revisa el uso de Tailscale DNS en el cliente y la opción de anulación del servidor de nombres para obtener el comportamiento deseado.
4. Comprueba que el receptor de Pi-hole y la política de acceso acepten consultas DNS desde esa ruta privada.
5. Desconecta el Wi-Fi de casa y repite desde el teléfono una consulta permitida y otra bloqueada.

Un receptor configurado para aceptar conexiones solo desde una red local específica puede explicar por qué funcionan los clientes de casa, pero falla un cliente de Tailscale. La referencia de configuración del receptor DNS de Pi-hole describe los modos disponibles. Elige un modo compatible con tu contenedor y tu red privada, y limita el acceso entrante a los clientes previstos. Una configuración de receptor amplia requiere un límite de firewall igual de claro.

Distingue también la configuración de DNS de la salida a Internet. Un servidor de nombres puede filtrar consultas sin convertirse en un nodo de salida. Si habilitas por separado un nodo de salida, vuelve a comprobar el comportamiento de DNS; Tailscale documenta esa interacción en su referencia de DNS y servidores de nombres. Una prueba satisfactoria con el Wi-Fi de casa no sustituye a probar el mismo teléfono con datos móviles.

Haz que la prueba final se centre en la ruta, no solo en un contador

Repite la prueba desde una conexión distinta, como los datos móviles con el Wi-Fi desactivado. Comprueba que aparezca en Pi-hole una nueva consulta desde el teléfono, que siga abriéndose un sitio permitido y que el nombre bloqueado seleccionado reciba una respuesta de filtrado. Un total creciente puede incluir solicitudes de otros dispositivos; usa el cliente pertinente y las marcas de tiempo para relacionar lo observado con tu prueba.

El siguiente paso de la serie de este creador es un cortafuegos OPNsense con DNS de Pi-hole para clientes inalámbricos. Como ejemplo más amplio de cómo organizar aplicaciones y el acceso remoto, el montaje modular de homelab de kabuto muestra cómo pueden integrarse esos servicios en una instalación física bien mantenida. Empieza con un cliente que funcione y, después, amplía la política de filtrado cuando hayas verificado las rutas locales y remotas. Vuelve a la demostración de Pi-hole y Tailscale de The Social Dork para consultar la secuencia original.

Soluciona los problemas de la primera capa que falla

Considera el servicio una dependencia del hogar cuando otros dispositivos empiecen a usarlo. Haz una copia de seguridad de su configuración, conserva un conjunto funcional de fuentes de políticas y prueba las actualizaciones primero con un solo cliente. Tras reiniciar el host, vuelve a comprobar una consulta permitida y otra denegada. Que el icono de la aplicación vuelva a aparecer en el panel es solo el primer paso de la verificación.

La documentación de configuración de contenedores de Pi-hole explica las opciones de persistencia y redes. Guarda ese registro operativo junto con la configuración que hayas elegido, en lugar de depender de una captura de pantalla con la dirección de otra persona.

Preguntas frecuentes

¿Pi-hole eliminará todos los anuncios de YouTube?

El filtrado DNS no puede separar de forma fiable los videos deseados de la publicidad cuando comparten un nombre de host. Considera este proyecto como un filtro por dominio y verifica las aplicaciones que uses en concreto, en lugar de prometer una experiencia sin anuncios en todas partes.

¿Todos los dispositivos del hogar necesitan Tailscale?

Los dispositivos del hogar pueden usar un punto de acceso LAN de Pi-hole mediante sus ajustes de DNS. En este proyecto, Tailscale proporciona la conexión privada para que los dispositivos que están fuera de casa puedan usar el mismo resolutor.

¿Necesito un nodo de salida de Tailscale para esta configuración?

No solo para acceder al servicio DNS privado. Un nodo de salida cambia la ruta del tráfico de Internet y requiere una configuración aparte, con su propio comportamiento de DNS.

¿Por qué se abre la página de Pi-hole, pero falla el DNS?

La interfaz web y el servicio DNS usan puertos distintos y pueden tener asignaciones de puertos o reglas de acceso diferentes en el contenedor. Prueba directamente una consulta DNS a la dirección prevista y comprueba la entrada correspondiente en el registro.

¿Por qué otro servidor DNS puede eludir el filtro?

Los clientes no necesariamente tratan un segundo servidor de nombres configurado como una alternativa de emergencia. Si es importante que el filtrado sea uniforme, verifica todos los resolutores anunciados y el comportamiento real del cliente.

¿Qué debo guardar antes de actualizar la aplicación?

Guarda la configuración funcional de la aplicación, las ubicaciones de los datos persistentes, las fuentes de políticas y los ajustes del cliente usados en una prueba que haya funcionado correctamente. Después de la actualización, repite la prueba y confirma que los ajustes se hayan conservado.

Conclusión

El proyecto de The Social Dork conecta tres decisiones: dónde se ejecuta el DNS, qué clientes lo usan y cómo llega a él un teléfono autorizado desde otra red. Una implementación útil hace que esas decisiones sean visibles y comprobables. La mejor evidencia es una consulta coincidente en el registro del cliente, la respuesta de política esperada y una navegación normal que siga funcionando.

Empieza con un cliente, amplía la configuración a DHCP después de que la prueba local salga bien y valida Tailscale desde una conexión realmente independiente. Luego, mantén el filtro como un servicio del que dependa el hogar. Conserva el vídeo de Pi-hole y Tailscale original para seguir la secuencia del creador, junto con la documentación oficial vigente para las versiones que tengas instaladas.