Клиент 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, запросите новый профиль и процедуру регистрации в том же разговоре. Не переименовывайте конфигурацию SSL и не предполагайте, что поля перенесутся: профиль IPsec называет версию IKE, удалённый шлюз и его удостоверение, метод аутентификации и селекторы трафика, которые принимает каждая сторона. Политика учётной записи и устройства тоже может применяться иначе. Переименование даёт клиент, который выглядит настроенным и ничего не согласует.

Прочитайте профиль, прежде чем ему доверять. В нём должны быть указаны версия IKE и предложения, использует ли аутентификация сертификат или заранее разделённый ключ, какие локальные и удалённые подсети выбраны и что шлюз ожидает в качестве своего удостоверения. Подтвердите, что одобренный клиент Linux поддерживает такую схему, потому что документ миграции не является заявлением о равенстве функций для каждого выпуска клиента. Независимый клиент вроде openfortivpn не является интерпретатором OpenVPN, поэтому всё остальное с SSL в названии считайте неодобренным, пока владелец не скажет иначе для этого режима, этого потока входа и этой политики устройств.

Проверка 5: локальные зависимости, затем проверьте и запишите

Когда шлюз и клиент выяснены, отказ запуска — это проблема упаковки, и собственные инструкции поддерживаемого пакета служат ориентиром. Отказ удостоверения TLS относится к оператору: якоря доверия и ожидаемое имя — это его конфигурация, а не то, что обходят локально. Это два этапа, на которых архивное руководство когда-либо было полезно.

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

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