Сборка под ARM — это не поддержка FortiClient на вашем Raspberry Pi

Запуск VPN-клиента на Raspberry Pi — не то же самое, что поддержка FortiClient на нём. В этом разговоре сливаются три утверждения: вендор квалифицирует платформу, кто-то собирает бинарник под процессор, а шлюз разрешает протокол и регистрацию этого клиента. Найти одно из трёх ничего не говорит о двух других. Пройдите их по порядку и остановитесь на том, которое не выполняется, потому что решать нужно именно его.

Первый шаг: прочитайте строку примечаний к выпуску для своего точного пакета

Заявления о поддержке привязаны к версии, поэтому начните с примечаний к выпуску пакета, который одобряет ваша организация. Конкретный пример: таблица FortiClient Standalone 7.4.7 перечисляет Ubuntu 22.04 и 24.04, Red Hat 9 и CentOS Stream 9 с GNOME. Требование к процессору для Linux сформулировано как Intel или эквивалент.

Raspberry Pi OS не входит в перечисленные среды Linux. Это не приговор всем изданиям FortiClient и не прогноз о следующих выпусках; это утверждение о той строке в том документе. Читайте матрицу для той версии, которую действительно собираетесь разворачивать.

Не переносите заметки о процессоре из строк Windows или macOS в строку Linux. Вендоры документируют платформы по изданиям и выпускам, и заметка, верная для одной строки, не доказывает ничего о другой.

Второй шаг: выясните, что именно запускает Pi

Три команды фиксируют локальные факты до любой загрузки:

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

Первая сообщает архитектуру ядра, вторая — дистрибутив и выпуск, третья — архитектуру пользовательского пространства, под которую собираются пакеты. Ядро 64 бита с 32-битным пользовательским пространством возможно, и это меняет нужный пакет.

Затем проверьте, что реально доступно для этой платформы. Опубликованная таблица пакетов Debian trixie включает сборки arm64 и armhf для openfortivpn. Это подтверждает доступность архитектуры в данном дистрибутиве. Оно не подтверждает, что Fortinet квалифицирует FortiClient на производном дистрибутиве, и не подтверждает, что шлюз вашей организации принимает этого клиента.

Используйте поддерживаемые пакеты и актуальную документацию выпуска, а не закешированный пакет из старого выпуска или отчёт о неудачной сборке с форума. Если существует графический интерфейс, квалифицируйте его отдельно: работающая сборка из командной строки не доказывает, что редактор, хранилище секретов и надзор за обёрткой рабочего стола поддерживаются.

Третий шаг: проверьте шлюз, прежде чем винить клиент

Upstream описывает openfortivpn как клиент PPP и TLS, который запускает pppd. Это конкретная реализация, и ей нужно, чтобы шлюз предлагал совместимый режим. Название марки сервера не является соглашением о протоколе.

Соберите выпуск шлюза и включённый метод доступа, одобренное имя хоста и его материал доверия, а также процесс идентификации, который требует сервис, включая второй фактор и проверку состояния устройства. Управляемое развёртывание может требовать шагов регистрации, которые клиент третьей стороны не имеет возможности выполнить.

Попробуйте подключение с выданной вам учётной записью, а не с администраторской, потому что регистрация и политика обычно привязаны к пользователю:

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

Читайте сбой, а не только код выхода. Ошибка сертификата, тайм-аут PPP и отказ по политике — три разные проблемы, и только одна из них про ARM.

Четвёртый шаг: примите это на устройстве, в рамках договорённости

Примите настройку с реальным частным ресурсом, разрешением DNS через туннель и переподключением после обрыва сети. Затем подтвердите, что пункт назначения, который должен оставаться недоступным, всё ещё не открывается, потому что одна доступность не доказывает правильность политики.

Запишите четыре факта вместе: выпуск ОС, архитектуру пользовательского пространства, версию клиентского пакета и режим шлюза. Без всех четырёх следующий человек не скажет, поддерживается ли настройка или просто работает.

Если работодатель требует управляемую среду FortiClient, которую Pi не может обеспечить, попросите одобренную конечную точку или одобренный хост доступа. Не отключайте проверку узла, не имитируйте проверки состояния и не заменяйте шлюз организации ради одной машины. Записать нужно вывод о том, какая поддерживаемая комбинация разрешена, а не о том, что закрытое ПО никогда не сможет работать на ARM.