Acceder a LAN domestica mediante WireGuard

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 significa dos cosas diferentes

Un ajuste realiza dos funciones, y leerlo de la misma manera en ambos extremos es la causa de 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 lee para el tráfico saliente, AllowedIPs es una tabla de enrutamiento. wg-quick convierte cada entrada en una ruta que apunta a wg0. Un paquete dirigido 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 sólo se incluye 10.8.0.0/24, el portátil envía el tráfico LAN por la Wi-Fi local, donde puede descartarse o llegar a un 192.168.20.10 completamente distinto. Si una ruta envía el paquete a wg0 de todos modos y ningún peer declara esa dirección, el kernel lo descarta y registra un error de transmisión en wg0, no un error de recepción.

Si se lee para el tráfico entrante, AllowedIPs es una lista de control de acceso. Después de que WireGuard descifra un paquete de un peer, comprueba la dirección de origen interna con la AllowedIPs de ese peer y descarta el paquete si no coincide. No se registra nada a menos que se activen los mensajes de depuración del kernel. El único indicio es el contador de errores de recepción en wg0, que muestra ip -s link show wg0, y el paquete simplemente desaparece.

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

La pareja correspondiente de archivos de configuración

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, o el handshake nunca se inicia y los registros del cliente muestran Handshake for peer 1 (203.0.113.7:51820) did not complete after 5 seconds, retrying (try 2). Esta guía asume que ya ha superado ese punto.

Hay cuatro líneas diferentes de una configuración simple de túnel completo, y cada una es deliberada.

• 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 casa, que normalmente es lo que quiere cuando sólo necesita 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á usar 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, sin que se muestre 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 silencio, por lo que 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ñadir una cambia la resolución de nombres de todo el equipo cliente. La sección siguiente sobre DNS explica su función antes de activarla.

Un túnel completo también permite acceder a la LAN, ya que 0.0.0.0/0 coincide con todas las direcciones. Hace pasar todo el tráfico por el túnel y provoca una colisión de subred que no se puede solucionar desde el cliente.

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

Elija para la subred doméstica un rango 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 de consumo. 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 establecer la conexión, y el comportamiento varía 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. Si la ruta existente tiene la misma métrica, ip route add rechaza la operación y la interfaz no llega a activarse:

RTNETLINK answers: File exists

En un portátil gestionado por NetworkManager, la ruta Wi-Fi suele tener una métrica como 600. Por eso, la adición se realiza correctamente y la ruta del túnel, con métrica 0, tiene prioridad. El NAS responde, pero todos los hosts de la red de la cafetería que están dentro de ese rango, incluido a menudo su servidor DNS, quedan detrás del túnel.

Con un túnel completo, wg-quick instala reglas de enrutamiento basado en políticas que mantienen deliberadamente las rutas más específicas fuera de la tabla principal. La ruta local 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 no es accesible. Renumerar la LAN doméstica es la única solución real.

Convierte el servidor en un enrutador

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, rara vez, 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. Ese es el origen del clásico informe «funcionó hasta el martes».

El reenvío también debe mantenerse a través del firewall. En Ubuntu con ufw activo, los paquetes reenviados se descartan a menos que DEFAULT_FORWARD_POLICY="ACCEPT" esté establecido en /etc/default/ufw o una regla ufw route allow coincida con ellos. Docker, con su backend de iptables predeterminado, establece la misma política cuando necesita activar el reenvío durante el arranque, a menos que ip-forward-no-drop esté establecido en /etc/docker/daemon.json. Por eso, si sudo iptables -S FORWARD | head -1 muestra -P FORWARD DROP en un equipo cuyo firewall nunca configuró manualmente, normalmente significa que Docker lo hizo. No obstante, también puede establecerlo un script de aprovisionamiento u otro gestor de firewall. En cualquier caso, 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 llega realmente al NAS. Aun así, no verá ninguna respuesta porque el paquete de respuesta 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 pierde.

Opción A: aplicar masquerade en el servidor WireGuard. El servidor reescribe la dirección de origen de cada paquete del túnel que reenvía a través de enp1s0 como 192.168.20.5, la dirección LAN propia de esa interfaz. El NAS ve ahora una solicitud procedente de un equipo vecino de su propia subred, responde directamente al servidor y este 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 permite saber si la regla se está utilizando.

Masquerade ofrece una segunda ventaja que es fácil pasar por alto. Muchos equipos ejecutan un firewall que sólo acepta conexiones procedentes 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. En esos equipos, un paquete procedente de 10.8.0.2 se descarta 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 todos los equipos de la LAN. No podrá distinguir los clientes entre sí y las reglas por cliente en los dispositivos de la LAN no podrán funcionar.

Opción B: una ruta estática en el router doméstico. Indique al router que 10.8.0.0/24 se encuentra 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árdelo en la configuración persistente del router, porque un ip route add ejecutado en un equipo Linux desaparece 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 equipos que utilizan ese router como gateway predeterminado. Cualquier equipo con un firewall local limitado a la subred todavía necesita su propia regla para 10.8.0.0/24. Empiece con masquerade, porque no requiere nada fuera del equipo que ya controla, y cambie a la ruta estática cuando necesite conservar las direcciones reales de los clientes.

Cómo encontrar cuál de las cuatro reglas es incorrecta

Siga el recorrido desde el cliente hacia fuera. 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 AllowedIPs del cliente no incluye la subred LAN, o está ganando una ruta local para el mismo rango. Este es el conflicto de subred descrito anteriormente. Un ping: connect: Network is unreachable apunta a la misma causa.

¿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. ICMP significa protocolo de mensajes de control de Internet y es el protocolo que utiliza ping. Si no aparece nada y el handshake es correcto, casi siempre se trata de la regla 2: AllowedIPs del servidor para ese peer no incluye 10.8.0.2. Por tanto, el paquete se descartó durante el descifrado, antes de llegar a wg0. El contador de errores RX de ip -s link show wg0 en el servidor, que aumenta con cada ping, lo confirma. Si el contador no cambia, busque un firewall en el cliente que esté bloqueando el tráfico saliente hacia el túnel.

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

sudo tcpdump -ni enp1s0 icmp

Las solicitudes visibles en wg0 y ausentes aquí indican la regla 3. El reenvío está desactivado o una regla de FORWARD descartó el paquete. Con menor frecuencia, el filtrado estricto de la ruta inversa (rp_filter) lo descarta. Esto ocurre cuando la ruta de retorno del servidor hacia el origen utiliza una interfaz diferente. Las solicitudes visibles aquí con origen 10.8.0.2 y sin respuestas suelen indicar la regla 4. La respuesta no tiene una ruta de retorno, aunque un host que ignore el ping o que sólo responda a su propia subred produce exactamente el mismo resultado. 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 no responde. Revise el firewall del NAS y, en un host Linux, compruebe si net.ipv4.icmp_echo_ignore_all está configurado para ignorar el ping. La misma secuencia sirve para cualquier otro servicio si sustituye icmp por port 445 o por el puerto que necesite comprobar.

Se puede 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 domésticos, 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 incluye 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 hay que añadir 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 lo que, mientras el túnel está activo, las consultas del portátil se dirigen al resolvedor doméstico, no sólo las de los nombres domésticos. Sólo los nombres de un dominio más específico que otra interfaz anuncie continúan dirigiéndose a otro sitio. Compruebe el resultado con resolvectl status wg0. Si quiere que los nombres domésticos se resuelvan en casa y que todo lo demás se resuelva localmente, eso es DNS dividido, y corregir DNS mediante un túnel WireGuard explica toda la configuración.

¿No tiene una IP pública en casa? Coloque un VPS en medio

Si la página de estado del router muestra una dirección WAN dentro de 100.64.0.0/10, está detrás de CGNAT (traducción de direcciones de red a nivel del operador) y ningún handshake procedente de Internet puede llegar a su casa. Una dirección privada 192.168.x.x en ese campo suele indicar que hay un segundo router delante del suyo, es decir, doble NAT: ponga el router módem del ISP en modo bridge o reenvíe también el puerto UDP 51820 en ese dispositivo. Si no puede cambiar ese dispositivo o su propia dirección WAN tampoco es pública, trátelo como CGNAT. 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 hub y el equipo de casa se conecta a él de forma saliente.

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 del peer del equipo de casa obtiene AllowedIPs = 10.8.0.3/32, 192.168.20.0/24: su propia dirección del túnel, además de la subred en cuyo nombre tiene permitido comunicarse.
• En el VPS, la entrada del peer del portátil conserva 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 se dirige al hub.
• 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 que está 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 exactamente 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 explica en abrir un túnel inverso desde detrás de CGNAT. Cuando la gestión manual de las direcciones de los peers deje de resultar práctica, ejecutar un router de subred de Tailscale realiza el mismo trabajo de 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 resto de la LAN es un problema de enrutamiento. El AllowedIPs del cliente debe incluir 192.168.20.0/24; de lo contrario, el paquete nunca entra en el túnel. El servidor necesita tener net.ipv4.ip_forward configurado como 1; de lo contrario, descarta todo lo que no esté dirigido a él. Además, la LAN necesita una ruta de retorno a 10.8.0.0/24. Ejecute sudo tcpdump -ni enp1s0 icmp en el servidor mientras hace ping: si las solicitudes salen con el origen 10.8.0.2 y no regresan respuestas, normalmente 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 cuya dirección ya saben alcanzar y el router no interviene. La alternativa es una ruta estática para 10.8.0.0/24 a través de la dirección LAN del servidor. Resulta útil cuando 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 hay la misma subred en ambos extremos?

El portátil no puede usar simultáneamente 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 de túnel dividido falla cuando ip route add rechaza la configuración con RTNETLINK answers: File exists o, si la ruta Wi-Fi tiene una métrica superior, se establece y oculta tras el túnel los equipos locales de ese rango. 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 tanto, gana la red local y la LAN remota sigue inaccesible. Renumere la LAN doméstica usando un rango poco habitual, como 192.168.20.0/24. No existe 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, el resolvedor doméstico, al bloque [Interface] del cliente y asegúrese de que esa dirección esté dentro de AllowedIPs del peer; de lo contrario, la consulta nunca entra en el túnel. Compruebe también que el resolvedor responda a consultas externas a su propia subred, porque dnsmasq con local-service y el modo de escucha local de Pi-hole rechazan esas consultas. Una regla de masquerade en el servidor WireGuard evita el problema al reescribir la dirección de origen de la consulta.

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

Sí, con un tercer nodo. Detrás de CGNAT, la dirección WAN del router no es pública, por lo que ningún peer de Internet puede iniciar un handshake con él. En cambio, un handshake saliente funciona normalmente. 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 el VPS, asigne a la entrada del peer del equipo doméstico 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 forward que permita wg0 a wg0.