IKEv1 con XAuth y OTP: qué pide cada campo
Una PSK de grupo, un intercambio XAuth de usuario y un desafío OTP son tres entradas distintas. Asigne cada campo a su propietario antes de instalar otro cliente.
IKEv1 con PSK, XAuth y OTP no pide una contraseña complicada. Superpone una clave compartida entre pares, un intercambio de usuario y un segundo factor que el backend decide cómo solicitar. Cada capa tiene su propio dueño y su propio mensaje de error. Confundirlos lleva a la gente a reescribir un código de un solo uso en un campo que guarda un secreto de grupo.
Asigne cada campo a la capa que lo solicita antes de instalar otro cliente o restablecer una credencial.
Tres secretos, tres dueños
La clave precompartida pertenece a la relación entre pares y la configura una vez quien posee ambos extremos. La credencial de usuario pertenece al backend de autenticación y se valida en cada inicio de sesión. El segundo factor pertenece a un sistema de tokens cuya respuesta cambia en cada intento. Ninguno sustituye a otro, y un despliegue que los trata como una sola contraseña falla en la capa que nadie documentó.
Anote tres columnas: dueño, vigencia y el mensaje de error que produce cada uno. Esa tabla es la herramienta de diagnóstico, y los nombres de campo del cliente no lo son.
| Layer | Owner | Lifetime |
|---|---|---|
| Pre-shared key | Peer configuration | Until operators change it |
| XAuth credential | Authentication backend | Per session, per policy |
| One-time code | Token system | Single use |
PSK: el par, no la persona
La clave precompartida autentica el par de puertas de enlace en esta disposición heredada, así que el inicio de sesión del usuario nunca la reemplaza. También es el valor que más probablemente está mal de una forma que produce un error genérico de negociación en lugar de un campo. Cuando el túnel falla antes de que aparezca cualquier campo de usuario, los sospechosos son la clave o las propuestas.
Una credencial de usuario no puede reparar un fallo de la primera fase. Rotarla desperdicia la única credencial que puede rotar con seguridad y refuerza la teoría equivocada.
XAuth: el intercambio de usuario heredado
XAuth añade un intercambio de autenticación de usuario sobre la autenticación de pares de IKEv1, y la puerta de enlace decide qué backend lo valida. Según ese backend, el intercambio puede aceptar una contraseña de directorio, una credencial RADIUS o una respuesta de token. La palabra XAuth nombra el transporte del intercambio, no el tipo de credencial.
Compruebe a qué backend apunta el perfil de la puerta de enlace. Eso le dice qué se le pedirá al usuario y qué cambia realmente un restablecimiento de contraseña, y ninguno de los dos se ve en un perfil de cliente.
OTP: lo que pida el backend
Algunos despliegues piden un código de un solo uso aparte después de la contraseña, y otros definen un formato de entrada combinado con un separador documentado. Ambos existen, y el perfil que tiene delante decide cuál. Inventar una concatenación porque funcionó en otro sitio es la forma más común de quemar un token de inscripción. La documentación de la propia puerta de enlace es la única fuente que lo resuelve.
Use el formato documentado con un cliente que pueda completar el intercambio que ofrece la puerta de enlace.
Dónde muerde el límite del cliente
Fortinet documenta que FortiClient 7.4.4 y posteriores ya no admiten IKEv1 para VPN IPsec, lo que es un límite de producto y versión y no una retirada universal, como nota de compatibilidad de FortiClient registra. Los demás clientes tampoco son intercambiables: OpenConnect y openfortivpn hablan protocolos de puerta de enlace concretos, no perfiles IKEv1 arbitrarios. Compruebe por separado la versión de IKE, el modo PSK, el soporte de XAuth y el modelo de interacción del cliente instalado. Un cliente que se conecta con otro método no ha demostrado el requisito original.
IKEv1 está obsoleto, así que un despliegue nuevo sobre un cliente antiguo sin soporte es una solución de corta vida. Pida al dueño de la puerta de enlace una ruta de migración compatible, incluida la forma en que se tratará allí el segundo factor.
Diagnosticar sin desactivar el factor
Separe las etapas en el registro: negociación de pares, el intercambio de usuario, el resultado del segundo factor y luego la asignación de dirección y ruta. Anote el componente y la etapa en lugar de probar el código en cada campo. Desactivar el factor para que pase una prueba produce un túnel que no demuestra nada sobre el despliegue.
Guarde los secretos de inscripción y la clave compartida en almacenamiento protegido según el proceso de la organización. Un código de un solo uso en un archivo persistente es un factor que ha dejado de serlo.