Cómo solucionar DNS en 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 sin pasar por el túnel, o el propio gestor de resolución del cliente sobrescribe la configuración unos segundos después de activar la interfaz. Casi nunca el problema está en 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 en wg-quick down. Por tanto, todos los problemas siguientes son problemas de enrutamiento o de wg-quick, nunca de criptografía. Si todavía no ha creado el túnel, empiece por una VPN WireGuard autoalojada en su propio VPS y vuelva después a esta página.

Confirme primero que el túnel funciona correctamente. No toque DNS todavía.

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, lo más probable es que tenga un problema de reenvío o NAT (traducción de direcciones de red), no un problema de DNS, y ninguna cantidad de cambios en la configuración del resolvedor lo solucionará. Un firewall que descarte ICMP produce el mismo tiempo de espera, así que confírmelo con curl -sI https://1.1.1.1 antes de cambiar las reglas de reenvío. Si los pings responden pero el rendimiento cae cuando empieza el tráfico real, se trata de un problema independiente, y la lentitud de WireGuard casi siempre se debe a MTU y no a nada de lo tratado en esta página. Todos los ejemplos usan 10.8.0.0/24 como subred del túnel y 10.8.0.1 como dirección del túnel del servidor. Sustitúyalos por sus propios valores.

Fallo uno: no se resuelve nada porque el resolver 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 resolver 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. Esto 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 haya ningún resolver en ejecución en el servidor o que el firewall del servidor descarte la consulta antes de que llegue. Compruebe ambas cosas en el servidor.

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

Un resolver que está en ejecución y enlazado correctamente muestra una línea con 10.8.0.1:53 o 0.0.0.0:53. En Ubuntu, lo habitual es encontrar 127.0.0.53:53: es el listener de tipo stub de systemd-resolved, que enlaza una dirección de loopback y no es accesible deliberadamente desde otros equipos. Si el cliente VPN apunta a un servidor cuyo único resolver es ese stub, se produce exactamente este timeout.

La solución consiste en usar un resolver que escuche en la dirección del túnel y añadir una regla de firewall que permita acceder a él a los peers.

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'

Después, abra el puerto sólo para el tráfico del túnel. Con nftables, añada estas dos líneas a la cadena input de /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. No abra nunca el puerto 53 a Internet. Los scanners encuentran un resolver recursivo abierto en pocos 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 hacia el resolver funciona. Por tanto, al cliente sólo le falta 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

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

Este problema 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.

Hay dos configuraciones que 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 a propósito 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 utiliza 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 muestra un bloque por cada 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. Que dig +short whoami.akamai.net devuelva la dirección de su conexión de banda ancha doméstica en lugar de la dirección de su servidor lo confirma desde el extremo remoto. La línea tcpdump proporciona la prueba definitiva: en una salida correcta, todos los paquetes destinados al puerto 53 que salen de la máquina utilizan wg0. En una salida con fugas, utilizan wlan0 o enp3s0. Los paquetes de lo hacia o desde 127.0.0.53 corresponden a aplicaciones que se comunican con el stub local de systemd-resolved y no constituyen una fuga.

La corrección tiene dos partes y ambas son necesarias. Configure DNS con una dirección que esté dentro del túnel y asegúrese de que esa dirección esté incluida en 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 necesita usar un resolvedor público en 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 enviarán por el túnel, aunque la red local todavía podrá ver que eligió ese proveedor a partir de sesiones anteriores. Un resolvedor administrado por usted evita esta cuestión.

La asignación del resolvedor es una de las diferencias visibles entre WireGuard configurado manualmente y una malla coordinada. Forma parte de la relación entre ventajas y limitaciones descrita en WireGuard comparado con Tailscale. Si ejecuta un servidor de control Headscale autohospedado, obtiene esa coordinación sin entregar el material de sus claves a un tercero. Si esa última cuestión es la que le preocupa, tenga en cuenta que Tailscale nunca posee las claves que cifran su tráfico. La pregunta más concreta es qué podría añadir a su red un servidor de coordinación comprometido o una cuenta de identidad robada.

El tercer fallo: 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 usa 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. En Debian 12 y Ubuntu 24.04 o posteriores, el comando resolvconf que se comunica con systemd-resolved se incluye en el paquete systemd-resolved. Instálelo y vuelva a activar la interfaz. Ubuntu 22.04 no tiene un paquete independiente para ese comando. En esa versión, cree manualmente el enlace de compatibilidad con sudo ln -s /usr/bin/resolvectl /usr/local/bin/resolvconf y omita la línea de instalación.

sudo apt install -y systemd-resolved
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 hacerle perder toda una tarde. La interfaz se activa, resolvectl status wg0 muestra correctamente DNS Servers: 10.8.0.1 y las consultas siguen llegando al resolver antiguo. systemd-resolved no ignora wg0. Un nombre que no coincide con ningún dominio de enrutamiento se envía a los servidores DNS de cada enlace que cuenta como ruta predeterminada. Un enlace con servidores DNS y sin un dominio exclusivo para rutas cuenta como ruta predeterminada de forma automática. Por tanto, la consulta se envía al mismo tiempo a 10.8.0.1 y al router del enlace inalámbrico, y gana la primera respuesta correcta. El router está a un salto y normalmente responde primero. En cualquier caso, la consulta ya ha salido sin cifrar. Los nombres del dominio de búsqueda propio del enlace inalámbrico, como lan, sólo se envían a ese enlace, porque gana el dominio de enrutamiento más específico.

Cuando wg-quick aplica DNS = mediante su propio contenedor resolvconf de systemd, ya solicita un dominio de enrutamiento general. Por eso, este fallo aparece sobre todo cuando otra implementación de resolvconf o un gestor de red aplica el ajuste. Establecerlo explícitamente elimina la ambigüedad.

Configure el resolver y reclame el dominio de enrutamiento general 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

Elimine la línea DNS = cuando use PostUp de esta forma. De lo contrario, dos mecanismos escribirán el estado del resolver y sólo uno lo limpiará después. El argumento ~. es la parte importante: convierte wg0 en el dominio exclusivo para rutas de todos los nombres. Así, systemd-resolved deja de enviar a los otros enlaces los nombres que no coincidan con un dominio más específico. Los nombres del dominio propio de otro enlace, como lan, siguen enviándose a ese enlace, que normalmente es lo que se desea para los hosts locales. Verifíquelo.

resolvectl status wg0

La salida correcta contiene DNS Servers: 10.8.0.1 y DNS Domain: ~.. Si falta ~., no se ejecutó la parte resolvectl domain y wg0 vuelve a competir con los otros enlaces. No use la marca de ruta predeterminada como comprobación: muestra yes (o +DefaultRoute en la línea Protocols, según la versión de systemd) incluso sin ~., porque un enlace sin un dominio exclusivo para rutas ya es una ruta predeterminada.

Conviene mencionar otro caso. Si /etc/resolv.conf es un archivo real y no un enlace simbólico a /run/systemd/resolve/stub-resolv.conf, otro componente es su propietario, normalmente NetworkManager o un runtime de contenedores. Ejecute ls -l /etc/resolv.conf antes de depurar cualquier otra cosa, porque una herramienta que reescriba ese archivo en cada cambio de red deshará su trabajo en el momento menos oportuno.

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

Cuando las consultas ya circulan de forma fiable por el túnel, el resolvedor del extremo remoto se convierte en un punto de control. Si ejecuta AdGuard Home allí, todos los dispositivos conectados obtienen filtrado mediante listas de bloqueo y un registro de consultas, sin instalar software en los clientes ni configurar cada dispositivo por separado. El script oficial de instalación, comprobado en octubre de 2026, consta de 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 el primer arranque. Acceda a él a través del túnel en http://10.8.0.1:3000 en lugar de exponer ese puerto públicamente. En el asistente, establezca tanto la dirección de escucha DNS como la dirección de escucha de administración en 10.8.0.1. Si unbound del primer fallo todavía mantiene la misma dirección, deténgalo primero con sudo systemctl disable --now unbound, porque ambos competirían por el puerto UDP 53 en una misma dirección y AdGuard Home terminaría 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 búsqueda que le llegue desde todos los pares, a menos que excluya a un cliente del registro. Esa exclusión es una decisión real de privacidad, no una ventaja sin coste: traslada la confianza de su proveedor de Internet a usted, y usted debe mantener actualizado ese equipo. Un servidor expuesto a Internet necesita tener primero las medidas básicas, y los primeros diez minutos en un VPS nuevo las 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 lo que un túnel operativo con consultas fallidas indica que el resolvedor configurado no responde. Pruebe 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, a menudo porque el stub de systemd-resolved sólo está enlazado a 127.0.0.53, o que el firewall del servidor está descartando el puerto UDP 53 recibido en wg0. Corrija primero el proceso que escucha y después abra el puerto sólo para wg0.

¿Cómo compruebo si mi DNS se está filtrando fuera de WireGuard?

Ejecute sudo tcpdump -ni any -c 10 port 53 en el cliente y observe la columna de interfaz mientras navega. Todos los paquetes que salgan del equipo deben usar wg0; los paquetes en lo hacia o desde 127.0.0.53 corresponden al stub local de systemd-resolved y son normales. Si aparecen en la interfaz inalámbrica o Ethernet, las consultas están saliendo en texto sin cifrar. 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 sea la dirección de su servidor confirma la filtración.

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

Sí, y 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 lo que la consulta sale por el enlace local aunque la línea DNS parezca correcta.

¿Por qué resolvectl muestra el servidor correcto, pero las consultas siguen yendo a otro sitio?

systemd-resolved envía simultáneamente un nombre que no coincide con ningún dominio de enrutamiento a todos los enlaces con ruta predeterminada, incluido wg0, y devuelve la primera respuesta correcta, que normalmente procede del router local. Añada PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~. al bloque [Interface] del cliente y elimine la línea DNS =. Después, resolvectl status wg0 debería informar de DNS Domain: ~., y todos los nombres que ningún otro enlace reclame con un dominio más específico se enviarán únicamente a wg0.

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

Corrija 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 de teléfonos y equipos de escritorio aplican los mismos valores DNS y AllowedIPs sin mostrar los componentes internos; por tanto, cuando el cliente Linux funcione correctamente, sólo tendrá que copiar una configuración que ya ha verificado.