Carga del servidor VPN explicada: usuarios, CPU o enlace de subida?

Una puerta de enlace con una carga de 0.4 todavía puede arrastrarse para cada usuario que hay detrás. La carga media cuenta las tareas ejecutables o atascadas en un sueño ininterrumpible, y en un host de cuatro núcleos basta un solo proceso saturado para empujarla hacia 1.0 mientras tres núcleos están ociosos. Leer esa cifra como margen disponible es el error más común al elegir un punto final. Lo que realmente limita un túnel suele ser una de cuatro cosas: un núcleo ocupado, el enlace de subida, la cola que tiene delante o una política por sesión que nadie documentó.

La carga media cuenta tareas, no caudal

El núcleo muestrea la cola de ejecución y el número de tareas que esperan entrada y salida, y luego suaviza ambos a lo largo de uno, cinco y quince minutos. Nada en esa definición menciona bytes, paquetes ni túneles. Un host con el almacenamiento atascado puede informar de una carga alta con casi ningún tráfico, y un host que empuja un gigabit por una ruta de datos del núcleo puede informar de una carga cómoda.

Por lo tanto, correlacionar la carga con el rendimiento del túnel exige una visión por núcleo. Si un núcleo está saturado, el porcentaje agregado del panel seguirá pareciendo correcto:

cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20

El tercer comando es el que más importa en hosts VPN. El procesamiento de paquetes en espacio de usuario de OpenVPN 2.x está en gran medida serializado por proceso, así que un solo hilo ocupado puede convertirse en el techo mientras el panel informa de una gran capacidad ociosa. Si un hilo acapara la mayor parte de un núcleo durante tu periodo lento, el host no está infradimensionado en conjunto; está limitado en la dimensión que resulta ser la que importa.

Fíjate también en el momento. Las medias de quince minutos esconden el pico que arruinó una llamada, así que una captura tomada después de la queja es una prueba débil. Toma muestras durante el problema y guarda la marca de tiempo junto con la salida.

El enlace de subida y la cola que tiene delante

Los contadores de interfaz responden a la pregunta del ancho de banda que las cifras de CPU no pueden. También separan la capacidad de la pérdida, que son fallos distintos con soluciones distintas:

ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit

Un enlace que durante tu prueba está cerca de su velocidad asignada es la explicación, y ninguna cantidad de CPU libre lo cambia. La línea de qdisc añade el detalle que importa para el tráfico interactivo: la acumulación y las pérdidas te dicen si los paquetes esperan en una cola antes de salir. Una cola que se llena bajo una subida masiva produce exactamente el síntoma que la gente atribuye al servidor remoto, llamadas lentas en una conexión que aún da buenos resultados en las pruebas.

Los contadores de retransmisión capturan el caso en que los paquetes salen pero nunca llegan limpios. Si las retransmisiones suben durante la ventana lenta y la interfaz está muy lejos de su capacidad, el problema está en la ruta y no en el host, y cambiar a otro punto final de la misma ciudad no ayudará.

Los recuentos de sesión describen la demanda, no el margen

Cada directorio público muestra un número de usuarios conectados, y casi ninguno te dice qué hacen esos usuarios. Veinte sesiones con trabajo interactivo y cuatro sesiones descargando archivos grandes producen cargas muy distintas en el mismo hardware. El segundo patrón es invisible en un recuento de usuarios, y es el que arruina una tarde. Así que un número de sesiones se lee mejor como una pista sobre la demanda, nunca como una afirmación sobre la capacidad libre.

En un host que controlas, el archivo de estado da la dimensión que falta. OpenVPN escribe una instantánea periódica que incluye contadores de bytes por cliente, lo que basta para ver si una sola sesión es responsable de todo el enlace de subida:

status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.status

Dos muestras separadas diez segundos convierten esos contadores acumulados en una tasa por cliente. Esa es la medición que suple un recuento de usuarios, y también es cómo descubres que un solo cliente mal configurado satura el enlace cada noche a la misma hora.

Los límites por sesión se esconden en la política

Un servidor puede estar ocioso y aun así negarte ancho de banda. Los límites de tasa, los topes de ancho de banda por cliente y la modelación de tráfico suelen aplicarse por nombre común o por grupo, así que dos usuarios en la misma puerta de enlace pueden obtener resultados muy distintos. El mecanismo no es sutil, pero es invisible desde fuera porque el túnel se levanta con normalidad en ambos casos.

Busca la modelación en la interfaz del túnel y no en la física. Comprueba si el límite sigue al usuario, al certificado o al grupo de direcciones. Si tu cuenta de prueba cae en el grupo sin tope, concluirás que el servidor está bien y que el usuario que se queja se equivoca. Esa conclusión es peor que ninguna, porque cierra el ticket.

Compara dos puntos finales con una misma tarea fija

El experimento del lado del cliente todavía merece la pena, pero solo si las variables están fijadas. Usa el mismo dispositivo, la misma red de acceso, el mismo protocolo y el mismo archivo de destino, y luego repite contra un segundo punto final a una distancia similar. Cualquier cosa que cambie entre ejecuciones, incluida la hora del día, contamina el resultado.

Registra los fallos con tanto cuidado como los éxitos. Una serie en la que tres puntos finales funcionan y uno se agota por tiempo es más informativa que cuatro cifras de velocidad, porque apunta a un problema de ruta o de política y no de capacidad. Ejecuta cada caso al menos dos veces; una sola muestra lenta no demuestra nada en una red compartida.

Por último, guarda las cifras que reuniste junto a la afirmación que respaldan. "Este punto final completó la transferencia en la misma ventana en la que el otro se atascó" es defendible, mientras que "este punto final es más rápido" invita a una discusión que no puedes ganar con una puntuación de portada. El manual de OpenVPN 2.6 documenta el archivo de estado y las opciones de modelación si necesitas las directivas exactas del lado del host.