IKEv1 amb XAuth i OTP: què demana cada camp
Una PSK de grup, un intercanvi XAuth d’usuari i un repte OTP són tres entrades diferents. Assigneu cada camp al seu propietari abans d’instal·lar un altre client.
IKEv1 amb PSK, XAuth i OTP no demana una contrasenya complicada. Superposa una clau compartida entre parells, un intercanvi d’usuari i un segon factor que el backend decideix com demanar. Cada capa té el seu propietari i el seu missatge d’error. Confondre’ls fa que la gent reescrigui un codi d’un sol ús en un camp que guarda un secret de grup.
Assigneu cada camp a la capa que el demana abans d’instal·lar un altre client o de restablir una credencial.
Tres secrets, tres propietaris
La clau prèviament compartida pertany a la relació entre parells i es configura una vegada per qui posseeix els dos extrems. La credencial d’usuari pertany al backend d’autenticació i es valida a cada inici de sessió. El segon factor pertany a un sistema de testimonis la resposta del qual canvia a cada intent. Cap substitueix l’altre, i un desplegament que els tracta com una sola contrasenya falla a la capa que ningú no va documentar.
Anoteu tres columnes: propietari, durada i el missatge d’error que produeix cada un. Aquesta taula és l’eina de diagnòstic, i els noms dels camps del client no ho són.
| 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 parell, no la persona
La clau prèviament compartida autentica la parella de passarel·les en aquesta disposició antiga, així que l’inici de sessió de l’usuari mai no la substitueix. També és el valor que més probablement és incorrecte d’una manera que produeix un error genèric de negociació en lloc d’un camp. Quan el túnel falla abans que aparegui cap camp d’usuari, els sospitosos són la clau o les propostes.
Una credencial d’usuari no pot reparar una fallada de la primera fase. Rotar-la malbarata l’única credencial que podeu rotar amb seguretat, i reforça la teoria equivocada.
XAuth: l’intercanvi d’usuari antic
XAuth afegeix un intercanvi d’autenticació d’usuari sobre l’autenticació de parell d’IKEv1, i la passarel·la decideix quin backend el valida. Segons aquest backend, l’intercanvi pot acceptar una contrasenya de directori, una credencial RADIUS o una resposta de testimoni. La paraula XAuth designa el transport de l’intercanvi, no el tipus de credencial.
Comproveu a quin backend apunta el perfil de la passarel·la. Això us diu què es demanarà a l’usuari i què canvia realment un restabliment de contrasenya, i ni una cosa ni l’altra no es veuen en un perfil de client.
OTP: el que demani el backend
Alguns desplegaments demanen un codi d’un sol ús separat després de la contrasenya, i altres defineixen un format d’entrada combinat amb un separador documentat. Tots dos existeixen, i el perfil que teniu davant decideix quin. Inventar una concatenació perquè va funcionar en un altre lloc és la manera més habitual de cremar un testimoni d’inscripció. La documentació de la mateixa passarel·la és l’única font que ho resol.
Feu servir el format documentat amb un client que pugui completar l’intercanvi que ofereix la passarel·la.
On mossega la frontera del client
Fortinet documenta que FortiClient 7.4.4 i posteriors ja no admeten IKEv1 per a VPN IPsec, cosa que és una frontera de producte i versió i no una retirada universal, com nota de compatibilitat de FortiClient recull. Els altres clients tampoc no són intercanviables: OpenConnect i openfortivpn parlen protocols de passarel·la concrets, no perfils IKEv1 arbitraris. Comproveu per separat la versió d’IKE, el mode PSK, el suport XAuth i el model d’interacció del client instal·lat. Un client que es connecta amb un mètode diferent no ha demostrat el requisit original.
IKEv1 està obsolet, així que un desplegament nou sobre un client antic no compatible és una solució de vida curta. Demaneu al propietari de la passarel·la un camí de migració compatible, incloent-hi com s’hi tractarà el segon factor.
Diagnòstic sense desactivar el factor
Separeu les etapes al registre: negociació de parells, l’intercanvi d’usuari, el resultat del segon factor i després l’assignació d’adreça i ruta. Anoteu el component i l’etapa en lloc de provar el codi a cada camp. Desactivar el factor perquè una prova passi produeix un túnel que no demostra res sobre el desplegament.
Guardeu els secrets d’inscripció i la clau compartida en emmagatzematge protegit segons el procés de l’organització. Un codi d’un sol ús en un fitxer persistent és un factor que ha deixat de ser-ho.