Klient Fortinet dla Linuksa: sprawdź bramę przed naprawą

Zarchiwizowany poradnik każe zainstalować 32-bitowe biblioteki, załatać motyw GTK i uruchomić instalator z terminala. Część tej rady była słuszna dla konkretnego wydania klienta, a nic z niej nie przywróci trybu tunelowego, którego brama już nie oferuje. Zanim zmienisz pakiet, znajdź pierwszy etap, który zawiódł. To idzie od bramy do wewnątrz, bo tam odpowiedzi są tanie, a błędna lokalna naprawa kosztuje najwięcej czasu.

Sprawdzenie 1: nazwij etap, który zawiódł

Trzy etapy zawodzą w różny sposób. Program się nie uruchamia, uruchamia się i odrzuca tożsamość serwera, albo łączy się, a brama nie ma usługi tego rodzaju, którego potrzebujesz. Każde niepowodzenie zostawia własny dowód: błąd loadera, komunikat o certyfikacie, odpowiedź bramy wskazującą niedostępny tryb.

Zapisz to, zanim czegokolwiek dotkniesz. Wszystko po tym punkcie zależy od tego, który etap nazwałeś, a trzy naprawy nie mają nic wspólnego.

Sprawdzenie 2: wydanie bramy i tryb tunelowy

Tryb tunelowy zniknął z obecnych bram, a tabela integracji FortiClient 7.4.4 z Linuksem jest miejscem, gdzie to zapisano: FortiOS 7.6.3 i nowsze nie oferują już trybu tunelowego SSL VPN i kierują administratorów do IPsec. Trzymaj produkt, wydanie i tryb przypisane do tego zdania, gdy je powtarzasz. Nie mówi ono nic o każdym produkcie Fortinet ani nic o funkcjach dostępu webowego, które nadal istnieją. Ogólna zgodność wersji i dostępność jednego trybu tunelowego to osobne sprawdzenia.

Zapytaj właściciela bramy o dwie rzeczy: jakie wydanie działa na bramie i jakie metody dostępu są dziś włączone. Poproś o odpowiedź na piśmie, wraz z ciągiem wydania i stroną ustawień lub wierszem konfiguracji, z którego pochodzi, bo to właśnie ustne zapewnienie odsyła ludzi do zarchiwizowanego poradnika. Następnie sprawdź tę odpowiedź z notatkami bramy lub matrycą dostawcy dla dokładnie tego wydania. Przeglądarka wyświetlająca portal webowy dowodzi, że portal odpowiada, i nic więcej.

Sprawdzenie 3: edycja klienta, którą zatwierdza właściciel

Uzyskaj zatwierdzoną edycję i wersję klienta Linuksa, a następnie sprawdź obsługiwany system operacyjny, architekturę, pulpit i przepływ uwierzytelniania. Matryca 7.4.4 to przykład związany z wersją, nie zalecenie dla najnowszego klienta i nie obietnica dla każdego pochodnego. Zapytaj, którego klienta właściciel naprawdę będzie wspierać, bo ta odpowiedź jest częścią migracji, a nie późniejszą myślą. Klient, który umiera, zanim jego pierwszy pakiet dotrze do bramy, dowodzi czegoś o laptopie, a nie o usłudze.

32-bitowe biblioteki i załatany motyw zmieniają to, co może wczytać plik binarny; nie zmieniają tego, co wspiera dostawca. Jeśli system operacyjny lub przepływ uwierzytelniania jest poza matrycą, pytanie o kwalifikację jest już rozstrzygnięte.

Sprawdzenie 4: poproś o profil zastępczy

Jeśli organizacja przeszła z trybu tunelowego SSL VPN na IPsec, poproś o nowy profil i procedurę rejestracji w tej samej rozmowie. Nie zmieniaj nazwy konfiguracji SSL i nie zakładaj, że pola się przeniosą: profil IPsec wskazuje wersję IKE, zdalną bramę i jej tożsamość, metodę uwierzytelniania oraz selektory ruchu akceptowane przez każdą stronę. Polityka konta i urządzenia też może być egzekwowana inaczej. Zmiana nazwy daje klienta, który wygląda na skonfigurowanego i niczego nie negocjuje.

Przeczytaj profil, zanim mu zaufasz. Powinien podawać wersję IKE i propozycje, czy uwierzytelnianie używa certyfikatu czy klucza współdzielonego, które podsieci lokalne i zdalne są wybrane oraz czego brama oczekuje jako swojej tożsamości. Potwierdź, że zatwierdzony klient Linuksa obsługuje taki układ, bo dokument migracji nie jest deklaracją równości funkcji dla każdego wydania klienta. Niezależny klient, taki jak openfortivpn, nie jest interpreterem OpenVPN, więc wszystko inne z SSL w nazwie traktuj jako niezatwierdzone, dopóki właściciel nie powie inaczej dla tego trybu, tego przepływu logowania i tej polityki urządzeń.

Sprawdzenie 5: zależności lokalne, potem weryfikacja i zapis

Gdy brama i klient są ustalone, niepowodzenie uruchomienia jest problemem pakowania, a własne instrukcje utrzymywanego pakietu są punktem odniesienia, którego należy przestrzegać. Niepowodzenie tożsamości TLS należy do operatora: kotwice zaufania i oczekiwana nazwa to jego konfiguracja, a nie coś, co omija się lokalnie. To dwa etapy, w których zarchiwizowany poradnik był kiedykolwiek przydatny.

Żadnego z nich nie rozwiązuje zaakceptowanie nieznanego certyfikatu ani wyłączenie sprawdzania postury. Zachowaj kontrole MFA i urządzenia, bo przywracanie łączności przez ich osłabienie zamienia awarię na incydent. Jeśli tryb zniknął, żadna lokalna flaga go nie przywróci.

Po zatwierdzonej zmianie dotrzyj do zamierzonego zasobu prywatnego, potwierdź rozwiązywanie DNS i połącz się ponownie raz. Zapisuj klienta, platformę, wydanie bramy i tryb tunelowy razem, bo następna osoba potrzebuje wszystkich czterech. Program, który otwiera się pomyślnie, przeszedł lokalny etap uruchamiania i nic więcej.