El VPN se cae en las subidas grandes: lee primero la cola

El túnel es estable todo el día y luego se cae cada vez que empieza una subida grande. Las peticiones interactivas se atascan primero, el cliente informa de un tiempo de espera agotado y la conexión vuelve cuando termina la transferencia. Ese patrón apunta a la cola y al procesamiento, no a que el servidor remoto esté caído, porque al servidor nunca se le dio la oportunidad de responder a tiempo. El trabajo es reproducirlo bajo una carga controlada y leer los contadores correctos.

Cambia una variable por ejecución y mantén fijo el extremo.

Construye una comparación de carga repetible

Registra una línea base con el enlace en reposo: tiempo de ida y vuelta, unas cuantas peticiones de aplicaciones y el registro de eventos del propio túnel. Luego inicia una subida de tamaño conocido y repite exactamente esas mediciones mientras corre. Mantén sin cambios el extremo, el cliente y el destino de la prueba, porque cambiar dos de ellos a la vez no te dice nada.

Fíjate en qué evento aparece primero. Un tiempo de ida y vuelta creciente antes de cualquier error sugiere cola; un tiempo de espera agotado y contundente con latencia estable sugiere otra cosa, como una rotación de claves o una acción en la cuenta. Los dos patrones llevan a siguientes pasos distintos. Anota la observación antes de cambiar nada.

Guarda la salida con marcas de tiempo para que las ejecuciones con carga y en reposo se puedan comparar línea por línea.

Lee la cola, no la velocidad

Los enlaces de consumidor almacenan paquetes en el equipo del proveedor, y una cola de subida llena retrasa todo, incluidos los pequeños paquetes de control que mantienen vivo el túnel. Una prueba de velocidad que da una cifra alta dice poco sobre ese retraso, y por eso una prueba en reposo pasa mientras un enlace saturado falla.

ping -c 20 -i 0.2 203.0.113.10
mtr -rwc 20 203.0.113.10
tc -s qdisc show dev eth0
ss -ti dst 203.0.113.10
nstat -az | grep -E 'Retrans|Timeout'

Compara las cifras de latencia con carga con las del reposo. Un salto de decenas de milisegundos a cientos, sin pérdida de paquetes, es cola; la pérdida con latencia estable apunta a otra avería.

Revisa el dispositivo y la ruta de control

El cifrado y el reenvío cuestan tiempo de procesador, y un router pequeño o un portátil limitado térmicamente puede descartar paquetes mientras está ocupado. Vigila la carga global y no el porcentaje de un proceso, porque el reenvío en el núcleo y el manejo de interrupciones no aparecen donde la gente suele mirar.

uptime
mpstat -P ALL 1 3
dmesg | grep -i -E 'thermal|throttl'
journalctl -u openvpn-server@server --since '10 min ago' | tail -20

Un tiempo de espera del cliente también puede coincidir con una rotación de claves programada o con un evento de política de sesión. Lee el registro del propio cliente para ver el orden de los eventos, no solo el mensaje de error de la aplicación.

Cambia una cosa y repite

Donde la plataforma lo permita, limita la tasa de subida o clasifica el tráfico masivo por debajo del interactivo para que la cola nunca se llene. Luego repite la misma carga de trabajo y compara las mismas tres cifras que antes. Un cambio que mejora una prueba de velocidad pero deja el tiempo de espera no ha arreglado nada.

Subir los tiempos de espera en general y debilitar el cifrado son los dos cambios que hacen desaparecer el síntoma sin identificar qué límite falló. Ninguno de los dos es una reparación. Ambos trasladan el fallo más adelante, donde es más difícil atribuirlo.

Termina probando una petición nueva y el comportamiento de reconexión del que el usuario depende de verdad. La estabilidad bajo la carga que provocó la queja es el único resultado que merece registrarse.