WireGuard falla tras la inactividad: prueba primero la dirección

Cuatro preguntas preceden a cualquier cambio de configuración: si el mismo recurso funciona mientras el cliente está activo, cuánto duró el periodo de inactividad, si el dispositivo durmió o cambió de red, y si el fallo aparece solo en el tráfico que inicia el lado opuesto. Las respuestas separan una asignación NAT caducada de una radio dormida y de una aplicación obsoleta. También te dicen si un keepalive es siquiera relevante. Empieza por la dirección, porque cuesta un comando y elimina la mitad de las causas posibles.

¿Qué dirección falla?

Una nueva petición saliente del cliente y el tráfico que llega hacia él tras un periodo de calma someten de forma distinta al equipo con estado. Los paquetes salientes reconstruyen una asignación al salir, mientras que los entrantes necesitan que la asignación antigua haya sobrevivido. Esa asimetría es toda la prueba. Si el cliente puede salir pero no entra nada, la asignación probablemente caducó, y si no funciona ninguna de las dos, el túnel o el acceso de red del cliente desapareció.

Anota cuánto duró el periodo de calma y si el dispositivo durmió o pasó a otra red mientras tanto. Esos dos hechos cambian el diagnóstico antes que cualquier configuración.

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

Ejecuta esos tres comandos antes y después del periodo de calma, porque cada uno responde a una parte distinta de la pregunta. Una marca de tiempo de handshake que no se ha movido dice que las partes dejaron de hablar, mientras que un extremo que ha cambiado dice que la asignación se movió en lugar de morir. Los contadores de transferencia muestran si llegó algo, que es la diferencia entre una asignación caducada y una aplicación silenciosa. Anota los números en ambos puntos, porque la comparación es la prueba.

Sueño, radio y estado de la aplicación

En un teléfono o un portátil, un dispositivo dormido puede haber perdido por completo el acceso a la red, y un keepalive no puede restaurar una radio apagada ni completar un portal cautivo que no se ha satisfecho. Las plataformas móviles suspenden el trabajo en segundo plano por política, así que si el tráfico periódico continúa depende de la plataforma y de lo que la aplicación haya negociado con ella. Una conexión en caché es el tercer caso y el más engañoso, porque el regreso del túnel no es lo mismo que la reconexión de la aplicación a él.

Vuelve a abrir la aplicación tras el periodo de inactividad en lugar de confiar en la pestaña que quedó abierta. Si una petición nueva tiene éxito donde falló la sesión antigua, el túnel nunca fue el problema.

Qué hace realmente un keepalive

PersistentKeepalive envía periódicamente un paquete vacío autenticado a un par, lo que basta para mantener viva una asignación NAT entre pares y para que el extremo del par siga actualizado, como describe el inicio rápido de WireGuard. No repara una radio dormida, una ruta perdida ni una aplicación que nunca reintenta. Elige el intervalo con la configuración compatible del cliente y no actives un valor agresivo en todas partes solo porque una pantalla de estado se quede en silencio.

La mayoría de los periodos de inactividad no son fallos. Un túnel que se reconecta tras cinco minutos de silencio se comporta correctamente, y el problema es solo el caso en que algo debía llegar del lado opuesto.

Espera el intervalo que antes fallaba

Haz un cambio compatible y deja pasar el mismo periodo de inactividad antes de volver a probar ese recurso. Esperar es parte de la prueba y no una formalidad. El éxito inmediato tras una reconexión no dice nada sobre un síntoma de inactividad prolongada, porque la reconexión es justo el evento que reinicia el estado. Si el problema también aparece durante el uso activo, vuelve a las comprobaciones de handshake y de ruta de datos en lugar de añadir más tráfico periódico.

Mantén un cambio por prueba y anota la duración de inactividad usada. Sin eso, cada comparación posterior se desvía y nadie puede decir qué cambio importó. Registra los cuatro hechos juntos: dirección, duración, estado de sueño y comportamiento de la aplicación.