Клиент 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 и се свържете отново веднъж. Запишете клиента, платформата, версията на шлюза и режима на тунела заедно, защото следващият човек се нуждае от четирите. Програма, която се отваря успешно, е преминала локалния етап на стартиране и нищо друго.