Cómo corregir DNS sobre WireGuard: 3 fallos comunes

Por qué DNS falla en cuanto se activa el túnel de WireGuard

DNS sobre WireGuard falla de tres formas, y cada una tiene su propia solución. No se resuelve ningún nombre, o los nombres se resuelven pero las consultas salen del equipo fuera del túnel, o el propio gestor de resolución del cliente sobrescribe la configuración unos segundos después de iniciar la interfaz. Casi nunca el problema es el túnel. El problema es la línea que indica al cliente qué resolvedor debe consultar y el enrutamiento que determina cómo viajan los paquetes hasta ese resolvedor.

WireGuard transporta paquetes IP y no conoce DNS (sistema de nombres de dominio, el servicio que convierte nombres como example.com en direcciones IP). La línea DNS = de un bloque de cliente [Interface] no es una configuración de WireGuard. La lee wg-quick, el envoltorio de shell que activa la interfaz, y wg-quick modifica la configuración del resolvedor del cliente mientras el túnel está activo y la restaura al ejecutar wg-quick down. Por tanto, todos los problemas siguientes son problemas de enrutamiento o de wg-quick, nunca problemas de criptografía. Si todavía no ha creado el túnel, empiece por una VPN WireGuard autohospedada en su propio VPS y vuelva después a esta página.

Confirme que el túnel funciona correctamente antes de modificar DNS.

sudo wg show
ping -c 3 10.8.0.1
ping -c 3 1.1.1.1

wg show debería mostrar el peer con un latest handshake reciente, y ambos pings deberían responder. Si ping 1.1.1.1 agota el tiempo de espera, tiene un problema de reenvío o NAT (traducción de direcciones de red), no un problema de DNS, y ninguna modificación de la configuración del resolvedor lo solucionará. Todos los ejemplos usan 10.8.0.0/24 como subred del túnel y 10.8.0.1 como dirección del servidor en el túnel. Sustitúyalos por sus propios valores.

Error uno: no se resuelve nada porque el resolvedor nunca responde

El síntoma es preciso. ping 1.1.1.1 funciona y curl https://example.com devuelve lo siguiente:

curl: (6) Could not resolve host: example.com

Consulte directamente el resolvedor del túnel desde el cliente. dig pertenece al paquete dnsutils en Ubuntu y Debian.

dig +short @1.1.1.1 example.com
dig +short @10.8.0.1 example.com

El primer comando devuelve una dirección, lo que demuestra que los paquetes llegan a Internet a través del túnel. El segundo no devuelve nada y muestra ;; communication timed out; no servers could be reached. El diagnóstico es completo: el cliente apunta a 10.8.0.1 y 10.8.0.1 no responde en el puerto UDP 53.

Hay dos causas posibles. Puede que no se esté ejecutando ningún resolvedor en el servidor o que el firewall del servidor descarte la consulta antes de que llegue. Compruebe ambas en el servidor.

sudo ss -ulnp | grep ':53'
sudo nft list ruleset

Un resolvedor que se está ejecutando y está enlazado correctamente muestra una línea con 10.8.0.1:53 o 0.0.0.0:53. En Ubuntu, la causa inesperada suele ser 127.0.0.53:53: es el listener auxiliar de systemd-resolved, que enlaza una dirección de loopback y no es accesible deliberadamente desde otras máquinas. Si un cliente VPN apunta a un servidor cuyo único resolvedor es ese listener auxiliar, se produce exactamente este tiempo de espera.

La solución es un resolvedor que escuche en la dirección del túnel y una regla de firewall que permita a los pares acceder a él.

sudo apt update && sudo apt install -y unbound
printf 'server:\n  interface: 10.8.0.1\n  access-control: 10.8.0.0/24 allow\n' \
  | sudo tee /etc/unbound/unbound.conf.d/wireguard.conf
sudo systemctl restart unbound
sudo ss -ulnp | grep '10.8.0.1:53'

A continuación, abra el puerto únicamente para el tráfico del túnel. Con nftables, añada estas dos líneas a la cadena input en /etc/nftables.conf y recargue la configuración con sudo systemctl reload nftables.

udp dport 53 iifname "wg0" accept
tcp dport 53 iifname "wg0" accept

Con ufw, sudo ufw allow in on wg0 to any port 53 realiza la misma función. Nunca abra el puerto 53 a Internet público. Los escáneres encuentran un resolvedor recursivo abierto en cuestión de días y lo utilizan para amplificar ataques de denegación de servicio. Su proveedor detectará ese tráfico antes que usted.

Vuelva a ejecutar dig +short @10.8.0.1 example.com desde el cliente. Una dirección en la salida indica que la ruta del resolvedor funciona, por lo que el cliente solo tiene que utilizarla. Añada la línea al bloque [Interface] del cliente y reinicie la interfaz con sudo wg-quick down wg0 && sudo wg-quick up wg0.

[Interface]
PrivateKey = <client private key>
Address = 10.8.0.2/32
DNS = 10.8.0.1

Error dos: fugas de DNS porque un túnel dividido no enruta el resolvedor

Este caso es peor porque todo parece funcionar. Los nombres se resuelven, las páginas cargan y las consultas atraviesan en texto claro la red local en la que no quería confiar.

Dos configuraciones lo provocan. La primera es un cliente con AllowedIPs = 0.0.0.0/0, ::/0 y sin una línea DNS =. wg-quick instala la ruta predeterminada en su propia tabla de enrutamiento y añade una regla con suppress_prefixlength 0. Esto mantiene activas deliberadamente las rutas locales más específicas para que la máquina pueda seguir accediendo a su impresora. El resolvedor que el cliente obtuvo mediante DHCP, normalmente el router en 192.168.1.1, coincide con una de esas rutas locales. El tráfico atraviesa el túnel. La red local sigue recibiendo la lista completa de nombres que consulta.

La segunda es un túnel dividido: AllowedIPs = 10.8.0.0/24 con DNS = 9.9.9.9. Como 9.9.9.9 no está dentro de AllowedIPs, el cliente no tiene una ruta hacia él a través del túnel. Por tanto, la consulta sale por el enlace local, exactamente igual que en el primer caso.

Compruebe qué resolvedor responde realmente. whoami.akamai.net es un nombre de prueba público que responde con la dirección IP del resolvedor recursivo que realizó la consulta. Así puede comparar su respuesta con la dirección pública de su servidor.

resolvectl status
dig +short whoami.akamai.net
sudo tcpdump -ni any -c 10 port 53

resolvectl status imprime un bloque por enlace. Si el bloque del enlace Ethernet o inalámbrico todavía muestra Current DNS Server: 192.168.1.1, mientras que el bloque wg0 no muestra ninguno, existe una fuga. Si dig +short whoami.akamai.net devuelve la dirección de su conexión de banda ancha doméstica en lugar de la dirección de su servidor, queda confirmado desde el extremo remoto. La línea tcpdump es la prueba definitiva: una salida correcta coloca todos los paquetes del puerto 53 en wg0, mientras que una fuga los coloca en wlan0 o enp3s0.

La corrección tiene dos partes y ambas son necesarias. Establezca DNS en una dirección que esté dentro del túnel y asegúrese de que esa dirección esté dentro de AllowedIPs.

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.8.0.0/24, 10.20.0.0/16

10.8.0.1 está dentro de 10.8.0.0/24, por lo que la consulta se cifra y se envía al servidor. Si insiste en usar un resolvedor público con un túnel dividido, añádalo como una ruta de host: AllowedIPs = 10.8.0.0/24, 9.9.9.9/32. Los paquetes se envían entonces por el túnel, aunque la red local todavía puede ver que eligió ese proveedor a partir de sesiones anteriores. Un resolvedor administrado por usted evita este problema.

La asignación del resolvedor es una de las diferencias visibles entre WireGuard configurado manualmente y una malla coordinada. Forma parte del compromiso descrito en WireGuard comparado con Tailscale. Ejecutar un servidor de control Headscale autohospedado proporciona esa coordinación sin entregar el material de sus claves a un tercero.

Fallo tres: resolvconf y systemd-resolved entran en conflicto en clientes Linux

Los clientes macOS, Windows, iOS y Android aplican DNS = mediante la aplicación oficial y suelen causar pocos problemas. En Linux, el ajuste se aplica mediante un script de shell que debe determinar cuál de varios gestores de resolución utiliza el sistema.

El primer fallo es evidente. sudo wg-quick up wg0 se detiene con:

resolvconf: command not found

wg-quick llama a resolvconf, pero ese binario no está instalado. Instala la implementación que se comunica con systemd-resolved y vuelve a activar la interfaz.

sudo apt install -y openresolv
sudo systemctl restart systemd-resolved
sudo wg-quick down wg0 && sudo wg-quick up wg0
resolvectl status wg0

El segundo fallo es silencioso y es el que puede hacerte perder una tarde. La interfaz se activa, resolvectl status wg0 muestra correctamente DNS Servers: 10.8.0.1 y las consultas siguen dirigiéndose al resolvedor anterior. systemd-resolved mantiene una lista de resolvedores independiente para cada enlace y selecciona un enlace para cada consulta. Si ningún enlace está marcado como ruta predeterminada para nombres, sigue utilizando el resolvedor del enlace inalámbrico, porque ese enlace tiene un dominio de búsqueda y el tuyo no.

Configura el resolvedor y reclama la ruta predeterminada en el mismo paso. %i se sustituye por el nombre de la interfaz, por lo que este bloque funciona sin cambios en cualquier interfaz.

[Interface]
Address = 10.8.0.2/32
PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~.
PostDown = resolvectl revert %i

Elimina la línea DNS = cuando utilices PostUp de esta forma, porque, de lo contrario, dos mecanismos escriben el estado del resolvedor y solo uno de ellos lo limpia después. El argumento ~. es la parte importante: marca wg0 como dominio de enrutamiento para todos los nombres, de modo que systemd-resolved envía allí todas las consultas en lugar de elegir un enlace para cada consulta. Verifícalo.

resolvectl status wg0

La salida correcta contiene DNS Servers: 10.8.0.1 y Default Route: yes. Si Default Route muestra no, la parte resolvectl domain no se ejecutó y el sistema vuelve a seleccionar enlaces.

Conviene mencionar otro caso. Si /etc/resolv.conf es un archivo real en lugar de un enlace simbólico a /run/systemd/resolve/stub-resolv.conf, otro componente lo administra, normalmente NetworkManager o un entorno de ejecución de contenedores. Ejecuta ls -l /etc/resolv.conf antes de depurar cualquier otra cosa, porque una herramienta que reescriba ese archivo con cada cambio de red deshará tu trabajo en el momento menos conveniente.

La actualización: tu propio resolver con filtrado a través del túnel

Cuando las consultas viajan de forma fiable por el túnel, el resolver del otro extremo se convierte en un punto de control. Ejecutar AdGuard Home allí proporciona filtrado mediante listas de bloqueo y un registro de consultas a todos los dispositivos conectados, sin software cliente ni configuración individual por dispositivo. El script de instalación oficial, comprobado en julio de 2026, ocupa una sola línea.

curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v

El asistente de configuración escucha en el puerto 3000 durante la primera ejecución. Accede a él a través del túnel en http://10.8.0.1:3000 en lugar de abrir ese puerto públicamente y, en el asistente, establece tanto la dirección de escucha DNS como la dirección de escucha administrativa en 10.8.0.1. Si unbound del primer fallo todavía usa la misma dirección, detenlo primero con sudo systemctl disable --now unbound, porque dos procesos no pueden asociar el puerto UDP 53 a una misma dirección y el segundo proceso termina con listen udp 10.8.0.1:53: bind: address already in use.

Las configuraciones de los clientes no necesitan cambios si ya indican DNS = 10.8.0.1. El registro de consultas mostrará ahora cada consulta de todos los pares, lo que constituye una decisión real de privacidad y no una ventaja gratuita: transfieres la confianza de tu proveedor de Internet a ti mismo y eres responsable de mantener actualizado ese servidor. Un servidor expuesto a Internet necesita tener primero los aspectos básicos configurados, y los primeros diez minutos en un VPS nuevo los cubren.

FAQ

¿Por qué mi túnel WireGuard se conecta, pero los nombres no se resuelven?

El túnel transporta paquetes y no gestiona nombres. Por tanto, si el túnel funciona pero las búsquedas fallan, el resolvedor configurado no responde. Prueba con dig +short @10.8.0.1 example.com desde el cliente. Una respuesta communication timed out significa que no hay ningún resolvedor escuchando en esa dirección del túnel, normalmente porque el stub de systemd-resolved solo está enlazado a 127.0.0.53, o que el firewall del servidor está descartando el puerto UDP 53 recibido en wg0. Corrige primero el servicio que escucha y después abre el puerto únicamente para wg0.

¿Cómo compruebo si mi DNS se filtra a través de WireGuard?

Ejecuta sudo tcpdump -ni any -c 10 port 53 en el cliente y supervisa la columna de interfaz mientras navegas. Todos los paquetes deberían usar wg0. Si aparecen en la interfaz inalámbrica o ethernet, las consultas están saliendo en texto claro. dig +short whoami.akamai.net proporciona una segunda comprobación, porque responde con la dirección pública del resolvedor recursivo que realizó la consulta. Por tanto, una respuesta que no contenga la dirección de tu servidor confirma la fuga.

¿Necesito la línea DNS = si uso un túnel dividido?

Sí. La dirección del resolvedor también debe estar dentro de AllowedIPs; de lo contrario, el cliente no tiene una ruta hacia ella. Con AllowedIPs = 10.8.0.0/24, un resolvedor en 10.8.0.1 queda incluido y la consulta se cifra. Un resolvedor público como 9.9.9.9 no queda incluido. Por tanto, la consulta sale por el enlace local aunque la línea DNS parezca correcta.

¿Por qué resolvectl muestra el servidor correcto, pero las búsquedas siguen usando otro?

systemd-resolved mantiene una lista de resolvedores por cada enlace y elige un enlace para cada consulta. Por eso, una entrada correcta en wg0 se ignora mientras otro enlace tenga la ruta predeterminada para los nombres. Añade PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~. al bloque [Interface] del cliente y elimina la línea DNS =. Después, resolvectl status wg0 debería mostrar Default Route: yes.

¿Qué cliente debo corregir primero cuando hay varios problemas?

Corrige primero un cliente Linux, porque es la única plataforma que muestra el mecanismo. resolvectl status y tcpdump indican qué resolvedor respondió y qué interfaz transportó el paquete. Las aplicaciones del teléfono y del escritorio aplican los mismos valores DNS y AllowedIPs sin mostrar los componentes internos. Cuando el cliente Linux funcione correctamente, solo tendrás que copiar una configuración que ya has verificado.