Un par de WireGuard no es accesible mientras otro funciona: lista de comprobación

Un par de WireGuard pasa tráfico y un segundo completa el handshake pero nunca llega a nada detrás del túnel. El par que funciona le dice que la interfaz, el puerto UDP y la clave del servidor probablemente están bien. No le dice nada sobre las AllowedIPs del segundo par, su dirección de origen interna ni las reglas de reenvío entre ambos. Recorra la lista en orden y deténgase en el primer paso cuya condición falle.

Paso 1: Anote la ruta que debería seguir el paquete

Dos clientes en el mismo concentrador no se alcanzan automáticamente. En un diseño de concentrador y radios, el servidor recibe el paquete en wg0 y debe reenviarlo de nuevo por wg0 hacia el otro par, lo que exige reenvío IP y una regla de reenvío. En un diseño directo de par a par, cada lado necesita el extremo del otro y la dirección de su túnel dentro de las AllowedIPs. Decida qué diseño está depurando antes de leer cualquier configuración.

La ruta esperada también le dice dónde mirar. Si el paquete debe cruzar el concentrador, el salto que falla es o las AllowedIPs del emisor, o el reenvío del concentrador, o las AllowedIPs del receptor. Si debe ir directo, el concentrador es irrelevante y los campos de extremo de ambos pares son los que importan.

Paso 2: Compare las AllowedIPs en ambos lados, no solo en uno

WireGuard usa las AllowedIPs a la vez como tabla de enrutamiento y como lista de acceso. Al enviar, la dirección de destino se busca en las AllowedIPs del par para elegir el túnel; al recibir, la dirección de origen interna debe caer dentro de las AllowedIPs del par emisor o el paquete se descarta. Un rango que falta en cualquiera de los dos lados produce el mismo síntoma: el transporte funciona, la carga desaparece.

Lea el estado vivo en lugar del archivo, porque una recarga puede haber fallado en silencio: sudo wg show wg0 allowed-ips. En el servidor, la entrada del par que falla debe incluir su dirección de túnel, por ejemplo 10.90.0.3/32. En el cliente, la entrada del par servidor debe incluir el destino que está probando, ya sea la dirección de túnel del concentrador o la subred remota. Los rangos superpuestos hacen ambigua la búsqueda y pueden seleccionar un par que no pretendía, así que manténgalos separados.

Paso 3: Compruebe la dirección de origen interna

Un cliente que enruta 10.90.0.3 por wg0 pero envía paquetes desde su dirección Wi-Fi será rechazado por el receptor, porque el origen no coincide con las AllowedIPs del par. Confirme qué elige realmente el núcleo con ip route get 10.90.0.3 from 10.90.0.2, y confirme la dirección asignada a la interfaz del túnel con ip -brief addr show wg0.

En el host Linux receptor, el filtrado de ruta inversa es una segunda puerta. Un rp_filter estricto en la interfaz que posee la ruta de vuelta puede descartar tráfico de túnel cuya ruta de retorno no coincide con la interfaz por la que llegó. Compruebe el valor efectivo antes de desactivarlo; en muchas topologías la corrección correcta es una ruta, no un filtro relajado.

Paso 4: Revise el reenvío del concentrador y la ruta de vuelta

Si el concentrador debe reenviar entre pares, el núcleo necesita net.ipv4.ip_forward=1, y el cortafuegos debe aceptar el flujo reenviado: entrada por wg0, salida por wg0, desde la dirección de túnel del emisor hasta la del receptor. Un fallo habitual es una regla de entrada que acepta UDP 51820 pero ninguna regla de reenvío], de modo que el handshake tiene éxito y la carga muere. Enumere las reglas efectivas con sudo nft list ruleset o el equivalente para su gestor de cortafuegos.

Después compruebe la respuesta. El host de destino debe tener una ruta de vuelta al emisor, ya sea por el concentrador o por su propia puerta de enlace. Si el concentrador también hace NAT en la subred del túnel, confirme que la traducción se aplica al flujo reenviado y que la respuesta llega al concentrador antes de que caduque el estado. Un fallo unidireccional que parece un problema de clave suele ser solo esta ruta de vuelta.

Por último, separe el handshake de los datos. Un par que completa el handshake pero se atasca en transferencias grandes suele tener un problema de MTU o MSS en esa ruta concreta, no un problema de AllowedIPs. Pruebe primero con un ping pequeño, luego con uno de tamaño completo, y compare los dos pares.

Paso 5: Cambie una cosa y mantenga intacto el par que funciona

Haga un solo cambio en la ruta que falla y vuelva a probar ambos pares. Sustituir las AllowedIPs de cada par por 0.0.0.0/0 es la forma más rápida de romper el par que ya funcionaba, porque cambia la decisión de enrutamiento de todo el tráfico de esa interfaz. Edite la entrada de ese par, recargue y vuelva a leer el estado vivo.

Anote qué ruta funcionó, cuál falló y la salida exacta del comando para cada una. Esa comparación vale más que un informe general de que la VPN está rota, y es lo primero que pedirá la siguiente persona.