¿El VPN se desconecta constantemente? Sigue este orden

Antes de reinstalar el cliente, anota tres cosas: cuánto tiempo estuvo levantado el túnel, qué dijo el cliente cuando se cayó y si el equipo durmió o cambió de red mientras tanto. Esa nota es la única prueba que tendrás después, y reinstalar suele borrarla. Una caída con un intervalo repetible es un temporizador o una caducidad de estado; una caída en un momento aleatorio es un problema de ruta. El orden de abajo evita que cambies tres cosas a la vez y no aprendas nada.

Paso uno: captura el intervalo y el texto del error

Empieza por el registro del propio cliente y no por el panel del proveedor. En un cliente Linux, el registro del servicio más el estado vivo del túnel cubren la mayor parte:

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

Anota las marcas de tiempo del último handshake correcto y el momento en que se detuvo el tráfico, no solo el momento en que el icono cambió de color. Un cliente GUI que dice desconectado a posteriori puede estar informando de un estado que el núcleo alcanzó segundos antes.

Conserva la redacción del error. Un tiempo de espera agotado, un rechazo de autenticación y un error de adaptador o controlador apuntan a tres capas distintas, y la mayor parte del esfuerzo perdido en este problema viene de tratarlos como uno solo. Copia la línea literalmente en tu nota.

Paso dos: cambia una variable, no el perfil

Mantén el dispositivo y el perfil fijos y mueve la máquina a otra red de acceso, como un punto de acceso del móvil. Esta es la prueba más barata que separa al cliente de la ruta. Ejecútala el tiempo suficiente para cubrir el intervalo de fallo original; dos minutos estables no demuestran nada sobre una caída que ocurre en el minuto treinta.

Un portátil con puerto Ethernet te da una segunda comparación que saca el Wi-Fi de la ecuación por completo. Si el túnel aguanta en las dos alternativas, la red de acceso original merece la atención: itinerancia entre puntos de acceso, un router doméstico con la tabla de traducción caducada o un enlace superior que reinicia flujos largos.

Anota qué variable cambiaste. Una comparación solo cuenta cuando todo lo demás ha permanecido igual, y eso incluye el extremo del servidor y la hora del día.

Paso tres: relaciona el intervalo con una capa

La duración de una buena sesión es el número único más informativo que tienes. Léelo contra esta lista antes de tocar temporizadores:

• Caída tras suspender o reanudar: el estado del túnel sobrevivió a la suspensión pero la interfaz no. Comprueba el comportamiento de reconexión al reanudar y si el servicio reinicia el túnel o espera tráfico.
• Caída solo cuando está inactivo: algo en medio ha hecho caducar el flujo. Es justo el caso para el que existen los keepalive.
• Caída a una edad de sesión fija: un evento de reautenticación o de renovación de claves, no un fallo de ruta. Un rechazo explícito en el registro exactamente en ese intervalo es la pista.
• Caída durante transferencias grandes o páginas grandes: sospecha del MTU y la fragmentación, no de un temporizador de inactividad.

Para el caso de inactividad, los ajustes dependen del protocolo y los dos extremos importan. El keepalive 10 60 de OpenVPN en el servidor envía un ping cada 10 segundos y reinicia el enlace tras 60 segundos sin uno; los clientes de WireGuard detrás de NAT usan PersistentKeepalive = 25 en el bloque de par. OpenVPN también renegocia el canal de datos con un temporizador, reneg-sec, que por defecto son 3600 segundos en la versión 2.x.

No copies valores agresivos de la guía de otro proveedor. Un tiempo de espera corto en un enlace móvil con pérdidas produce justo las desconexiones que debía evitar, y los valores enviados por el servidor anulan lo que configures en el perfil del cliente.

Paso cuatro: compara una alternativa compatible

Si el operador publica tanto un perfil UDP como uno TCP, ejecuta el mismo dispositivo y la misma red contra el otro. Usa el archivo correspondiente real en lugar de editar el transporte en un perfil copiado. Un perfil TCP estable en una ruta donde el UDP se reinicia acota el problema a esa ruta; no demuestra que el TCP sea el mejor transporte en todas partes.

La misma lógica se aplica a los extremos. Prueba otro servidor y mantén el resultado original al lado. Si solo una salida reinicia sesiones, es una prueba sobre ese extremo, no un motivo para rehacer cada adaptador del portátil.

Después de cualquier cambio, repite el desencadenante original y confirma adónde va realmente el tráfico. Un acceso a internet recuperado no es el mismo resultado que el tráfico dentro del túnel, y un cliente que ha caído en silencio a una ruta directa parece sano desde el navegador.

Verifica la corrección y conserva la reversión

Una corrección se verifica reproduciendo el desencadenante original, no con una conexión correcta. Deja el túnel inactivo más allá del viejo intervalo de fallo, suspende y reanuda una vez, y comprueba después la edad del handshake y la dirección de salida:

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

Conserva el perfil anterior y los valores de temporizador anteriores hasta que el nuevo comportamiento sobreviva una jornada laboral completa. Si las caídas vuelven, restaura la copia de seguridad y luego vuelve a aplicar los cambios de uno en uno para que el segundo intento empiece desde un estado conocido.

Si el registro sigue limpio y el túnel aún se cae con un intervalo repetible, la siguiente parada es el lado del servidor para esa sesión. Lleva contigo el identificador de sesión del cliente y la hora exacta de la caída, porque ese par es lo que hace que un registro del servidor sea buscable. Las opciones de enlace del protocolo están documentadas en el manual de OpenVPN 2.6 cuando necesitas el significado exacto de un valor.