OpenVPN: Parte 3 — Acceso mediante Keycloak (SSO y autenticación de dos factores)

Los certificados protegen bien el túnel, pero son inadecuados para gestionar el acceso de personas. Cuando hay decenas de empleados, hay que emitir y revocar certificados manualmente, y la persona despedida sigue conectándose hasta que su certificado se añade a la lista de revocados. Además, el certificado no tiene segundo factor: el archivo de perfil se puede copiar a cualquier dispositivo.

La solución es delegar la verificación del usuario a un sistema de inicio de sesión único. El empleado se conecta a la VPN, el cliente abre el navegador, la persona inicia sesión en la cuenta corporativa con contraseña y un código de un solo uso, y solo entonces se levanta el túnel. Si se desactiva la cuenta en un lugar, también se pierde el acceso a la VPN.

Para esto a menudo se usa Keycloak —un servidor de cuentas de código abierto. No existe un “botón Keycloak” estándar en OpenVPN. Hay dos vías reales, y dependen de la edición del servidor.

Opción 1. Access Server y SAML

OpenVPN Access Server, a partir de la versión 2.11, soporta el acceso vía SAML. Keycloak puede actuar como proveedor de identidad (IdP) mediante SAML, por lo que la integración se realiza con las herramientas de ambos productos sin código adicional. En la documentación de Access Server hay una guía específica para Keycloak.

Orden de configuración según la documentación de Access Server:

1. Proporcionar los datos del servicio a Keycloak. En Access Server existen los metadatos del Service Provider (SP): el identificador y la dirección de recepción de respuestas (ACS). En Keycloak se crea un cliente de tipo SAML: su Client ID es igual al identificador del SP, y la dirección ACS se añade a la lista de direcciones de redirección permitidas.
2. Proporcionar los datos de Keycloak al Access Server. Cada realm de Keycloak tiene una dirección de metadatos SAML del tipo https://sso.example.ru/realms/<realm>/protocol/saml/descriptor. Esa URL se indica en la configuración SAML en la interfaz web de Access Server.
3. Activar SAML para todos los usuarios o para grupos concretos.
4. Conceder acceso a los usuarios desde Keycloak.
5. Verificar el inicio de sesión: el usuario selecciona el perfil en OpenVPN Connect, el cliente abre la página de inicio de sesión de Keycloak en el navegador, y tras el inicio de sesión exitoso se levanta el túnel.

Detalle importante: al entrar vía SAML, la autenticación de dos factores integrada de Access Server (TOTP) no funciona. El segundo factor se configura en el lado de Keycloak.

La limitación para empresas rusas es la misma que se describió en la primera parte del ciclo: Access Server se vende por suscripción y no se puede pagar con una tarjeta rusa. Sin suscripción solo están disponibles dos conexiones simultáneas.

Opción 2. OpenVPN Community y openvpn-auth-oauth2

Para el OpenVPN Community existe el proyecto externo openvpn-auth-oauth2 con licencia MIT. Es un servicio separado que se conecta a la interfaz de gestión de OpenVPN y guía al usuario a través del inicio de sesión por OpenID Connect. Keycloak figura en la lista de proveedores soportados. El proyecto funciona como cliente de la interfaz de gestión o como plugin para Linux y FreeBSD.

Cómo se realiza el inicio de sesión

1. El cliente se conecta al servidor OpenVPN.
2. El servidor avisa a openvpn-auth-oauth2 de que el usuario espera verificación.
3. El servicio devuelve una dirección de inicio de sesión, el servidor se la pasa al cliente y el cliente abre el navegador.
4. El usuario inicia sesión en Keycloak; Keycloak redirige el navegador de vuelta al servicio con un código de autorización, el servicio intercambia el código por tokens.
5. El servicio autoriza o deniega la conexión, y el servidor levanta el túnel o la rechaza.

Requisitos

Según la documentación del proyecto: servidor OpenVPN no inferior a 2.6.2 (Access Server no está soportado), cliente no inferior a 2.5.0 con soporte de inicio vía navegador. Se ha comprobado que funcionan OpenVPN GUI del paquete Community 2.6 y posteriores para Windows, Tunnelblick 4 para macOS, Viscosity, y en Linux clientes basados en la librería OpenVPN 3 (3.9 y posteriores). OpenVPN Connect está soportado parcialmente, y el módulo NetworkManager para GNOME no funciona con este tipo de inicio de sesión. Esto hay que tenerlo en cuenta antes de la implantación: los clientes de los empleados deben pertenecer a la lista soportada.

Configuración de OpenVPN

En la configuración del servidor se añaden las líneas de la documentación del proyecto:

management /run/openvpn/server.sock unix /etc/openvpn/password.txt
management-client-auth
auth-user-pass-optional
auth-gen-token 28800 external-auth

• management … unix — interfaz de gestión en un socket local con la contraseña tomada del archivo;
• management-client-auth — la decisión sobre la admisión del cliente la toma un servicio externo;
• auth-user-pass-optional — el cliente no está obligado a introducir usuario y contraseña en OpenVPN;
• auth-gen-token 28800 external-auth — tras el inicio de sesión el servidor entrega al cliente un token válido 8 horas. Sin él, al cambiar las claves (por defecto una vez por hora) el usuario tendría que volver a autenticarse.

Configuración de Keycloak

En el realm correspondiente de Keycloak se crea un cliente:

• tipo — OpenID Connect, con habilitada la autenticación de cliente (Client authentication);
• en la lista de direcciones de redirección permitidas — la dirección del servicio, por ejemplo https://vpn-login.example.ru/oauth2/callback;
• en la pestaña Credentials — el secreto del cliente.

Configuración de openvpn-auth-oauth2

Archivo mínimo de configuración en formato YAML según la documentación del proyecto:

http:
  listen: ":9000"
  baseurl: "https://vpn-login.example.ru"
openvpn:
  addr: "unix:///run/openvpn/server.sock"
  password: "<contraseña del archivo /etc/openvpn/password.txt>"
oauth2:
  issuer: "https://sso.example.ru/realms/company"
  client:
    id: "openvpn"
    secret: "<secreto del cliente en Keycloak>"

baseurl — la dirección que se abrirá en el navegador del usuario. Debe ser accesible por HTTPS: algunos clientes, por ejemplo Viscosity, por defecto se niegan a abrir direcciones sin cifrado. Normalmente se coloca el servicio detrás de un proxy inverso con certificado.

Autenticación de dos factores en Keycloak

En ambas vías el segundo factor lo valida Keycloak, no OpenVPN. La opción más sencilla son los códigos de un solo uso desde una aplicación (TOTP):

1. En la configuración del realm revisar la política de contraseñas de un solo uso (algoritmo, longitud del código, periodo).
2. Para los usuarios activar la acción obligatoria «Configure OTP»: en el próximo inicio Keycloak pedirá escanear el código QR en la app autenticadora.
3. Verificar que el flujo de inicio (Authentication flow) del realm requiere OTP para los usuarios necesarios.

Así, el acceso a la VPN recibe el mismo segundo factor que otros servicios corporativos en Keycloak.

Las llaves de hardware FIDO2 como segundo factor y su funcionamiento se explican en Secretos y zero trust: Parte 4 — FIDO2 y YubiKey: hmac-secret, libfido2 y permisos de acceso.

Qué elegir

Errores típicos

• No hay auth-gen-token. Al usuario lo saca cada hora a la página de inicio de sesión.
• Dirección del servicio por HTTP. Algunos clientes no abrirán la página de inicio y la contraseña y el código viajarán por la red en texto claro.
• Clientes no compatibles. Los empleados con NetworkManager o con un cliente antiguo no podrán iniciar sesión: hay que elegir la lista de clientes comprobados con antelación.
• Se eliminaron los certificados por completo. La autorización externa verifica a la persona, y el certificado y tls-crypt siguen protegiendo el túnel en sí. No conviene prescindir de ellos.

La implantación de Keycloak y del inicio de sesión único para la VPN y otros servicios de la empresa se puede solicitar en la página «Configuración de Keycloak / SSO».