Pulse Secure to dziś przede wszystkim nazwa historyczna, ale wciąż ważna dla osób, które utrzymują firmowy VPN, klienta na Linuksie albo planują migrację na nowszą platformę dostępu. W praktyce chodzi o zdalny dostęp do zasobów firmowych: tunel VPN, uwierzytelnianie wieloskładnikowe, kontrolę stanu urządzenia i porządkowanie starszych wdrożeń. W 2026 roku temat jest szczególnie ważny, bo stare instalacje nadal pracują w wielu organizacjach, a ich nazwy i linie produktowe potrafią mylić nawet doświadczonych administratorów. Poniżej porządkuję, czym to rozwiązanie jest, jak działa na Linuksie i co realnie warto sprawdzić przed wdrożeniem lub wymianą.
Najważniejsze informacje w skrócie
- To rozwiązanie do bezpiecznego zdalnego dostępu, a nie tylko „kolejny klient VPN”.
- Stara linia 9.1x zakończyła wsparcie 31 grudnia 2024 roku, więc nie jest już dobrym wyborem do nowych lub krytycznych wdrożeń.
- Aktualny klient dla środowisk końcowych jest rozwijany jako Ivanti Secure Access Client i działa także na Linuksie.
- Na Linuksie instalacja jest oparta o CLI, a do poprawnego działania zwykle potrzebne są dodatkowe pakiety zależności.
- Najwięcej problemów nie wynika z samego tunelu, tylko z polityk dostępu, MFA, certyfikatów i zgodności wersji.
- Jeśli utrzymujesz starszą bramę wystawioną do internetu, plan migracji powinien być priorytetem, a nie „zadaniem na później”.
Czym jest to rozwiązanie i dlaczego nazwa bywa myląca
Najprościej patrzę na ten temat tak: to rodzina narzędzi do zdalnego dostępu do zasobów firmowych, w której są zarówno komponenty brzegowe, jak i klient końcowy. Z perspektywy użytkownika końcowego wygląda to jak zwykłe połączenie VPN, ale od strony administracyjnej dochodzi jeszcze kontrola urządzenia, integracja z katalogiem tożsamości i polityki oparte na roli. Właśnie dlatego ta marka bywa myląca, bo w obiegu funkcjonuje jednocześnie jako dawna nazwa produktu, skrót myślowy na klienta oraz określenie całego ekosystemu dostępu.
Po przejęciu przez Ivanti nazewnictwo zostało uporządkowane, ale w starszych wdrożeniach nadal spotyka się dokumentację, ikony i procedury z poprzedniego okresu. Dla administratora nie ma to znaczenia kosmetycznego. Znaczenie ma to, czy mówi o bramie, kliencie, politykach czy migracji, bo od tego zależą następne kroki. Ja zwykle zaczynam od rozdzielenia tych pojęć, bo wtedy szybciej widać, co jest jeszcze aktualne, a co już tylko legacy.
To rozróżnienie prowadzi wprost do pytania, jak taki dostęp działa w praktyce i gdzie w tym wszystkim pojawia się Linux.
Jak działa w sieci firmowej i gdzie wchodzi Linux
W typowym scenariuszu użytkownik uruchamia klienta, loguje się przez mechanizm firmowy, a następnie dostaje dostęp zgodny z polityką organizacji. Czasem jest to pełny tunel, czasem dostęp warunkowy do konkretnych aplikacji lub segmentów sieci. W nowoczesnych wdrożeniach ważne jest nie tylko samo szyfrowanie, ale też sprawdzenie tożsamości, stanu urządzenia i kontekstu sesji. To właśnie odróżnia zwykłe „połączenie z firmą” od rozwiązania, które rzeczywiście wspiera zero trust.
| Warstwa | Rola | Na co zwrócić uwagę |
|---|---|---|
| Klient na stacji roboczej | Tworzy sesję VPN i przekazuje dane uwierzytelnienia | Czy instalacja działa na danej dystrybucji i czy są spełnione zależności |
| Uwierzytelnianie | Weryfikuje użytkownika przez SSO, MFA, certyfikat lub LDAP/AD | Czy polityka nie blokuje poprawnych użytkowników przez zbyt sztywne reguły |
| Brama dostępu | Buduje tunel i egzekwuje polityki ruchu | Czy jest aktualna, wspierana i zgodna z wymaganiami bezpieczeństwa |
| Kontrola postawy urządzenia | Sprawdza zgodność endpointu z polityką firmy | Czy urządzenie ma aktualny system, szyfrowanie dysku, aktywny firewall i wymagane komponenty |
Na Linuksie dochodzi jeszcze warstwa praktyczna. W bieżącej dokumentacji Ivanti klient dla Linuksa obsługuje instalację z linii poleceń i buduje połączenie Layer 3 VPN z bramą Connect Secure. Warto to podkreślić, bo wielu administratorów zakłada, że proces będzie identyczny jak na Windowsie. Nie jest. Na Linuksie trzeba bardziej uważać na pakiety zależności, wariant dystrybucji i sposób logowania użytkownika. To właśnie tutaj najczęściej wychodzą różnice, które później decydują o stabilności całego wdrożenia.
Skoro sam mechanizm jest już jasny, warto sprawdzić, co z tej rodziny produktów jest dziś aktualne, a co powinno być traktowane jako techniczny dług.
Co dziś jest aktualne, a co wymaga migracji
Według dokumentacji Ivanti starsza linia 9.1x zakończyła wsparcie 31 grudnia 2024 roku i nie otrzymuje już zmian kodu. To jest granica, którą trzeba traktować poważnie. Jeżeli takie urządzenie nadal stoi na brzegu sieci i jest wystawione do internetu, ryzyko przestaje być teoretyczne. W praktyce oznacza to, że nowe wdrożenia nie powinny opierać się na starym wydaniu, a istniejące środowiska trzeba planowo przestawiać na wspierane wersje albo na inne bezpieczne rozwiązanie.
| Obszar | Starsza linia | Stan obecny |
|---|---|---|
| Wsparcie | Brak wsparcia po 31 grudnia 2024 | Aktywne, przy założeniu pracy na wspieranych wersjach |
| Klient końcowy | Starszy klient z dawnym brandingiem | Ivanti Secure Access Client |
| Linux | Legacy dokumentacja i starsze pakiety | Instalacja CLI, aktualne pakiety i testowane dystrybucje |
| Ryzyko operacyjne | Brak poprawek i rosnąca podatność na błędy | Niższe, jeśli środowisko pozostaje aktualne i zgodne z zaleceniami producenta |
Aktualna dokumentacja klienta dla Linuksa pokazuje też, jak ważna jest zgodność platform. Testowane są między innymi Ubuntu 24.04.2 LTS, Ubuntu 22.04 LTS, Ubuntu 20.04.5 LTS, Fedora 32, Debian 11, RHEL 8.3 i CentOS 8.2.2004. To nie jest lista „na zawsze”, tylko zestaw środowisk sprawdzonych z bieżącą wersją. Warto też pamiętać, że na Ubuntu 22.04 LTS pewne funkcje, w tym CEF i SAML, nie są wspierane. Dla części firm to detal, ale dla środowisk opartych na logowaniu federacyjnym taki detal potrafi zatrzymać całe wdrożenie.
Gdy już wiadomo, co jest aktualne, a co wymaga wymiany, można przejść do samego wdrożenia klienta na Linuksie bez typowych potknięć.
Jak zainstalować i sprawdzić klienta na Linuksie
Tu najczęściej wygrywa prostota. Zamiast zaczynać od skomplikowanej konfiguracji, ja zwykle zaczynam od trzech pytań: czy dystrybucja jest wspierana, czy są wszystkie zależności i czy organizacja ma spójny sposób uwierzytelniania. Jak podaje Ivanti, instalacja dla Linuksa jest oparta o CLI, a do poprawnego działania potrzebne są m.in. nss3-tools i net-tools. To ważne, bo bez tych pakietów klient potrafi zainstalować się tylko częściowo albo uruchamiać się z błędami, które trudno potem powiązać z właściwą przyczyną.
- Sprawdź, czy używasz aktualnego pakietu dla Ivanti Secure Access Client, a nie starej wersji z dawnych zasobów.
- Doinstaluj wymagane zależności dla swojej dystrybucji.
- Zainstaluj pakiet z użyciem odpowiedniego menedżera: apt na systemach Debian i Ubuntu lub rpm na systemach opartych o RPM.
- Zweryfikuj logowanie, MFA, certyfikaty i dostęp do rzeczywistych zasobów firmowych, a nie tylko sam fakt zestawienia tunelu.
- Sprawdź, czy polityka split tunnelingu, DNS i trasy sieciowe odpowiadają temu, jak użytkownicy faktycznie pracują.
Istotna jest jeszcze jedna rzecz: aktualizacja z dawnego klienta do nowego nie jest wspierana jako prosty upgrade. W praktyce oznacza to, że plan trzeba budować jak przy czystej migracji, a nie jak przy zwykłym patchowaniu. Jeśli ktoś próbuje ominąć ten krok, zwykle kończy z niestabilnym środowiskiem i trudnymi do odtworzenia błędami po stronie użytkowników. To prowadzi do kolejnego, praktycznego pytania: co najczęściej psuje się nie w instalacji, ale później, już w pracy produkcyjnej?
Najczęstsze błędy przy utrzymaniu i migracji
W praktyce najwięcej problemów widzę nie na poziomie samego tunelu, tylko na styku tożsamości, polityk i sieci. Sama instalacja potrafi przejść gładko, a potem użytkownik nie ma dostępu do jednego z zasobów, bo trasa jest źle zdefiniowana, DNS wskazuje niewłaściwy serwer albo polityka roli jest zbyt wąska. To nie jest wada jednego produktu. To klasyczny efekt zbyt szybkiego wdrażania bez testu pełnego scenariusza użytkownika.
- Utrzymywanie starej bramy po terminie wsparcia - to najgroźniejszy błąd, bo ryzyko dotyczy już nie tylko awarii, ale i bezpieczeństwa.
- Założenie, że upgrade klienta rozwiąże wszystko - przy tej platformie potrzebny jest często czysty proces migracji.
- Brak spójności w MFA i SSO - użytkownik może mieć poprawne konto, ale nie przejdzie przez politykę uwierzytelniania.
- Ignorowanie stanu endpointu - jeśli urządzenie nie spełnia wymagań, dostęp powinien być ograniczony, a nie udawany.
- Testowanie tylko na jednej dystrybucji - na Linuksie różnice między wydaniami są realne i potrafią zmienić wynik wdrożenia.
- Brak planu dla użytkowników poza biurem - jeśli część zespołu pracuje mobilnie, trzeba uwzględnić również certyfikaty, sieci domowe i procedury awaryjne.
W polskich firmach dochodzi do tego jeszcze jedna rzecz: presja, żeby „po prostu działało”, bez czasu na porządną segmentację i opis ról. Ja nie traktuję tego jako drobiazgu organizacyjnego, tylko jako techniczny błąd, który później odbija się na zgodności z RODO, audycie i wsparciu użytkowników. Z tego powodu sensowna decyzja nie polega na samej wymianie nazwy, ale na uporządkowaniu całego modelu dostępu.
Co zrobiłbym dziś, zanim włączę to do produkcji
Gdybym dziś miał przejąć takie środowisko, zacząłbym od inwentaryzacji. Chcę wiedzieć, które urządzenia są jeszcze na starej linii, jakie wersje klientów krążą po stacjach, którzy użytkownicy logują się z Linuksa i jakie metody uwierzytelniania są faktycznie używane. Dopiero potem sprawdzam, czy lepszy będzie dalszy rozwój na Ivanti Connect Secure, czy pełniejsza zmiana architektury dostępu.
- Ustal dokładny stan wersji bramy i klienta na wszystkich platformach.
- Wyłącz lub odizoluj stare instancje, które nie powinny już mieć ekspozycji do internetu.
- Przetestuj logowanie, MFA i dostęp do zasobów z każdej wspieranej dystrybucji Linuksa osobno.
- Uprość polityki dostępu do takiego poziomu, żeby dało się je utrzymać bez ręcznego gaszenia pożarów.
- Udokumentuj ścieżkę migracji, bo bez niej każdy kolejny incydent będzie zaczynał się od odtwarzania wiedzy od zera.
Jeśli miałbym zostawić jedną praktyczną wskazówkę, byłaby prosta: nie oceniaj tego rozwiązania po samej nazwie. W 2026 roku liczy się to, czy używasz wspieranej wersji, czy klient na Linuksie instaluje się przewidywalnie, czy polityki dostępu są spójne i czy starsze wdrożenie nie ciąży już na bezpieczeństwie całej organizacji. Właśnie na tym etapie odróżnia się działający VPN od środowiska, które tylko wygląda na działające.
