La VPN por UDP se atasca en reposo: el cortafuegos olvidó tu flujo

La VPN se conecta, funciona un rato y luego deja de pasar tráfico mientras el cliente sigue mostrando una sesión. Reconectar lo arregla, lo que hace que parezca un fallo del cliente. Normalmente es un cortafuegos o un dispositivo NAT que descartó una asignación UDP inactiva y no tiene ni idea de que el túnel sigue existiendo.

El síntoma es lo bastante consistente para diagnosticarlo: aparece tras la inactividad, no bajo carga.

Cómo se ve un atasco por inactividad

Mídelo en lugar de describirlo. Anota cuánto tiempo el túnel queda inactivo antes de que el tráfico se detenga, si un paquete saliente nuevo lo revive y si la interfaz del cliente todavía conserva su dirección. Si una petición nueva del cliente funciona pero una respuesta a un flujo existente no, la asignación es la sospechosa. Si nada funciona hasta que reconectas, el estado de sesión del cliente también se ha perdido.

Ambos están relacionados con la inactividad y necesitan soluciones distintas.

Apunta los tiempos antes de cambiar nada. Un informe de que se detiene tras unos diez minutos de inactividad es verificable, mientras que un informe de que cae al azar no lo es. Esa diferencia decide si persigues un temporizador o un cambio de enrutamiento.

Encuentra el dispositivo que olvidó

Varios dispositivos pueden mantener estado para el mismo flujo: el router local, un traductor aguas arriba, un límite de nube y el cortafuegos del host. Cada uno tiene su propio temporizador y gana el más corto. Una interrupción de cinco minutos suele significar que un dispositivo está configurado muy por debajo de los demás.

No des por hecho que el valor predeterminado documentado es el tiempo de espera de tu ruta. Es el valor predeterminado de un solo dispositivo.

• Router doméstico: a menudo minutos, a veces mucho menos.
• NAT en la nube o balanceador de carga: consulta el tiempo de espera de inactividad documentado específicamente para UDP.
• Cortafuegos del host: los temporizadores de seguimiento de netfilter se aplican por flujo.

Comprueba los temporizadores en la ruta real

En Linux, los temporizadores de seguimiento de netfilter son visibles y ajustables: sysctl net.netfilter.nf_conntrack_udp_timeout y net.netfilter.nf_conntrack_udp_timeout_stream. El segundo se aplica cuando ya se ha visto tráfico en ambos sentidos, y por eso un túnel establecido puede sobrevivir a una sonda simple.

RFC 4787 establece el comportamiento de UDP NAT y los mínimos recomendados. Es la referencia que hay que citar cuando el valor predeterminado de un proveedor parece inusualmente corto.

Keepalive y reconexión son herramientas distintas

Un keepalive mantiene viva una asignación; una reconexión reconstruye una sesión muerta. Resuelven fallos diferentes y no son ajustes de velocidad intercambiables. La opción PersistentKeepalive de WireGuard envía un paquete a un intervalo fijo para mantener abierta la vinculación NAT. La opción keepalive de OpenVPN hace el mismo trabajo a su manera. Ninguna ayuda si el dispositivo intermedio ya ha olvidado el flujo y descarta ambas direcciones.

Las sondas extremadamente frecuentes añaden trabajo sin arreglar el límite equivocado.

Verifica con una petición nueva, no con una recarga de página

Después de cambiar un temporizador o añadir un keepalive, repite el escenario de inactividad exactamente como antes. Luego haz una petición realmente nueva desde la aplicación cubierta. Una pestaña del navegador ya cargada puede renderizarse desde la caché y no decirte nada.

Si el atasco persiste, muévete un salto hacia fuera y comprueba la tabla de estados de ese dispositivo.