粘贴门户 URL 后 openfortivpn 登录为什么会失败

这个失败看起来像是凭据问题：openfortivpn 询问密码，把密码发送出去，网关却返回拒绝，或者重定向回登录页面。于是用户重新输入密码，尝试带域名的账号名，最后把浏览器里的门户 URL 粘贴到 host 字段里。正是这最后一步，把一个很小的配置错误变成了令人困惑的问题。

像 https://vpn.example.com/ext 这样的 Fortinet 门户地址同时携带多项信息，其中只有一部分属于 VPN 客户端。

端点与 realm 是两个独立的输入

openfortivpn 期望的端点是 host 或 host:port 形式，另外还需要账号，以及在部署使用 realm 时提供 realm 值。realm 告诉网关在评估账号之前要应用哪一套认证策略。它是一个独立的字段，而不是客户端从 URL 里解析出来的后缀。

对于运营方确认 realm 为 ext 的部署，非机密的调用看起来是这样的：openfortivpn vpn.example.com:443 --username=alice --realm=ext。同样的值写入配置文件的 host、port、username 和 realm 条目。两种形式都不要写密码，让客户端自己提示输入，这样密码就不会进入 shell 历史，也不会落在所有人可读的文件里。第一个客户端仍持有隧道时再次尝试，会因与 realm 毫无关系的原因失败。

openfortivpn 手册 列出了这两个选项，所以在联系支持之前很容易核对准确的拼写。但它无法告诉你网关上配置了哪个 realm。

路径段并不自动等于 realm

门户 URL 在主机名之后会收集各种各样的东西：登录应用、语言选择器、重定向目标、会话标识符。把最后一段路径截下来并称其为 realm，成功率足以带来风险。请向运营方确认配置值，或者从组织分发的配置文件中读取。

realm 也不等于用户名上的域名后缀，或者网关所在的区域。有些部署要 alice，另一些要 alice@corp，而由 realm 决定网关接受哪一种。为了弥补错误的 realm 而修改账号格式，通常只会得到第二次信息更少的拒绝。

不要通过修改 host 来修复 realm 错误

把主机名换成 IP 地址感觉像是去掉一层，但它破坏的东西比修复的多。TLS 名称校验会把证书与客户端使用的名称进行比较，而 IP 地址很少出现在证书的主题备用名称中。服务器名称指示会随地址而变化，因此在同一地址上托管多个门户的网关可能返回错误的那一个。在修正认证参数时，请保持主机名和信任配置不变。

如果证书在你的环境中不受信任，请修复信任库，或者有意识地固定预期证书。为了绕过 realm 错误而关闭校验，是用登录问题换来了静默拦截的风险。

把被拒绝的登录与失败的隧道区分开

认证失败和隧道失败发生在不同时刻，报错消息也不同。名称解析错误发生在任何 TLS 握手之前。TLS 拒绝发生在凭据发送之前。realm 或账号被拒绝会作为门户返回的 HTTP 层响应出现。只有经过这些阶段之后 PPP 协商才开始，也只有到那时才会出现 路由和 DNS 问题。

正确的 realm 既不会创造缺失的路由，也不会让不受支持的登录方式变得可用。如果门户坚持使用基于浏览器的流程，请使用客户端为这种流程支持的路径，而不是重复密码交换并指望会话能够匹配。

把值放在下次启动能找到的地方

一旦连接成功，就把网关、端口、账号和 realm 写入受管理的配置文件，而不是写进 shell 别名。放在仓库或配置管理系统里的配置文件可以防止下次启动时悄悄带入另一个配置文件的 realm。

端到端重新测试一次连接，并同时确认所应用的策略以及你真正需要的资源访问权限。认证成功只是这项检查的开始，而不是结束。