Conectar RADIUS con OpenVPN: complemento ou enlace de script?

O complemento aínda se recomenda en fíos anteriores ás compilacións actuais, e falla ao cargarse nun servidor compilado onte. Non é un erro de configuración que se arranxe cunha ruta. O complemento e o enlace de script resolven o mesmo problema en capas distintas, e pasar dun a outro cambia que hai que instalar, que se executa con privilexios de servidor e que lle di realmente un inicio de sesión fallido.

O mito: o complemento é a vía soportada

Un complemento é un obxecto compartido cargado no proceso de OpenVPN, así que debe coincidir coa interface que ese proceso expón. As compilacións cambian, o empaquetado cambia, e unha biblioteca compilada para unha interface anterior simplemente négase a cargarse. Nada na configuración do servidor pode salvar esa fenda, por iso o consello de "só instala radiusplugin" acaba cun servidor que non arrinca.

O enlace de script queda fóra do proceso. OpenVPN executa un programa, entrégalle as credenciais e le un veredicto. Ese desacoplamento é o que lle permite sobrevivir ás actualizacións, e tamén o que o converte en responsabilidade súa dun xeito en que o complemento nunca o foi.

Ningunha das dúas enfoques é máis segura por construción. Unha executa código alleo dentro do daemon; a outra executa o seu código ao lado coas credenciais na man. A pregunta correcta é cal deses dous riscos pode operar de verdade.

Que ataba o complemento

O complemento levaba o seu propio ficheiro de configuración co host RADIUS, o segredo compartido, o número de reintentos e o tempo de espera, e a configuración do servidor referenciábao cunha soa liña. O tratamento das credenciais quedaba dentro do proceso do servidor, o que significaba que o contrasinal nunca cruzaba unha fronteira de proceso que o administrador tivese que protexer.

O custo era o acoplamento. Cada actualización de OpenVPN arriscaba unha interface incompatible, e cada distribución que reconstruía o paquete arriscaba producir unha biblioteca que xa non coincidía. Cando iso ocorre, o fallo é ruidoso e inmediato, e esa é a única mercede do deseño.

Se un complemento así aínda se carga na súa compilación, pode ser a superficie operativa máis pequena. Confirme a interface para a que se compilou, mantéñao fixado á compilación que probou e trate calquera actualización como un cambio que esixe unha proba completa de inicio de sesión, non como unha actualización rutineira do paquete.

En que confía realmente o enlace de script

O enlace configúrase con auth-user-pass-verify e un mecanismo de entrega: variables de contorno ou un ficheiro temporal. Coa forma de contorno, OpenVPN esixe script-security 3, o nivel documentado que permite expor o contrasinal aos scripts. Ese nivel é un debilitamento deliberado do valor por defecto, e debe tratarse como un permiso cunha xustificación anexa.

Todo o que o script toca herda esa confianza. Debe ser propiedade de root, non escribible polo grupo nin por outros, referenciado cunha ruta absoluta e libre de calquera punto onde un valor non fiable chegue a un shell. Pon cada variable entre comiñas, rexeita caracteres inesperados e non constrúas nunca un comando a partir do nome de usuario fornecido. Un script que se executa como root en cada intento de inicio de sesión merece unha revisión precisamente por esas catro propiedades.

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

A forma de entrega por ficheiro evita o problema da herdanza de contorno e entrega as credenciais ao script mediante un ficheiro temporal con permisos restrinxidos. Se o seu cliente o admite, adoita ser o mellor valor por defecto, aínda que engade un obxecto máis que limpar en caso de fallo.

Os códigos de saída deciden se falla aberto

O estado de saída do script é o veredicto: cero acepta, distinto de cero rexeita. O patrón que causa problemas é un script de shell que só acepta cando a resposta RADIUS contén un token de aceptación concreto e devolve fallo para todo o demais, porque iso funde tres sucesos distintos nunha soa resposta. Un contrasinal incorrecto, un servidor inalcanzable e unha resposta malformada convértense todos no mesmo rexeitamento.

Separe eses casos no script aínda que o enlace só poida devolver acepta ou rexeita. Rexistre o resultado do backend por separado, alerte sobre tempos de espera e erros de transporte, e faga evidente na monitorización cando a autenticación falla porque o servizo está caído e non porque os usuarios se equivoquen ao teclear.

Dous hábitos manteñen o resto sensato. Se RADIUS é a autoridade, debería ser o único lugar onde se comproba un contrasinal, porque unha táboa na sombra crea dúas respostas á mesma pregunta e a segunda é unha superficie de ataque que ninguén vixía. E lembre que o enlace se chama de novo en cada reintento, así que un script lento cun cliente impaciente convértese nun amplificador para adiviñar contrasinais salvo que engada atraso ou unha política no lado de RADIUS.

Que perde cando desaparece o certificado

Moitos despregamentos desta forma desactivan por completo a comprobación do certificado de cliente, deixando un nome de usuario e un contrasinal como toda a credencial do cliente. O que desaparece con ese axuste é a identidade baseada en certificado. A canle segue cifrada, pero o único que nomea o cliente é o veredicto de RADIUS. Calquera elemento posterior que antes se baseaba no suxeito do certificado agora debe basearse no nome de usuario.

Manteña a protección da canle de control para que un par non autenticado non poida sondar nin inundar o saúdo, e use username-as-common-name cando a configuración por usuario dependa do nome común. As pasarelas xestionadas adoitan resolvelo doutro xeito, terminando a autenticación de certificado nunha pasarela que fala EAP-TLS con RADIUS, e nese caso non se aplica ningunha destas directivas de servidor. Copie o modelo que documenta a súa propia plataforma, non o dun produto veciño. As directivas que importan difiren o suficiente como para que mesturalas produza unha configuración que se analiza e logo non autentica a ninguén.