IKEv1 avec XAuth et OTP : ce que chaque champ demande
Un PSK de groupe, un échange XAuth utilisateur et un défi OTP sont trois entrées différentes. Associez chaque champ à son propriétaire avant d’installer un autre client.
IKEv1 avec PSK, XAuth et OTP ne demande pas un mot de passe compliqué. Il superpose une clé partagée entre pairs, un échange utilisateur et un second facteur dont le backend décide comment le demander. Chaque couche a son propre propriétaire et son propre message d’erreur. Les confondre amène les gens à ressaisir un code à usage unique dans un champ qui stocke un secret de groupe.
Associez chaque champ à la couche qui le demande avant d’installer un autre client ou de réinitialiser un identifiant.
Trois secrets, trois propriétaires
La clé pré-partagée appartient à la relation entre pairs et est configurée une fois par celui qui possède les deux extrémités. L’identifiant utilisateur appartient au backend d’authentification et est validé à chaque connexion. Le second facteur appartient à un système de jetons dont la réponse change à chaque tentative. Aucun ne remplace l’autre, et un déploiement qui les traite comme un seul mot de passe échoue à la couche que personne n’a documentée.
Notez trois colonnes : propriétaire, durée de vie et le message d’erreur que chacun produit. Ce tableau est l’outil de diagnostic, et les noms de champs du client ne le sont pas.
| 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 : le pair, pas la personne
La clé pré-partagée authentifie la paire de passerelles dans cette disposition héritée, donc la connexion de l’utilisateur ne la remplace jamais. C’est aussi la valeur la plus souvent erronée d’une manière qui produit une erreur de négociation générique au lieu d’un champ. Quand le tunnel échoue avant l’apparition d’un quelconque champ utilisateur, la clé ou les propositions sont les suspects.
Un identifiant utilisateur ne peut pas réparer une panne de la première phase. Le faire tourner gaspille le seul identifiant que vous pouvez faire tourner en sécurité, et renforce la mauvaise théorie.
XAuth : l’échange utilisateur hérité
XAuth ajoute un échange d’authentification utilisateur par-dessus l’authentification de pair d’IKEv1, et la passerelle décide quel backend le valide. Selon ce backend, l’échange peut accepter un mot de passe d’annuaire, un identifiant RADIUS ou une réponse de jeton. Le mot XAuth nomme le transport de l’échange, pas le type d’identifiant.
Vérifiez vers quel backend pointe le profil de la passerelle. Cela vous dit ce qui sera demandé à l’utilisateur et ce qu’une réinitialisation de mot de passe change réellement, et ni l’un ni l’autre n’est visible dans un profil client.
OTP : ce que le backend demande
Certains déploiements demandent un code à usage unique distinct après le mot de passe, et d’autres définissent un format de saisie combiné avec un séparateur documenté. Les deux existent, et le profil devant vous décide lequel. Inventer une concaténation parce qu’elle a fonctionné ailleurs est le moyen le plus courant de brûler un jeton d’enrôlement. La documentation de la passerelle elle-même est la seule source qui tranche.
Utilisez le format documenté avec un client capable de terminer l’échange que la passerelle propose.
Où la frontière du client mord
Fortinet documente que FortiClient 7.4.4 et les versions ultérieures ne prennent plus en charge IKEv1 pour les VPN IPsec, ce qui est une limite de produit et de version et non un retrait universel, comme note de compatibilité FortiClient le consigne. Les autres clients ne sont pas interchangeables non plus : OpenConnect et openfortivpn parlent des protocoles de passerelle précis, pas des profils IKEv1 arbitraires. Vérifiez séparément la version IKE, le mode PSK, la prise en charge de XAuth et le modèle d’interaction du client installé. Un client qui se connecte par une autre méthode n’a pas prouvé l’exigence d’origine.
IKEv1 est obsolète, donc un nouveau déploiement sur un vieux client non pris en charge est une solution de courte durée. Demandez au propriétaire de la passerelle un chemin de migration pris en charge, y compris la façon dont le second facteur y sera traité.
Diagnostiquer sans désactiver le facteur
Séparez les étapes dans le journal : négociation de pair, échange utilisateur, résultat du second facteur, puis attribution d’adresse et de route. Notez le composant et l’étape au lieu d’essayer le code dans chaque champ. Désactiver le facteur pour qu’un test passe produit un tunnel qui ne prouve rien sur le déploiement.
Conservez les secrets d’enrôlement et la clé partagée dans un stockage protégé selon le processus de l’organisation. Un code à usage unique dans un fichier persistant est un facteur qui a cessé d’en être un.