Conectar RADIUS con OpenVPN: ¿complemento o enlace de script?

El complemento todavía se recomienda en hilos anteriores a las compilaciones actuales, y falla al cargarse en un servidor compilado ayer. No es un error de configuración que se arregle con una ruta. El complemento y el enlace de script resuelven el mismo problema en capas distintas, y pasar de uno a otro cambia qué hay que instalar, qué se ejecuta con privilegios de servidor y qué le dice realmente un inicio de sesión fallido.

El mito: el complemento es la vía soportada

Un complemento es un objeto compartido cargado en el proceso de OpenVPN, así que debe coincidir con la interfaz que ese proceso expone. Las compilaciones cambian, el empaquetado cambia, y una biblioteca compilada para una interfaz anterior simplemente se niega a cargarse. Nada en la configuración del servidor puede salvar esa brecha, por eso el consejo de "solo instala radiusplugin" acaba con un servidor que no arranca.

El enlace de script queda fuera del proceso. OpenVPN ejecuta un programa, le entrega las credenciales y lee un veredicto. Ese desacoplamiento es lo que le permite sobrevivir a las actualizaciones, y también lo que lo convierte en responsabilidad suya de una forma en que el complemento nunca lo fue.

Ninguno de los dos enfoques es más seguro por construcción. Uno ejecuta código ajeno dentro del demonio; el otro ejecuta su código al lado con las credenciales en la mano. La pregunta correcta es cuál de esos dos riesgos puede operar de verdad.

Qué ataba el complemento

El complemento llevaba su propio archivo de configuración con el host RADIUS, el secreto compartido, el número de reintentos y el tiempo de espera, y la configuración del servidor lo referenciaba con una sola línea. El tratamiento de las credenciales se quedaba dentro del proceso del servidor, lo que significaba que la contraseña nunca cruzaba una frontera de proceso que el administrador tuviera que proteger.

El coste era el acoplamiento. Cada actualización de OpenVPN arriesgaba una interfaz incompatible, y cada distribución que reconstruía el paquete arriesgaba producir una biblioteca que ya no coincidía. Cuando eso ocurre, el fallo es ruidoso e inmediato, y esa es la única merced del diseño.

Si un complemento así todavía se carga en su compilación, puede ser la superficie operativa más pequeña. Confirme la interfaz para la que se compiló, manténgalo fijado a la compilación que probó y trate cualquier actualización como un cambio que exige una prueba completa de inicio de sesión, no como una actualización rutinaria del paquete.

En qué confía realmente el enlace de script

El enlace se configura con auth-user-pass-verify y un mecanismo de entrega: variables de entorno o un archivo temporal. Con la forma de entorno, OpenVPN exige script-security 3, el nivel documentado que permite exponer la contraseña a los scripts. Ese nivel es un debilitamiento deliberado del valor por defecto, y debe tratarse como un permiso con una justificación adjunta.

Todo lo que el script toca hereda esa confianza. Debe ser propiedad de root, no escribible por el grupo ni por otros, referenciado con una ruta absoluta y libre de cualquier punto donde un valor no fiable llegue a un shell. Ponga cada variable entre comillas, rechace caracteres inesperados y no construya nunca un comando a partir del nombre de usuario proporcionado. Un script que se ejecuta como root en cada intento de inicio de sesión merece una revisión precisamente por esas cuatro propiedades.

ls -l /usr/local/sbin/radius-auth.sh
stat -c '%U %a' /usr/local/sbin/radius-auth.sh

La forma de entrega por archivo evita el problema de la herencia de entorno y entrega las credenciales al script mediante un archivo temporal con permisos restringidos. Si su cliente lo admite, suele ser el mejor valor por defecto, aunque añade un objeto más que limpiar en caso de fallo.

Los códigos de salida deciden si falla abierto

El estado de salida del script es el veredicto: cero acepta, distinto de cero rechaza. El patrón que causa problemas es un script de shell que solo acepta cuando la respuesta RADIUS contiene un token de aceptación concreto y devuelve fallo para todo lo demás, porque eso funde tres sucesos distintos en una sola respuesta. Una contraseña incorrecta, un servidor inalcanzable y una respuesta malformada se convierten todos en el mismo rechazo.

Separe esos casos en el script aunque el enlace solo pueda devolver acepta o rechaza. Registre el resultado del backend por separado, alerte sobre tiempos de espera y errores de transporte, y haga evidente en la monitorización cuándo la autenticación falla porque el servicio está caído y no porque los usuarios se equivoquen al teclear.

Dos hábitos mantienen el resto sensato. Si RADIUS es la autoridad, debería ser el único lugar donde se comprueba una contraseña, porque una tabla en la sombra crea dos respuestas a la misma pregunta y la segunda es una superficie de ataque que nadie vigila. Y recuerde que el enlace se llama de nuevo en cada reintento, así que un script lento con un cliente impaciente se convierte en un amplificador para adivinar contraseñas salvo que añada retardo o una política en el lado de RADIUS.

Qué pierde cuando desaparece el certificado

Muchos despliegues de esta forma desactivan por completo la comprobación del certificado de cliente, dejando un nombre de usuario y una contraseña como toda la credencial del cliente. Lo que desaparece con ese ajuste es la identidad basada en certificado. El canal sigue cifrado, pero lo único que nombra al cliente es el veredicto de RADIUS. Cualquier elemento posterior que antes se basaba en el sujeto del certificado ahora debe basarse en el nombre de usuario.

Mantenga la protección del canal de control para que un par no autenticado no pueda sondear ni inundar el saludo, y use username-as-common-name cuando la configuración por usuario dependa del nombre común. Las pasarelas gestionadas suelen resolverlo de otra forma, terminando la autenticación de certificado en una pasarela que habla EAP-TLS con RADIUS, y en ese caso ninguna de estas directivas de servidor se aplica. Copie el modelo que documenta su propia plataforma, no el de un producto vecino. Las directivas que importan difieren lo suficiente como para que mezclarlas produzca una configuración que se analiza y luego no autentica a nadie.