ARM 构建不等于为树莓派提供 FortiClient 支持

在树莓派上运行 VPN 客户端，和在树莓派上获得 FortiClient 支持是两件事。这段讨论里混着三个主张：厂商认定某个平台合格、有人为处理器编译了二进制文件、网关允许该客户端的协议并接受注册。找到其中一条，并不说明另外两条。按这个顺序逐一核对，哪一步不成立就停在哪一步，因为那才是必须解决的问题。

第一步：查你自己那个包对应的发布说明行

支持范围与版本绑定，所以先看组织批准的那个包的发布说明。举个具体例子：FortiClient Standalone 7.4.7 的表格列出 Ubuntu 22.04 与 24.04、带 GNOME 的 Red Hat 9 与 CentOS Stream 9。它对 Linux 处理器的要求写的是 Intel 或同等。

Raspberry Pi OS 不在这些列出的 Linux 环境里。这不是对所有 FortiClient 版本的判决，也不是对后续版本的预言；它只是关于那份文档中那一行的陈述。要读的是你真正打算部署的那个版本的矩阵。

不要把 Windows 或 macOS 行里的处理器说明搬到 Linux 行。厂商按版本、按发行分别记录平台，适用于一行的说明不能当另一行的证据。

第二步：确认 Pi 实际在跑什么

下载之前，三条命令就能把本地事实定下来：

uname -m
cat /etc/os-release
dpkg --print-architecture

第一条给出内核架构，第二条给出发行版与版本，第三条给出软件包所针对的用户空间架构。64 位内核配 32 位用户空间是可能的，这会改变你需要哪个包。

然后查该平台实际有哪些可用的东西。Debian trixie 公布的软件包表里有 openfortivpn 的 arm64 与 armhf 构建。这只证明该发行版中存在该架构。它不能证明 Fortinet 认可衍生发行版上的 FortiClient，也不能证明你所在组织的网关接受这个客户端。

用受支持的软件包和当前版本的文档，而不是旧版本留下的缓存包或论坛帖里的编译失败报告。如果存在图形前端，要单独认定：命令行构建能跑，并不证明编辑器、密钥存储和桌面封装层的维护仍在继续。

第三步：先查网关，再怪客户端

Upstream 把 openfortivpn 描述成会启动 pppd 的 PPP 与 TLS 客户端。这是特定实现，需要网关提供兼容模式。服务器品牌名不是协议约定。

把网关版本与已启用的接入方式、获准的主机名及其信任材料、服务要求的身份流程收集起来，包括任何第二因素与设备状态检查。受管部署可能要求第三方客户端根本无法完成的注册步骤。

用发给你的账号试连接，不要用管理员的账号，因为注册与策略通常绑在用户身上：

sudo openfortivpn vpn.example.com:443 -u <username>

要看失败的具体内容，而不只是退出码。证书错误、PPP 超时、策略拒绝是三个不同的问题，只有一个跟 ARM 有关。

第四步：在设备上、在协议范围内验收

用真实的私有资源、经隧道完成的 DNS 解析，以及断网后的重连来验收。然后再确认一个本该不通的目标依然不通，因为只有可达性并不能证明策略是对的。

把四个事实一起记下来：操作系统版本、用户空间架构、客户端软件包版本、网关模式。缺了任何一项，下一个人就说不清这套配置是受支持，还是只是碰巧能用。

如果雇主需要 Pi 无法满足的受管 FortiClient 环境，就申请获批的终端或获批的接入主机。不要关闭对端校验、不要模仿状态检查、也不要为了一台机器去替换组织的网关。要写下的结论是哪种受支持的组合获得授权，而不是闭源软件永远不能面向 ARM。