Cómo solucionar DNS en WireGuard: 3 fallos comunes

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

DNS sobre WireGuard falla de tres formas, y cada una tiene su propia solución. Puede que no se resuelva ningún nombre, que los nombres se resuelvan pero las consultas salgan del equipo sin pasar por el túnel, o que el gestor de resolución del propio cliente sobrescriba la configuración unos segundos después de iniciar la interfaz. Casi nunca el problema está en el túnel. El problema suele ser la línea que indica al cliente qué resolver debe consultar y el enrutamiento que determina cómo viajan los paquetes hasta ese resolver.

WireGuard transporta paquetes IP y no sabe nada de 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 wrapper de shell que inicia la interfaz, y wg-quick modifica después la configuración del resolver 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 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 que el túnel funciona correctamente antes de tocar 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 configuración del resolver lo solucionará. Si los pings responden pero el rendimiento se desploma cuando empieza el tráfico real, se trata de un problema distinto, y el bajo rendimiento de WireGuard casi siempre se debe a MTU y no a nada de lo descrito 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 los valores propios.

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 encamina el resolvedor

Este problema es peor porque todo parece funcionar. Los nombres se resuelven, las páginas cargan y las consultas viajan sin cifrar por 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 a propósito las rutas locales más específicas para que el equipo pueda seguir accediendo a su impresora. El resolvedor que el cliente obtiene mediante DHCP, normalmente el router en 192.168.1.1, coincide con una de esas rutas locales. El tráfico viaja por 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 de su enlace Ethernet o inalámbrico todavía muestra Current DNS Server: 192.168.1.1, mientras que el bloque wg0 no muestra ninguno, esa es la 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 confirmada desde el extremo remoto. La línea tcpdump es la prueba definitiva: una salida correcta coloca todos los paquetes destinados al puerto 53 en wg0, mientras que una fuga los coloca en wlan0 o enp3s0.

La solución tiene dos partes y ambas son necesarias. Configure DNS con una dirección que pertenezca al 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 necesita 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 viajarán por el túnel, aunque la red local todavía podrá saber qué proveedor eligió a partir de sesiones anteriores. Un resolvedor administrado por usted evita este problema.

La asignación del resolver es una de las diferencias visibles entre una configuración de WireGuard hecha manualmente y una malla coordinada. Forma parte del equilibrio descrito en WireGuard frente a Tailscale. Ejecutar un servidor de control Headscale autohospedado le proporciona esa coordinación sin entregar el material de sus claves a un tercero. Si esa última parte es la que le preocupa, tenga en cuenta que Tailscale nunca almacena las claves que cifran su tráfico. La cuestión más importante 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, esta configuración la aplica un script de shell que debe determinar cuál de varios gestores de resolución está en uso.

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

resolvconf: command not found

wg-quick intenta ejecutar resolvconf, pero ese binario no está instalado. Instale la implementación que se comunica con systemd-resolved y vuelva 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 hacerle perder una tarde. La interfaz se activa, resolvectl status wg0 muestra correctamente DNS Servers: 10.8.0.1 y las consultas siguen utilizando el resolvedor antiguo. systemd-resolved mantiene una lista de resolutores independiente para cada enlace y selecciona un enlace para cada consulta. Si ningún enlace está marcado como ruta predeterminada para los nombres, sigue utilizando el resolutor del enlace inalámbrico, porque ese enlace tiene un dominio de búsqueda y el suyo no.

Configure el resolutor y reclame la ruta predeterminada en el mismo paso. %i se sustituye por el nombre de la interfaz, por lo que este bloque funciona sin cambios con 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 utilice PostUp de esta forma, porque de lo contrario dos mecanismos escriben el estado del resolutor y sólo 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íquelo.

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 vuelve a aplicarse la selección de enlaces.

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

La mejora: su propio resolvedor con filtrado a través del túnel

Cuando las consultas ya viajan de forma fiable por el túnel, el resolvedor del extremo remoto 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 instalar software en los clientes ni configurar cada dispositivo. El script oficial de instalación, comprobado en julio 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 inicio. Acceda 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, establezca tanto la dirección de escucha de DNS como la dirección de escucha de administración en 10.8.0.1. Si unbound del primer fallo sigue usando la misma dirección, deténgalo primero con sudo systemctl disable --now unbound, porque dos procesos no pueden asociarse al puerto UDP 53 en una misma dirección y el segundo 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 resolución solicitada por todos los pares. Esto es una decisión de privacidad real, no una ventaja gratuita: traslada la confianza del proveedor de Internet a usted, y usted debe mantener ese equipo actualizado. Un servidor expuesto a Internet necesita tener primero los aspectos básicos correctamente configurados, y los primeros diez minutos en un VPS nuevo los cubren.

FAQ

¿Por qué mi túnel de 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 consultas fallan, el resolver configurado no está respondiendo. Pruebe con dig +short @10.8.0.1 example.com desde el cliente. Una respuesta communication timed out significa que no hay ningún resolver escuchando en esa dirección del túnel, a menudo porque el stub de systemd-resolved sólo se enlaza a 127.0.0.53, o que el firewall del servidor está descartando el puerto UDP 53 recibido en wg0. Corrija primero el listener y después abra el puerto sólo para wg0.

¿Cómo compruebo si mi DNS se filtra por WireGuard?

Ejecute sudo tcpdump -ni any -c 10 port 53 en el cliente y observe la columna de interfaz mientras navega. Todos los paquetes deben usar wg0. Si aparecen en la interfaz inalámbrica o Ethernet, las consultas están saliendo en texto claro. dig +short whoami.akamai.net ofrece una segunda comprobación, porque responde con la dirección pública del resolver recursivo que realizó la consulta. Por tanto, una respuesta que no sea la dirección de su servidor confirma la fuga.

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

Sí. La dirección del resolver también debe estar dentro de AllowedIPs o el cliente no tendrá una ruta hacia ella. Con AllowedIPs = 10.8.0.0/24, un resolver en 10.8.0.1 queda incluido y la consulta se cifra. Un resolver 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 mantiene una lista de resolvers por 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ñada PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~. al bloque [Interface] del cliente y elimine la línea DNS =. A continuación, resolvectl status wg0 debería mostrar Default Route: yes.

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

Corrija primero un cliente Linux, porque es la única plataforma que muestra el mecanismo. resolvectl status y tcpdump indican qué resolver 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 detalles internos. Cuando el cliente Linux funcione correctamente, podrá copiar una configuración que ya ha comprobado.