El handshake de WireGuard funciona, pero la subred de la oficina no responde

El handshake se completa, wg show informa de una transferencia reciente y la dirección del túnel del servidor responde a un ping. Un host de la LAN del servidor no. Tres condiciones deben cumplirse a la vez: el cliente debe enrutar el prefijo de la LAN hacia el túnel, el servidor debe reenviar los paquetes y la respuesta necesita un camino de vuelta. Cuando falta una de las tres, el síntoma es idéntico.

AllowedIPs es a la vez una lista de acceso y una tabla de rutas

En el cliente, la lista AllowedIPs decide tanto qué puede enviarse a ese par como qué rutas instala WireGuard. Una entrada de par que solo enumera la dirección del túnel del servidor instala una ruta de host, así que los destinos de la LAN nunca entran en el túnel. Añadir el prefijo de la LAN es lo primero que hay que verificar, y también es el cambio que más a menudo falta tras copiar una configuración. Un par ampliado a una ruta predeterminada es otro diseño, y también moverá el tráfico de internet del cliente.

Mantenga la ruta de host y el prefijo de la LAN como entradas separadas. Si la oficina tiene dos subredes, ambas pertenecen a la lista, y el segundo prefijo ausente produce un fallo que parece selectivo en lugar de total.

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

El reenvío y la traducción pertenecen al servidor

El servidor necesita el reenvío de IP activado, una regla de reenvío que acepte el tráfico que llega del túnel y una regla de traducción hacia su interfaz de LAN. La traducción es lo que hace funcionar el diseño sin tocar cada host de la red de la oficina. Entonces las respuestas vuelven al servidor en lugar de a una dirección que la LAN nunca ha oído. Sin ella, cada host necesita una ruta para la subred del túnel y una regla de firewall que la permita, lo que rara vez es aceptable en una red que administra otra persona.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Las reglas añadidas a mano desaparecen al reiniciar, así que átelas a la interfaz con los comandos de gancho de la configuración del servidor. Un conjunto de reglas que sobrevive a su interfaz es como una máquina acaba traduciendo tráfico para un túnel que ya no existe.

Cuando la LAN se mudó y la regla no

La sustitución de un router que renumera la subred de la oficina es la versión clásica de este fallo. El túnel sigue activo, el handshake sigue fresco y nada detrás del servidor responde, porque la regla de traducción sigue nombrando la dirección antigua. Los scripts de instalación a menudo incrustan la dirección de LAN del servidor en una regla POSTROUTING, y tras una renumeración esa dirección no existe en ninguna interfaz. Los paquetes se reescriben entonces hacia un destino que no puede responder.

iptables -t nat -n -L POSTROUTING
ip -br addr show

Compare las dos salidas. Un destino de traducción que no aparece en la lista de interfaces es el error, y corregirlo es un cambio de una línea una vez que lo ha visto. La regla puede vivir en una unidad generada en lugar de la configuración de WireGuard, así que recargue esa unidad tras editarla y confirme que el siguiente arranque no reescribe su cambio.

Dos sedes detrás de NAT necesitan un lugar donde encontrarse

Cuando ninguno de los dos lados acepta conexiones entrantes, la respuesta práctica es un host pequeño con una dirección pública y dos interfaces de WireGuard. Cada sede se conecta hacia fuera, el host intermedio enumera la LAN de cada par en su propia AllowedIPs, y el reenvío transporta paquetes entre los dos túneles. Nada del firewall de ninguna de las dos sedes tiene que cambiar, y por eso este diseño se extiende con facilidad.

El enrutamiento entre las sedes conserva las direcciones de origen originales y, por tanto, mantiene significativo el registro por host. Traducir en el host intermedio es más simple cuando las dos LAN se solapan, a costa de perder la identidad del origen en los registros. Decida qué propiedad importa antes de elegir.

Separe las capas con cuatro comprobaciones

Ejecute una comprobación por capa en lugar de cambiar tres cosas y esperar. La primera muestra la antigüedad del handshake y los contadores de cada par. La segunda muestra si el cliente enruta realmente ese destino hacia el túnel. La tercera y la cuarta le dicen si la solicitud llegó y si alguna política la descartó tras la llegada.

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

Una solicitud que llega y no obtiene respuesta apunta a la ruta de respuesta o al host de la LAN. Una solicitud que nunca llega apunta a AllowedIPs o a la ruta del cliente. Esos dos resultados necesitan correcciones distintas, y la captura es lo que los distingue.