Primero el método EAP: qué hash de contraseña puede usar una VPN
Una VPN verifica el secreto, no el hash web. Lee el método y luego comprueba qué guarda el almacén antes de prometer que las mismas contraseñas seguirán funcionando.
Muchos equipos tienen un inicio de sesión web que funciona y una VPN que rechaza cada contraseña de la misma tabla. La aplicación web compara un hash que calculó ella misma, mientras que el túnel pide al cliente que demuestre la posesión de un secreto de una forma que el servidor debe poder comprobar. Son requisitos distintos sobre el material almacenado. Es en la brecha entre ambos donde se atascan la mayoría de estos proyectos.
Primero el método, después el esquema
Anota qué prueba exige el método elegido antes de mirar cualquier esquema. Un método de desafío-respuesta necesita material del que el servidor pueda calcular la respuesta esperada, lo que en la práctica significa la contraseña o una forma derivada compatible. Un método que lleva la contraseña dentro de un túnel protegido necesita la contraseña misma en el verificador. Lee la documentación del método por el requisito del verificador y no por la configuración del cliente, porque los requisitos del cliente suelen ser la parte fácil.
Un hash con sal producido por un marco web moderno no aporta ninguna de las dos cosas. Verifica una comparación concreta y no puede revertirse al secreto del que salió.
El desafío-respuesta no puede usar un hash con sal
MSCHAPv2 es un intercambio de desafío-respuesta, así que el servidor nunca recibe la contraseña y no puede comparar una cadena almacenada. Tiene que derivar la respuesta esperada del material que ya posee, y por eso las formas almacenadas compatibles son tan estrechas. Un valor bcrypt o Argon2 con una sal por usuario es de un solo sentido de una manera que descarta el intercambio por completo. La tabla de abajo parte de la forma de almacenamiento y no del nombre del método, porque la forma de almacenamiento es lo que decide la respuesta.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
La documentación del complemento SQL para strongSwan define un esquema propio para la configuración y las credenciales, y el proyecto sigue marcando ese complemento como experimental. Nada en ella se adapta a la tabla de usuarios de una aplicación ni adivina qué esquema de hash produjo un valor almacenado. Las opciones realistas son, por tanto, migrar a un almacén que la pasarela pueda usar, o un servicio de autenticación delante del almacén existente que pueda realizar el intercambio. Cualquier otra cosa es un conector con una suposición oculta dentro.
RADIUS mueve el trabajo, no el requisito
Delegar EAP en un servidor RADIUS cambia dónde ocurre la verificación y normalmente mejora el rastro de auditoría. No recupera una contraseña de un hash de un solo sentido, así que el servicio de autenticación sigue necesitando material compatible con el método que termina. Los equipos lo descubren después de construir la ruta RADIUS y de encontrarse el mismo muro al otro lado.
Donde el servidor RADIUS puede leer un directorio con una credencial compatible, el diseño funciona y la pasarela VPN se mantiene sencilla. Donde no puede, la respuesta honesta es un cambio de alta y no otro conector. El aprovisionamiento y la revocación pertenecen a quien posee la identidad, así que una tabla copiada sin un proceso de sincronización soportado es un segundo ciclo de vida de credenciales y no un inicio de sesión único. Se desvía la primera vez que alguien restablece una contraseña en un solo lugar, y la desviación es silenciosa hasta que una cuenta que existe en ambos sistemas se comporta de forma distinta en cada uno.
Limita la cuenta que lee el directorio a esa lectura y mantenla separada de la cuenta que la pasarela usa para su propia configuración. Una cuenta administrativa compartida convierte un diseño de solo lectura en un radio de impacto mucho mayor.
Dónde debería vivir la cuenta
Una vez resuelta la cuestión del material, quedan dos arquitecturas. La pasarela puede tener un pequeño almacén de credenciales que solo ella lee, o puede delegar en un servicio de autenticación que se sitúa delante del directorio corporativo.
La primera es más fácil de razonar y peor para el usuario, que acaba con una segunda contraseña que mantener. La segunda conserva una sola identidad y añade una dependencia de un servicio que ahora tiene que estar disponible antes de que nadie pueda conectarse. Ninguna es incorrecta, pero la elección debería registrarse junto a la configuración de la pasarela, porque de lo contrario el siguiente ingeniero dará por hecho que se eligió la otra. Elijas lo que elijas, los dos comandos de abajo son los que muestran el estado actual antes de cambiarlo.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsLa autenticación de la cuenta tampoco resuelve la autorización. La pertenencia a grupos, el estado del dispositivo y el permiso de red siguen necesitando un mapeo explícito una vez que el usuario ha demostrado la identidad requerida. Una conexión que se autentica a la perfección y no autoriza nada es un resultado de política, no un fallo del método.