El manual definitivo para navegar 100% seguro con WireGuard, Pi-hole y Unbound.

Este es el último manual de una lista que debes poner en marcha en el siguiente orden.

1. WireGuard en Raspberry PI, VPN casera, segura y gratuita.
2. Pi-hole en Raspberry Pi: Instalación paso a paso.
3. Configura tu propio servidor DNS recursivo con Pi-hole y Unbound
4. El manual definitivo para navegar 100% seguro con WireGuard, Pi-hole y Unbound.

Comenzamos.

Una vez hayas completado todos los manuales anteriores, como vimos en WireGuard en Raspberry PI, VPN casera, segura y gratuita. no deberías usar las DNS de Google (8.8.8.8) que se detallaban en el apartado «6.2. Crear los archivos de configuración de cada cliente«.

Porque tu cliente de WireGuard en el móvil tiene grabada a fuego la directiva DNS = 8.8.8.8 en su perfil actual. Al levantar el túnel, el sistema operativo de tu móvil le hace caso a esa línea y envía las consultas DNS a Google a través del túnel.

El objetivo principal de montar tu propia infraestructura es mantener la privacidad y, de paso, aprovechar el bloqueo de publicidad y rastreadores de Pi-hole incluso cuando estás fuera de casa. Para lograrlo, la dirección IP que debes poner en el apartado DNS de las configuraciones de los clientes varía según cómo quieras resolver las peticiones dentro del túnel:

La prueba de dnsleaktest

Cuando estás conectado a la VPN con el DNS de Google (8.8.8.8), las páginas de test verán que tus peticiones vienen de los servidores de Google. Si usas tu servidor recursivo, verán la IP pública de tu casa (la de tu proveedor de internet).

1. Conéctate a la VPN desde fuera de casa (o quita el WiFi y usa datos móviles).
2. Entra en la página web: dnsleaktest.com
3. Verás tu IP pública actual. Haz clic en el botón «Standard test».
4. Analiza el resultado:
   • Si sale Google (generalmente con banderas de tu país, o donde esté el servidor más cercano) o ves IPs que no te pertenecen: Sigues usando el DNS de Google configurado en la interfaz.
   • Si sale únicamente tu proveedor de internet (Movistar, Digi, Orange, etc.) con la IP de tu casa: Significa que tu petición ha viajado por la VPN hasta tu Raspberry Pi, y de ahí Unbound ha salido a internet a resolverla. El sistema recursivo está funcionando.

La captura del test muestra claramente que las peticiones se están resolviendo a través de servidores pertenecientes a Google en Madrid. Esto significa que, aunque el resto de tu tráfico (la navegación general) sí vaya cifrado por la VPN, las preguntas de «¿a qué IP pertenece esta web?» se le siguen enviando directamente a Google en el formato tradicional, saltándose por completo tu Raspberry Pi con Pi-hole y Unbound.

Cómo solucionar el problema en 3 pasos:

Para solucionarlo y hacer que tu servidor recursivo tome el control total, tienes que actualizar la configuración del cliente.

Paso 1. Modifica el archivo en la Raspberry Pi: Ve a la ruta donde guardas los perfiles de los clientes:

sudo nano /etc/wireguard/clients/phone_dad.conf

y edita el archivo cambiando la línea del DNS = 8.8.8.8 por:

[Interface]
PrivateKey = [clave privadaa]
Address = 10.0.0.2/32
DNS = 10.0.0.1

[Peer]
PublicKey = [clave_publica]
Endpoint = linuxete.duckdns.org:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Paso 2. Asegura el cambio en Pi-hole: Confirma que aplicaste el cambio a «Permit all origins» en la pestaña DNS de Pi-hole (y dale a Save & Apply si no lo hiciste antes) para que acepte las consultas que le lleguen desde la interfaz de WireGuard.

Paso 3. Actualiza el perfil en tu móvil:

En la terminal de la Pi, vuelve a generar el código QR con el archivo modificado:

sudo cat /etc/wireguard/clients/phone_dad.conf | qrencode -t ansiutf8

Escanea el nuevo QR desde la app de WireGuard en el móvil.

Una vez hecho esto, activa la VPN con tus datos móviles y vuelve a pasar el dnsleaktest.com. Si todo está en orden, los 6 servidores de Google deberían desaparecer y, en su lugar, debería figurar únicamente tu proveedor de internet local de casa.

Ahora cuando mi móvil solicita resolver un dominio desde la red móvil (o cualquier WiFi pública), la consulta viaja encriptada por el túnel de Wireguard directo a mi Raspberry Pi. Pi-hole la procesa y se la pasa a Unbound.

Como Unbound es un servidor DNS recursivo propio, no le pregunta a ninguna entidad comercial (ni a Google, ni a Cloudflare, ni a tu operador), sino que sale directamente a los Root Servers de internet usando tu propia conexión física de casa. Por eso de cara al test, el encargado de resolver la petición es, a todos los efectos, tu IP pública fija.

Hemos conseguido el combo ideal: Privacidad absoluta (DNS recursivo sin intermediarios), bloqueo de publicidad en movilidad (Pi-hole) y conexión segura (WireGuard). ¡Objetivo cumplido!

¡Hazlo desde la terminal!

Puede ser que no dispongas de un entorno gráfico o un navegador a mano para ir a dnsleaktest.com, pero si tienes una terminal, ¡tienes un tesoro!

Para comprobar qué DNS estás utilizando, abre tu consola y lanza un nslookup apuntando a cualquier dominio:

nslookup google.com

Fíjate bien en la primera línea de la respuesta, ya que te indicará qué servidor ha resuelto la petición:

• Si muestra Server: 8.8.8.8, estás saliendo a través de los DNS de Google.
• Si muestra Server: 127.0.0.1 (o la IP local de tu servidor), ¡enhorabuena! Estás usando con éxito tu propio combo de Pi-hole + Unbound.

Si quieres forzar la consulta directamente contra tu servidor para probarlo, puedes añadir su IP al final del comando:

~ $ nslookup google.com 10.0.0.1
Server:		10.0.0.1
Address:	10.0.0.1#53

Non-authoritative answer:
Name:	google.com
Address: 216.58.205.110

El «Efecto Termux»: ¿Por qué no siempre coincide en Android?

Si estás haciendo esta prueba desde un teléfono Android, debes tener en cuenta un detalle importante sobre cómo interactúan las aplicaciones con la red:

1. La app oficial de WireGuard: Intercepta el tráfico a nivel de VpnService (la capa de red del sistema). Cuando usas el navegador web del móvil, la API de la VPN secuestra esa solicitud DNS y la fuerza a ir por el túnel hacia la IP de tu Pi-hole.
2. El caso de Termux: Las herramientas de consola dentro de entornos emulados como Termux a veces se saltan las rutas DNS modificadas por las APIs de la VPN de Android. Debido a esto, pueden saltarse el túnel y exponer los servidores DNS del sistema base (los de tus datos móviles o la red WiFi).

💡 En resumen: Si estás en una terminal nativa de Linux, un simple nslookup google.com bastará. Si estás en Termux dentro de Android y quieres asegurarte de que el túnel responde, fuerza la consulta especificando la IP interna de tu servidor: nslookup google.com 10.0.0.1.