Клієнт Fortinet для Linux: перевірте шлюз перед ремонтом
Архівний посібник із 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 і один раз перепідключіться. Запишіть клієнт, платформу, випуск шлюзу і режим тунелю разом, бо наступній людині потрібні всі чотири. Програма, яка успішно відкривається, пройшла локальний етап запуску, і більше нічого.