AES-NI en OpenSSL frente a la descarga en el kernel: ¿cuál necesita?

Se usan dos etiquetas como si fueran lo mismo: acelerado por hardware y descargado en el kernel. Una describe qué instrucciones ejecuta la rutina AES de una biblioteca y la otra describe dónde ocurre el procesamiento de paquetes. Una VPN puede tener la primera sin la segunda, la segunda sin la primera o ambas a la vez. Cualquier decisión sobre rendimiento debe empezar por nombrar cuál de las dos está cambiando en realidad.

Dos ejes, no una puntuación

El primer eje es la implementación: el código que hace AES-256-GCM se dirige a una versión que usa las instrucciones dedicadas del procesador o a una rutina portátil que las ejecuta como aritmética corriente. Esa elección vive dentro de la biblioteca criptográfica y se toma al inicializarse.

El segundo eje es la ubicación: el paquete recorre la ruta de transformación del kernel o un demonio en el espacio de usuario lee de un dispositivo de túnel, cifra y vuelve a escribir.

Ningún eje limita al otro. Una VPN en espacio de usuario sobre una CPU con instrucciones AES puede usarlas todo el tiempo, y una ruta en el kernel sobre una CPU sin ellas recurre a una implementación de software. Las etiquetas del material de proveedores rara vez marcan esa distinción, y por eso los consejos de ajuste copiados entre ambas situaciones tantas veces no hacen nada.

Eje uno: qué código hace el cifrado

OpenSSL detecta características del procesador durante la inicialización y usa el resultado para elegir rutas de código optimizadas, como describe la documentación de capacidades x86. AES-NI es una de las capacidades documentadas detrás de ese despacho. Nada de esto exige que la biblioteca se convierta en un componente del kernel.

Confirme que la característica es visible para el proceso antes de suponer que se usa la ruta rápida. En Linux la fuente es el campo flags de /proc/cpuinfo, y dentro de un invitado refleja lo que expone el hipervisor y no el nombre del modelo del host físico.

grep -m1 '^flags' /proc/cpuinfo | grep -o '\baes\b'
openssl list -providers -verbose

El segundo comando nombra los proveedores cargados en esa compilación. No le dice qué biblioteca enlazó el servicio VPN, y un host puede llevar dos instalaciones de OpenSSL mientras el proceso en ejecución usa solo una.

Eje dos: dónde corre la ruta de paquetes

Ubicar en el kernel significa que la transformación ocurre en la maquinaria IPsec del propio kernel o dentro de un controlador de túnel en el kernel, así que los paquetes no necesitan un viaje de ida y vuelta por un proceso de usuario para cada lote. Eso puede recortar copias y cambios de contexto, y repartir el trabajo entre núcleos como no puede un demonio de un solo hilo. También mueve los contadores y trazas que leerá cuando caiga el caudal, porque el trabajo ocurre ahora al otro lado de una frontera que no controla. Considérelo un coste de depuración, no solo una decisión de rendimiento.

No crea soporte de instrucciones, no configura un cifrado ni hace que funcione una ruta existente.

La virtualización añade un pliegue también en este eje. A un invitado puede dársele un modelo de CPU enmascarado que oculta características que el host tiene, y un invitado anidado puede ver aún menos. Lea la vista de capacidades desde dentro del entorno donde la VPN corre de verdad, no desde la consola del hipervisor.

Qué compra cada opción y qué no puede

La pregunta práctica es adónde va el tiempo. Si un solo hilo ocupado, copias repetidas del búfer o una llamada al sistema por paquete limitan el caudal, mover la transformación a una ruta que elimina esos costes puede ayudar, siempre que el kernel implemente la transformación que necesita.

Si el límite es un enlace ascendente congestionado, una ruta con pérdidas, un tiempo de ida y vuelta largo, un servicio de destino saturado o un hilo fijado a un núcleo, la ubicación no cambia nada importante. Lo mismo vale para la elección de instrucciones: AES sobre hardware dedicado no repara una ruta ausente y no ayudará si el túnel está inactivo porque falla la resolución de nombres.

Donde aplican ambas, se combinan. Una ruta en el kernel puede usar el mismo despacho a nivel de instrucción dentro de la API criptográfica del kernel, y una ruta en espacio de usuario con una biblioteca bien elegida ya lo usa. La decisión no es cuál es más rápida en abstracto; es para qué coste tiene pruebas.

Anote los cuatro hechos antes de cambiar nada

Escriba el binario del servicio y la biblioteca criptográfica a la que enlaza, porque esos deciden el eje uno. Luego anote la protección de datos negociada, porque un cifrado sin ruta de instrucciones dedicada se comporta distinto de uno con ella, y el conjunto lo eligen ambas partes.

Después, la vista de capacidades desde dentro del entorno en ejecución y, por último, la ruta de paquetes activa con pruebas de que el modo que cree habilitado lo está de verdad. Un módulo cargado no prueba que un perfil lo use, y una línea de configuración no prueba que el kernel la haya aceptado.

Cambie una cosa y compare con una carga de trabajo constante con los mismos extremos y la misma dirección de transferencia. Una afirmación de velocidad que no midió vale menos que una nota que diga que el backend nunca estuvo en duda.