IKEv1 con XAuth e OTP: que pide cada campo
Unha PSK de grupo, un intercambio XAuth de usuario e un reto OTP son tres entradas distintas. Asigne cada campo ao seu propietario antes de instalar outro cliente.
IKEv1 con PSK, XAuth e OTP non pide un contrasinal complicado. Superpón unha clave compartida entre pares, un intercambio de usuario e un segundo factor que o backend decide como solicitar. Cada capa ten o seu propio dono e a súa propia mensaxe de erro. Confundilos leva a xente a reescribir un código dun só uso nun campo que garda un segredo de grupo.
Asigne cada campo á capa que o solicita antes de instalar outro cliente ou restablecer unha credencial.
Tres segredos, tres donos
A clave precompartida pertence á relación entre pares e configúraa unha vez quen posúe ambos os extremos. A credencial de usuario pertence ao backend de autenticación e valídase en cada inicio de sesión. O segundo factor pertence a un sistema de tokens cuxa resposta cambia en cada intento. Ningún substitúe a outro, e unha implantación que os trata como un só contrasinal falla na capa que ninguén documentou.
Anote tres columnas: dono, vixencia e a mensaxe de erro que produce cada un. Esa táboa é a ferramenta de diagnóstico, e os nomes de campo do cliente non o 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: o par, non a persoa
A clave precompartida autentica o par de pasarelas nesta disposición heredada, así que o inicio de sesión do usuario nunca a substitúe. Tamén é o valor que máis probablemente está mal dun xeito que produce un erro xenérico de negociación en lugar dun campo. Cando o túnel falla antes de que apareza calquera campo de usuario, os sospeitosos son a clave ou as propostas.
Unha credencial de usuario non pode reparar un fallo da primeira fase. Rotala desbaldeira a única credencial que pode rotar con seguridade e reforza a teoría equivocada.
XAuth: o intercambio de usuario herdado
XAuth engade un intercambio de autenticación de usuario sobre a autenticación de pares de IKEv1, e a pasarela decide que backend o valida. Segundo ese backend, o intercambio pode aceptar un contrasinal de directorio, unha credencial RADIUS ou unha resposta de token. A palabra XAuth nomea o transporte do intercambio, non o tipo de credencial.
Comprobe a que backend apunta o perfil da pasarela. Iso dille que se lle pedirá ao usuario e que cambia realmente un restablecemento de contrasinal, e ningún dos dous se ve nun perfil de cliente.
OTP: o que pida o backend
Algunhas implantacións piden un código dun só uso á parte despois do contrasinal, e outras definen un formato de entrada combinado cun separador documentado. Ambos existen, e o perfil que ten diante decide cal. Inventar unha concatenación porque funcionou noutro sitio é a forma máis común de queimar un token de inscrición. A documentación da propia pasarela é a única fonte que o resolve.
Use o formato documentado cun cliente que poida completar o intercambio que ofrece a pasarela.
Onde morde o límite do cliente
Fortinet documenta que FortiClient 7.4.4 e posteriores xa non admiten IKEv1 para VPN IPsec, o que é un límite de produto e versión e non unha retirada universal, como nota de compatibilidade de FortiClient rexistra. Os demais clientes tampouco son intercambiables: OpenConnect e openfortivpn falan protocolos de pasarela concretos, non perfís IKEv1 arbitrarios. Comprobe por separado a versión de IKE, o modo PSK, o soporte de XAuth e o modelo de interacción do cliente instalado. Un cliente que se conecta con outro método non demostrou o requisito orixinal.
IKEv1 está obsoleto, así que unha implantación nova sobre un cliente antigo sen soporte é unha solución de curta vida. Pida ao dono da pasarela unha ruta de migración compatible, incluída a forma en que se tratará alí o segundo factor.
Diagnosticar sen desactivar o factor
Separe as etapas no rexistro: negociación de pares, o intercambio de usuario, o resultado do segundo factor e despois a asignación de enderezo e ruta. Anote o compoñente e a etapa en lugar de probar o código en cada campo. Desactivar o factor para que pase unha proba produce un túnel que non demostra nada sobre a implantación.
Garde os segredos de inscrición e a clave compartida en almacenamento protexido segundo o proceso da organización. Un código dun só uso nun ficheiro persistente é un factor que deixou de ser.