¿Es el bajo rendimiento de la VPN un problema de entropía? Normalmente no

Un rendimiento lento a través de un túnel y una máquina bloqueada esperando números aleatorios producen experiencias muy distintas, pero se archivan bajo la misma queja. Uno se manifiesta como una pausa antes de que nada funcione. El otro se manifiesta como una conexión que funciona y mueve datos despacio mientras la observa. Decidir cuál tiene lleva diez minutos y ahorra una semana de conjeturas.

Dos síntomas que se parecen

Un servicio que se cuelga tras un arranque reciente, antes de aceptar una sola conexión, espera algo. Un túnel que se establece rápido y luego transfiere a una fracción de la tasa esperada está limitado por otra cosa. La palabra cifrado aparece en ambas historias, por eso se fusionan. Sepárelos antes de tocar un archivo de configuración.

Coloque marcas de tiempo alrededor del arranque, la autenticación, la renegociación de claves y la propia transferencia. Una demora larga antes de que el túnel sea utilizable no es una tasa baja constante, y promediar ambas en un solo número destruye la evidencia.

systemd-analyze blame | head -10
journalctl -u [email protected] -o short-precise | head -40
cat /proc/sys/kernel/random/entropy_avail

Los dos primeros comandos sitúan el trabajo de arranque en una línea de tiempo. El tercero imprime el valor contable de entropía del núcleo, que es útil como un único dato e inútil como medidor de ancho de banda.

Cómo se ve realmente una espera de números aleatorios

Una solicitud de bytes aleatorios seguros puede bloquearse hasta que el núcleo haya inicializado su fuente aleatoria. Eso importa sobre todo en máquinas virtuales y placas embebidas pequeñas al principio del arranque, cuando se ha recogido poco ruido ambiental. De ahí no se sigue que cada byte cifrado consuma entropía fresca.

Los generadores modernos se siembran una vez y luego producen salida a partir de una construcción determinista, resembrando según su propio calendario. La transferencia masiva no vacía un depósito byte a byte, así que un valor bajo del depósito durante una transferencia lenta no demuestra nada sobre la causa.

strace -f -e trace=getrandom -p $(pidof openvpn) 2>&1 | head -20
dmesg | grep -i 'random\|crng'

El primer comando muestra si el proceso está detenido en una llamada de números aleatorios mientras observa. El segundo muestra los mensajes de inicialización del propio núcleo, y es ahí donde un bloqueo de arranque temprano se hace visible.

Anote la versión del núcleo y la biblioteca contra la que el servicio enlaza realmente, porque el comportamiento difiere entre implementaciones y entre versiones. Una traza tomada tras la recuperación suele perder la pausa por completo.

Cómo se ve realmente una lentitud sostenida

Un túnel que transfiere despacio todo el tiempo está limitado por la ruta de datos. Un hilo saturado, la pérdida de paquetes externos, las retransmisiones o las colas de socket llenas producen cada uno ese patrón, y cada uno tiene su propia solución. El porcentaje agregado de CPU oculta un solo hilo ocupado, que es la mala lectura más común. Mire el tiempo por hilo antes de mirar la carga total.

Mida en ambas direcciones con una base comparable y vigile los contadores de la interfaz en lugar del informe de la propia aplicación.

ss -tin dst 203.0.113.10
nstat -az | grep -i 'drop\|retrans'
ethtool -S eth0 | grep -i 'drop\|error'

El primer comando muestra el estado de cola y congestión de un par. El segundo y el tercero informan de descartes y retransmisiones en la pila y en la interfaz, que es donde la causa suele aparecer primero.

Elija la corrección para el cuello de botella que midió

Si la evidencia apunta a la inicialización de arranque temprano, mire la ruta de siembra admitida por la plataforma, que en una máquina virtual puede incluir un dispositivo aleatorio proporcionado por el anfitrión. Una imagen de semilla copiada sin cambios en muchos invitados no sustituye una inicialización independiente.

Si la evidencia apunta a la ruta de datos, ajuste lo que señalan los contadores. Los tamaños de búfer ayudan cuando las colas se desbordan y no hacen nada cuando un hilo está saturado. Instalar un demonio de entropía para subir un contador no es una reparación del rendimiento, y cambiar las suposiciones de siembra para que un gráfico se vea mejor cambia una propiedad de seguridad por un número.

Acepte el cambio solo cuando la misma medición mejore en las mismas condiciones. Un contador mayor no es un resultado; una espera medida más corta o una transferencia más rápida con una causa identificada sí lo es.