IKEv1 配合 XAuth 与 OTP：每个提示分别在要什么

IKEv1 同时使用 PSK、XAuth 和 OTP 时，并不是在要一个很复杂的密码。它把对等端之间的共享密钥、一次用户交换，以及由后端决定如何索取的第二因素分层叠加。每一层都有自己的归属方和自己的失败消息。把三者混为一谈，就会让人把一次性验证码重新输进用来保存组密钥的字段里。

在安装另一个客户端或重置凭据之前，先把每个提示对应到提出它的那一层。

三个秘密，三个归属方

预共享密钥属于对等端关系，由同时掌管两端的人配置一次。用户凭据属于认证后端，每次登录时校验。第二因素属于令牌系统，其响应每次尝试都会变化。三者互不替代，把三者当成同一个密码的部署，会在没人记录过的那一层出错。

写下三列：归属方、生存期，以及各自产生的失败消息。那张表才是诊断工具，客户端的字段名不是。

PSK：属于对等端，而不属于个人

在这种遗留安排里，预共享密钥用于认证网关对，所以用户的登录凭据永远替代不了它。它也是最容易以某种方式出错的值：出错时给出的是笼统的协商错误，而不是提示框。当隧道在任何用户提示出现之前就失败时，嫌疑对象就是密钥或提议。

用户凭据修不好第一阶段失败。轮换它只会浪费你唯一能安全轮换的那份凭据，还会强化错误的判断。

XAuth：遗留的用户交换

XAuth 在 IKEv1 对等端认证之上增加了一次用户认证交换，由网关决定用哪个后端来校验。视该后端而定，这次交换可能接受目录密码、RADIUS 凭据或令牌响应。XAuth 这个词命名的是交换的传输方式，不是凭据类型。

查一下网关配置指向哪个后端。这能说明用户会被要求输入什么，以及重置密码实际改变了什么，而这两点在客户端配置里都看不到。

OTP：后端要什么就给什么

有些部署会在密码之后单独索取一次性验证码，另一些则定义了带文档说明分隔符的组合输入格式。两种都存在，由你面前的配置决定用哪种。因为它在别处能行就自己发明拼接方式，是烧掉注册令牌最常见的方式。只有网关自己的文档才能定论。

用能够完成网关所提供交换的客户端，按文档记录的格式来用。

客户端边界在哪里卡住

Fortinet 说明，FortiClient 7.4.4 及之后版本不再为 IPsec VPN 支持 IKEv1，这是产品与版本层面的边界，而不是全面移除，正如 FortiClient 兼容性说明 所记录的那样。其他客户端也不可互换：OpenConnect 和 openfortivpn 说的是特定的网关协议，而不是任意的 IKEv1 配置。要逐项检查已安装客户端的 IKE 版本、PSK 模式、XAuth 支持和交互模型。用另一种方法连上的客户端，并没有证明原来的需求被满足。

IKEv1 已弃用，所以基于不再受支持的旧客户端做的新部署只是短命方案。向网关负责人要一条受支持的迁移路径，包括在那里如何处理第二因素。

在不关闭因素的前提下诊断

在日志里把各阶段分开：对等端协商、用户交换、第二因素结果，然后是地址与路由分配。记录是哪个组件、哪个阶段，而不是把验证码在每个字段里都试一遍。为了让测试通过而关闭因素，得到的隧道对这套部署什么也证明不了。

按组织的流程，把注册密钥和共享密钥放在受保护的存储里。放在长期保存文件里的一次性验证码，已经不再是第二因素。