WireGuard: cómo enrutar a la LAN doméstica

Por qué la LAN doméstica no responde a través de WireGuard

Para acceder a la LAN doméstica a través de WireGuard, deben coincidir cuatro configuraciones independientes. Tres de las cuatro todavía permiten tener un túnel que parece funcionar correctamente, lo que hace que este fallo resulte tan confuso. wg show informa de un handshake reciente, ping 10.8.0.1 responde en unos pocos milisegundos y ping 192.168.20.10 no devuelve nada.

Esta es la lista completa, en el orden en que un paquete se encuentra con cada configuración. LAN significa red de área local, es decir, la red privada situada detrás del router doméstico.

1. AllowedIPs en el cliente debe incluir la subred remota. De lo contrario, el paquete nunca entra en el túnel.
2. AllowedIPs en el servidor debe incluir la dirección del túnel del cliente. De lo contrario, el paquete se descarta en cuanto se descifra.
3. net.ipv4.ip_forward debe ser 1 en el servidor, porque Linux descarta cualquier paquete que no esté dirigido al propio equipo.
4. La LAN debe conocer una ruta de retorno a 10.8.0.0/24, mediante una regla de masquerade en el servidor o una ruta estática en el router doméstico.

Todos estos ajustes pueden fallar sin mostrar un mensaje de error. No se registra nada, no aparece ninguna advertencia y el handshake sigue funcionando durante todo el tiempo. Compruébelos en este orden y localizará el ajuste incorrecto en aproximadamente un minuto.

La red que usa esta guía

Todas las direcciones siguientes son ejemplos. Sustitúyalas por las suyas y mantenga la coherencia, porque una configuración actualizada sólo a medias es la segunda causa más común de este problema.

• La LAN doméstica es 192.168.20.0/24. El router doméstico es 192.168.20.1.
• El servidor WireGuard es un equipo Linux conectado a esa LAN. Su interfaz LAN enp1s0 tiene 192.168.20.5, y su interfaz de túnel wg0 tiene 10.8.0.1.
• El host al que quiere acceder es un NAS (almacenamiento conectado a la red) en 192.168.20.10.
• El cliente es un portátil situado en otro lugar, 10.8.0.2 dentro del túnel.

El servidor es un equipo de la LAN, no el router. Este es el caso normal: una Raspberry Pi o un mini PC antiguo. Esto es importante para la regla 4: el router no sabe que existe el túnel a menos que se lo indique, y todos los hosts de la LAN envían el tráfico destinado a otras subredes a ese router.

Si su conexión doméstica no tiene una dirección IP pública, nada de esto funciona por sí solo, porque ningún equipo de Internet puede iniciar un handshake con su casa. La sección sobre el uso de un VPS como intermediario cubre ese caso. Allí se aplican las mismas cuatro reglas, con un peer adicional que debe mantener identificado.

AllowedIPs tiene dos funciones distintas

Un mismo ajuste cumple dos funciones, y leerlo de la misma forma en ambos extremos es el error que causa la mayoría de estos casos. WireGuard denomina a este mecanismo enrutamiento mediante claves criptográficas. Se describe con más detalle en cómo WireGuard vincula las claves públicas a rangos de IP.

Si se interpreta para tráfico saliente, AllowedIPs es una tabla de enrutamiento. wg-quick convierte cada entrada en una ruta que apunta a wg0. Un paquete destinado a 192.168.20.10 se cifra y se envía a un peer sólo si algún peer declara un rango que contiene esa dirección. Si se incluye únicamente 10.8.0.0/24, el portátil envía el tráfico de la LAN por la Wi-Fi local. Allí puede descartarse o llegar a un 192.168.20.10 completamente distinto.

Si se interpreta para tráfico entrante, AllowedIPs es una lista de control de acceso. Después de que WireGuard descifra un paquete de un peer, comprueba que la dirección de origen interna esté incluida en el AllowedIPs de ese peer. Si no coincide, descarta el paquete. No hay ninguna línea de registro ni ningún contador para ese descarte. El paquete simplemente desaparece.

Por tanto, los dos archivos de configuración nunca son imágenes especulares. El cliente enumera lo que quiere alcanzar a través del servidor. El servidor enumera las direcciones de origen que ese cliente puede usar.

El par de archivos de configuración correspondiente

Cliente, /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = <laptop private key>
Address = 10.8.0.2/32

[Peer]
PublicKey = <server public key>
Endpoint = home.example.com:51820
AllowedIPs = 10.8.0.0/24, 192.168.20.0/24
PersistentKeepalive = 25

Servidor, /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = <server private key>
Address = 10.8.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <laptop public key>
AllowedIPs = 10.8.0.2/32

El router doméstico también necesita un reenvío de puertos, UDP 51820 a 192.168.20.5. De lo contrario, el handshake nunca se inicia y los registros del cliente muestran Handshake for peer 1 did not complete after 5 seconds, retrying. Esta guía asume que ya ha superado ese punto.

Cuatro líneas difieren de una configuración normal de túnel completo. Cada diferencia es intencionada.

• AllowedIPs = 10.8.0.0/24, 192.168.20.0/24 en el cliente, en lugar de 0.0.0.0/0, ::/0. Es un túnel dividido: la subred del túnel y la LAN doméstica pasan por wg0, y todo lo demás conserva su ruta local. La navegación web no pasa por la conexión de su domicilio. Normalmente es lo que necesita cuando sólo quiere acceder al NAS.
• AllowedIPs = 10.8.0.2/32 en el servidor, una dirección en lugar de un rango. Escriba 10.8.0.0/24 ahí y ese único cliente podrá reclamar cualquier dirección dentro del túnel. Si más adelante añade un segundo peer con un rango solapado, el tráfico se dirige al peer configurado en último lugar. No se muestra ningún error.
• PersistentKeepalive = 25 sólo en el cliente. El cliente está detrás de NAT (traducción de direcciones de red), y su router olvida la asignación UDP después de uno o dos minutos de inactividad. Por eso, el servidor ya no puede alcanzarlo. El servidor tiene una dirección pública y no necesita keepalive.
• Todavía no hay ninguna línea DNS =. Añadirla cambia la resolución de nombres de todo el equipo cliente. La sección sobre DNS explica su función antes de activarla.

Un túnel completo también permite acceder a la LAN, porque 0.0.0.0/0 coincide con todas las direcciones. Sin embargo, envía todo su tráfico por el túnel y crea una colisión de subred que no puede corregir desde el cliente.

Por qué la misma subred en ambos extremos impide que funcione

Elija una subred doméstica que casi nadie más utilice, como 192.168.20.0/24 o 10.44.7.0/24. 192.168.1.0/24 y 192.168.0.0/24 son los valores predeterminados de fábrica en la mayoría de los routers domésticos, por lo que tarde o temprano su portátil se conectará a una red de una cafetería o un hotel que utilice exactamente ese rango.

La colisión impide continuar y se manifiesta de forma distinta en cada caso. Con un túnel dividido, wg-quick intenta añadir una ruta para un prefijo que ya existe en la interfaz Wi-Fi, ip route add la rechaza y la interfaz no llega a activarse:

RTNETLINK answers: File exists

Con un túnel completo, wg-quick instala reglas de enrutamiento por políticas que mantienen deliberadamente las rutas más específicas fuera de la tabla principal. La ruta local de 192.168.1.0/24 tiene prioridad sobre el túnel, por lo que todos los paquetes destinados a la LAN remota salen por el enlace local. El túnel está activo, el handshake funciona y el NAS es inaccesible. Renumerar la LAN doméstica es la única solución real.

Convierte el servidor en un router

ip route show default
printf 'net.ipv4.ip_forward = 1\n' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
sysctl net.ipv4.ip_forward

El primer comando muestra el nombre real de la interfaz LAN. Las imágenes actuales usan nombres como enp1s0 o ens3 y, en raras ocasiones, eth0. Una regla de masquerade que indique la interfaz incorrecta no coincide con ningún paquete. El último comando debería mostrar net.ipv4.ip_forward = 1. Un sudo sysctl -w sin argumentos establece el mismo valor, pero se pierde tras el siguiente reinicio. Este es el caso clásico de «funcionó hasta el martes».

El reenvío también debe sobrevivir al firewall. En Ubuntu con ufw activo, los paquetes reenviados se descartan si DEFAULT_FORWARD_POLICY="ACCEPT" no está establecido en /etc/default/ufw. Docker establece esta misma política por su cuenta. Por eso, si sudo iptables -S FORWARD | head -1 muestra -P FORWARD DROP en un equipo cuyo firewall nunca configuró manualmente, Docker la estableció y el tráfico del túnel necesita una regla de aceptación explícita.

Por qué las respuestas nunca regresan

Si configura correctamente las reglas 1 a 3, el ping sí llega al NAS. Aun así, no verá ninguna respuesta porque el paquete no tiene una ruta de regreso. El NAS responde a 10.8.0.2, una dirección que está fuera de su propia subred, así que entrega el paquete a su gateway predeterminado, el router doméstico en 192.168.20.1. Ese router nunca ha aprendido la ruta a 10.8.0.0/24, por lo que reenvía la respuesta a su propio gateway predeterminado, la conexión a Internet, donde se descarta. La solicitud llega, pero la respuesta se desecha.

Opción A: aplicar masquerade en el servidor WireGuard. El servidor reescribe la dirección de origen de cada paquete reenviado a 192.168.20.5, su propia dirección LAN. El NAS ve ahora una solicitud de un equipo vecino de su propia subred, responde directamente al servidor y el servidor revierte la reescritura y envía la respuesta de vuelta por el túnel. No es necesario cambiar nada más en la LAN.

Añádalo al bloque [Interface] del servidor para que la regla aparezca y desaparezca junto con la interfaz:

PostUp = iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o enp1s0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.8.0.0/24 -o enp1s0 -j MASQUERADE

En un equipo que ya esté gestionado con nftables, escríbalo en /etc/nftables.conf:

table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    ip saddr 10.8.0.0/24 oifname "enp1s0" counter masquerade
  }
}

Conserve la palabra clave counter. Sin ella, sudo nft list ruleset muestra la regla sin el contador de paquetes, y ese contador es precisamente lo que indica si la regla se está utilizando.

Masquerade ofrece una segunda ventaja que es fácil pasar por alto. Muchos hosts ejecutan un firewall que sólo acepta conexiones de su propia subred. El uso compartido de archivos de Windows funciona así de forma predeterminada, al igual que varios paneles de administración de NAS. El host de destino descarta un paquete procedente de 10.8.0.2 aunque el enrutamiento sea correcto. Después de aplicar masquerade, el origen es una dirección LAN, por lo que esas reglas coinciden. El coste es que todos los clientes del túnel aparecen como 192.168.20.5 en los registros de cada host de la LAN. Por tanto, no puede distinguir los clientes y las reglas por cliente en los dispositivos LAN no pueden funcionar.

Opción B: una ruta estática en el router doméstico. Indique al router que 10.8.0.0/24 está detrás de 192.168.20.5. En un router Linux, sólo necesita un comando:

sudo ip route add 10.8.0.0/24 via 192.168.20.5

Los routers de consumo suelen tener una página llamada Static Routes o Routing dentro de la configuración avanzada: destino 10.8.0.0, máscara 255.255.255.0, gateway 192.168.20.5. Guárdela en la configuración persistente del router, porque un ip route add introducido en un equipo Linux se pierde en el siguiente reinicio.

Esta opción conserva la dirección real del cliente, por lo que los registros y las reglas por cliente de la LAN siguen siendo útiles. Requiere un router compatible con rutas estáticas y sólo ayuda a los hosts que utilizan ese router como gateway predeterminado. Cualquier host con un firewall local limitado a la subred también necesita su propia regla para 10.8.0.0/24. Empiece con masquerade, porque no requiere nada fuera del equipo que ya controla, y pase a la ruta estática cuando necesite conservar las direcciones reales de los clientes.

Cómo encontrar cuál de los cuatro elementos es incorrecto

Empiece por el cliente y avance hacia el exterior. Cada paso indica si el paquete llegó hasta ese punto.

¿Entra el paquete en el túnel? En el cliente:

ip route get 192.168.20.10

La respuesta debe indicar dev wg0. Si indica la interfaz Wi-Fi, la regla 1 es incorrecta y el AllowedIPs del cliente no incluye la subred LAN. Un ping: connect: Network is unreachable apunta a la misma línea.

¿Llegan los paquetes al servidor? Ejecute esto en el servidor y, después, haga ping al NAS desde el cliente:

sudo tcpdump -ni wg0 icmp

Una ruta operativa muestra IP 10.8.0.2 > 192.168.20.10: ICMP echo request, donde ICMP es el protocolo de mensajes de control de Internet que usa ping. Si no aparece nada, pero el handshake es correcto, el problema está en la regla 2: el AllowedIPs del servidor para ese peer no incluye 10.8.0.2, por lo que el paquete se descartó durante el descifrado antes de llegar a wg0.

¿Salen hacia la LAN? En el servidor, supervise el lado de la LAN:

sudo tcpdump -ni enp1s0 icmp

Las solicitudes visibles en wg0 y ausentes aquí indican un problema en la regla 3: el reenvío está desactivado o una regla de FORWARD descartó el paquete. Las solicitudes visibles aquí con origen 10.8.0.2 y sin respuestas indican un problema en la regla 4: la respuesta no tiene una ruta de retorno. Las solicitudes visibles aquí con origen 192.168.20.5 y sin respuestas indican que la regla de masquerade funciona y que el propio host de destino está rechazando la conexión; revise el firewall del NAS. La misma secuencia sirve para cualquier otro servicio si sustituye icmp por port 445 o por el puerto que necesite comprobar.

Puedo acceder a la IP, pero no al nombre

ssh 192.168.20.10 funciona y ssh nas.home.arpa falla:

ssh: Could not resolve hostname nas.home.arpa: Name or service not known

El túnel no tiene ningún problema. La resolución de nombres sigue una ruta independiente, y el portátil continúa consultando el resolvedor que aprendió de la Wi-Fi local. Ese resolvedor no conoce los nombres de la red doméstica.

Para que funcionen los nombres de la red doméstica deben cumplirse dos condiciones. La dirección del resolvedor debe estar dentro de AllowedIPs en el cliente; de lo contrario, la consulta DNS (sistema de nombres de dominio) nunca entra en el túnel. Además, el resolvedor debe aceptar consultas cuyo origen sea 10.8.0.2. Muchos resolvedores domésticos las rechazan de forma predeterminada: dnsmasq ejecutándose con local-service sólo responde a consultas procedentes de una subred conectada directamente, y Pi-hole se distribuye con un modo de escucha que sólo permite solicitudes locales. Una regla de masquerade oculta este problema, porque después de la reescritura la consulta llega desde 192.168.20.5.

En el cliente sólo hace falta una línea:

DNS = 192.168.20.1

En un cliente Linux que necesite openresolv o un equivalente; de lo contrario, wg-quick se detiene con resolvconf: command not found. Antes de configurarlo, compruebe qué hace en un sistema con systemd-resolved: wg-quick registra esos servidores de forma exclusiva. Por tanto, mientras el túnel está activo, todas las consultas del portátil se envían al resolvedor doméstico, no sólo las correspondientes a nombres domésticos. Compruebe el resultado con resolvectl status wg0. Si quiere que los nombres domésticos se resuelvan en casa y todo lo demás de forma local, eso es DNS dividido, y corregir DNS a través de un túnel WireGuard explica toda la configuración.

¿No tiene una IP pública en casa? Use un VPS como intermediario

Si la página de estado del router muestra una dirección WAN dentro de 100.64.0.0/10 o una dirección privada 192.168.x.x, está detrás de CGNAT (traducción de direcciones de red a nivel de operador) y ningún handshake desde Internet puede llegar a su red doméstica. Un handshake saliente sigue funcionando con normalidad, por lo que la solución es un tercer nodo con una dirección pública. Un VPS pequeño ejecuta el concentrador y el equipo de casa se conecta a él desde fuera.

Las cuatro reglas no cambian. Ahora se aplican a través de dos saltos, por lo que el registro de direcciones se duplica.

• En el VPS, la entrada de peer del equipo de casa obtiene AllowedIPs = 10.8.0.3/32, 192.168.20.0/24: su propia dirección del túnel y la subred que tiene permitido representar.
• En el VPS, la entrada de peer del portátil sigue siendo AllowedIPs = 10.8.0.2/32.
• En el portátil, el peer del VPS obtiene AllowedIPs = 10.8.0.0/24, 192.168.20.0/24, porque ahora todo el tráfico va al concentrador.
• En el equipo de casa, el peer del VPS obtiene AllowedIPs = 10.8.0.0/24 y el equipo de casa anuncia PersistentKeepalive = 25, porque ahora es el lado situado detrás de NAT.
• El VPS también necesita net.ipv4.ip_forward = 1 y su cadena de reenvío debe permitir wg0 a wg0, porque el tráfico del portátil llega y sale por la misma interfaz. Un firewall escrito para un VPS con túnel completo bloquea precisamente ese tráfico.

Si todavía no ha configurado el extremo del VPS, configurar WireGuard en un VPS explica la generación de claves, el firewall y la unidad de systemd. El patrón general para acceder a una máquina que no puede aceptar conexiones entrantes se describe en abrir un túnel inverso desde detrás de CGNAT. Cuando deje de ser práctico administrar manualmente las direcciones de los peers, ejecutar un router de subred de Tailscale realiza el mismo enrutamiento y automatiza el registro de direcciones.

Haga que persista tras reiniciar

sudo systemctl enable --now wg-quick@wg0
sudo systemctl enable --now nftables
sudo wg show

enable --now es la parte que muchos omiten. Un wg-quick up wg0 ejecutado manualmente desaparece después de la siguiente actualización del kernel y el reinicio. wg show debe mostrar el par con una línea latest handshake reciente y contadores de transferencia distintos de cero en ambas direcciones.

Añadir otro cliente más adelante no requiere reiniciar el servicio, lo que desconectaría a todos los usuarios conectados:

sudo bash -c 'wg syncconf wg0 <(wg-quick strip wg0)'

wg-quick strip muestra la configuración sin las claves que sólo entiende wg-quick, y syncconf aplica la diferencia mientras las sesiones activas siguen funcionando. Sólo actualiza los pares. Un Address modificado o una nueva línea PostUp todavía requieren bajar y volver a subir completamente la interfaz.

FAQ

¿Por qué puedo hacer ping al servidor WireGuard, pero no a ningún otro equipo de la LAN doméstica?

Hacer ping a 10.8.0.1 sólo confirma que el túnel está activo. El acceso al resto de la LAN es un problema de enrutamiento. El AllowedIPs del cliente debe incluir 192.168.20.0/24, o el paquete nunca entra en el túnel. El servidor necesita net.ipv4.ip_forward configurado como 1, o descarta todo lo que no esté dirigido a él. Además, la LAN necesita una ruta de retorno hacia 10.8.0.0/24. Ejecute sudo tcpdump -ni enp1s0 icmp en el servidor mientras hace ping: si las solicitudes salen con origen 10.8.0.2 y no llegan respuestas, falta la ruta de retorno.

¿Necesito una ruta estática en el router doméstico?

Sólo si omite la regla de masquerade. Una regla de masquerade en el servidor WireGuard reescribe la dirección de origen del tráfico del túnel con la dirección LAN del propio servidor. Así, los equipos de la LAN responden a un vecino que ya saben alcanzar y el router no interviene. La alternativa es una ruta estática hacia 10.8.0.0/24 a través de la dirección LAN del servidor. Conviene configurarla si quiere que los equipos de la LAN registren las direcciones reales de los clientes o aplicar reglas de firewall por cliente en esos equipos.

¿Por qué se rompe el túnel cuando ambas redes usan la misma subred?

El portátil no puede mantener dos rutas para el mismo prefijo. Si la red local asigna 192.168.1.0/24 y la LAN doméstica también usa 192.168.1.0/24, un wg-quick up con túnel dividido falla cuando ip route add rechaza la operación con RTNETLINK answers: File exists. En cambio, el túnel completo se establece, pero wg-quick instala reglas de política que mantienen las rutas más específicas fuera de la tabla principal. Por eso gana la red local y la LAN remota sigue inaccesible. Renumere la LAN doméstica con una red poco habitual, como 192.168.20.0/24. No hay una solución en el cliente.

Puedo acceder al NAS por IP, pero no por nombre. ¿Qué falta?

La resolución de nombres no sigue el túnel automáticamente. Añada DNS = 192.168.20.1, su resolvedor doméstico, al bloque [Interface] del cliente y asegúrese de que esa dirección esté incluida en el AllowedIPs del peer. De lo contrario, la consulta nunca entra en el túnel. Compruebe también que el resolvedor responda a consultas procedentes de fuera de su propia subred, porque dnsmasq con local-service y el modo de escucha sólo local de Pi-hole rechazan esas consultas. Una regla de masquerade en el servidor WireGuard evita este problema al reescribir la dirección de origen de la consulta.

Mi conexión doméstica no tiene una IP pública. ¿Todavía puedo acceder a mi LAN?

Sí, con un tercer nodo. Detrás de CGNAT, la dirección WAN del router es privada, por lo que ningún peer de Internet puede iniciar un handshake con él. En cambio, un handshake saliente funciona con normalidad. Ejecute WireGuard en un VPS con una dirección pública y haga que el equipo doméstico se conecte a él mediante PersistentKeepalive = 25. En la entrada del peer correspondiente al equipo doméstico en el VPS, configure un AllowedIPs que contenga su dirección del túnel y 192.168.20.0/24. Después, active el reenvío en el VPS y añada una regla de reenvío que permita wg0 hacia wg0.