Por qué tu VPN tarda más en recuperarse que la caída

El Wi-Fi volvió hace treinta segundos y la VPN sigue caída, así que el cliente parece averiado. A menudo solo sigue su propio calendario de reintentos, y ese calendario no sabe que la red acaba de volver. Esa brecha es toda la historia: el tiempo de recuperación es la caída más cualquier espera que el cliente ya haya asumido. Bajar todos los temporizadores es una respuesta, y entender qué temporizador importa es la otra.

Tres condiciones deciden si el ajuste ayuda: qué etapa es lenta, si el fallo es reintentable siquiera y cómo se entera el cliente de que la red ha vuelto.

Tres esperas que parecen una

La resolución del punto final, la negociación de IKE o TLS, la retransmisión de paquetes y iniciar un intento nuevo son eventos separados con temporizadores separados. strongSwan documenta el retroceso de retransmisión para IKE, y OpenVPN tiene sus propios controles de reintento con una semántica distinta. Copiar un número de uno a otro supone que los mecanismos coinciden, y no coinciden. Lee la secuencia del registro antes de decidir qué intervalo estás mirando.

Un minuto de silencio en el registro no es necesariamente un proceso congelado. Puede ser un retroceso exponencial haciendo exactamente aquello para lo que se configuró.

¿Qué etapa es realmente lenta?

Si el registro muestra intentos que fallan con un error de autenticación, ningún cambio de temporizador ayuda, porque la credencial es incorrecta. Si no se hacen intentos en absoluto, el cliente está dentro de su ventana de espera y el calendario es la solución. Si se hacen intentos y se agotan, el problema es la alcanzabilidad o un oyente ausente, y reintentar más rápido solo llena el registro. Cada uno de esos tres estados tiene un dueño distinto, y solo uno de ellos es un problema de sincronización.

Clasifica el fallo antes de tocar un número.

Cuándo ayuda bajar un temporizador y cuándo no

Baja el techo de reintentos cuando el coste dominante es la espera tras una caída breve y frecuente, como un portátil que se mueve entre puntos de acceso. Déjalo en paz cuando los fallos son largos o raros, porque reintentar con agresividad añade carga justo en el momento en que el concentrador es menos capaz de responder. En ambos casos, cambia un parámetro, regístralo y mide la siguiente recuperación en lugar de suponer que ha mejorado.

Un tiempo de espera muy bajo copiado en cada perfil es el estado final habitual del ajuste sin medición.

Comprueba la disponibilidad antes de culpar al cliente

El cliente a menudo no puede ver que la red es utilizable hasta que algo lo intenta. Un portal cautivo, una renovación de DHCP o un cambio de ruta pueden dejarlo esperando un calendario fijado antes de que ocurriera nada de eso. Observa el cambio de estado de red del sistema operativo y el siguiente intento del cliente en el mismo reloj, y verás de quién es la espera. La versión rápida es anotar la marca de tiempo del evento de red lista y la marca de tiempo del primer intento posterior.

Confirma también que el tráfico directo sigue bloqueado durante la espera, porque una reconexión más rápida que filtra tráfico no es una mejora.

Qué registrar

Anota qué temporizador cambió, de qué valor a qué valor, y cómo se vio la recuperación después. Anota también la versión del cliente, porque los valores por defecto se mueven entre versiones y un tiempo de espera muy bajo no documentado confundirá a la siguiente persona que lea el perfil.

Ese registro convierte la próxima actualización de software en una comparación en lugar de un experimento.