Fortinet Linux 客户端：先查网关再动手修

这篇归档教程教你安装 32 位库、修补 GTK 主题，并从终端运行安装程序。其中一部分建议对某个特定客户端版本确实成立，但没有一条能把网关不再提供的隧道模式找回来。在改动任何软件包之前，先找出第一个失败的环节。排查顺序是从网关向内，因为那里的答案成本最低，而错误的本地修补最费时间。

检查 1：说出失败的环节

三个环节的失败方式各不相同。程序起不来；起来了却拒绝服务器身份；或者连上了，但网关没有你需要的那类服务。每种失败都留下自己的证据：加载器报错、证书提示，或点名某个不可用模式的网关回复。

在动手之前把这些写下来。此后的一切都取决于你点出的是哪个环节，而这三种修复没有任何共同点。

检查 2：网关的发布版本与隧道模式

当前网关上已经没有隧道模式，FortiClient 7.4.4 的 Linux 集成表就是写明这一点的地方：FortiOS 7.6.3 及更高版本不再提供 SSL VPN 隧道模式，而是把管理员引向 IPsec。转述这句话时，请把产品、版本和模式一起绑在这句话上。它没有谈每一个 Fortinet 产品，也没有谈仍然存在的网页访问功能。通用版本兼容性和单一隧道模式是否可用，是两项不同的检查。

向网关所有者问两件事：网关跑的是哪个版本，今天启用了哪些访问方式。请对方以书面形式回答，并附上版本字符串以及出处（设置页面或配置行），因为恰恰是口头保证把人送回归档教程。然后拿这个答复去核对网关说明或厂商矩阵中对应那个版本的内容。能打开网页门户的浏览器只能证明门户有响应，仅此而已。

检查 3：所有者批准的客户端版本

拿到已批准的 Linux 客户端版本与版号，再核对其支持的操作系统、架构、桌面环境和认证流程。7.4.4 矩阵是与版本绑定的示例，既不是对最新客户端的推荐，也不是对每个衍生版本的承诺。要问所有者实际会支持哪个客户端，因为那个答案属于迁移工作的一部分，而不是事后补想的。客户端在第一个数据包到达网关之前就挂掉，证明的是笔记本的问题，不是服务的问题。

32 位库和打过补丁的主题改变的是二进制文件能加载什么，改变不了厂商支持什么。如果操作系统或认证流程落在矩阵之外，资格问题其实已经有答案了。

检查 4：索取替换用的配置文件

如果组织已从 SSL VPN 隧道模式迁到 IPsec，请在同一轮沟通中索取新的配置文件和注册流程。不要只是改个名字就以为字段会跟着过来：IPsec 配置会指明 IKE 版本、远端网关及其身份、认证方式，以及双方各自接受的流量选择器。账户与设备策略的执行方式也可能不同。只改名字，得到的客户端看着是配好的，却什么也协商不成。

在信任这份配置之前先读一遍。它应当写明 IKE 版本与提案、认证用的是证书还是预共享密钥、选定了哪些本地与远端子网，以及网关期望把它自己认成什么身份。还要确认已批准的 Linux 客户端支持这套安排，因为迁移文档并不等于对每个客户端版本的功能对等声明。像 openfortivpn 这样的独立客户端不是 OpenVPN 解释器，所以名字里带 SSL 的其他东西，都应视为未获批准，直到所有者针对这个模式、这个登录流程和这套设备策略另有说法。

检查 5：先看本地依赖，然后验证并记录

网关和客户端都弄清楚之后，启动失败就是打包问题，而受维护软件包自己的说明才是应当遵循的参照。TLS 身份失败属于运维方：信任锚和期望名称是他们的配置，不是在本地绕过去的事。归档教程真正有用的，也就这两个环节。

这两类问题都不是靠接受一张陌生证书或关掉设备合规检查能解决的。MFA 和设备检查要保持开启，因为靠削弱它们换回连通性，等于拿一次中断换一次安全事件。模式没了，任何本地开关都找不回来。

完成获批的改动后，访问目标私有资源，确认 DNS 解析，并重连一次。把客户端、平台、网关版本和隧道模式记在一起，因为下一个人四样都需要。程序能成功打开，只说明它过了本地启动这一关，别的什么都证明不了。