Konfiguracja Clientless SSL VPN dla RDP i SSH na Sophos Firewall

Za pomocą Clientless SSL VPN Sophos Firewall udostępnia bezpośrednio w przeglądarce pojedyncze wewnętrzne połączenia RDP, SSH, VNC lub z serwerami plików. Użytkownik nie instaluje klienta VPN i nie otrzymuje ogólnego dostępu do sieci wewnętrznej. Zamiast tego loguje się do VPN Portal i widzi tylko bookmarki opublikowane przez przypisaną mu policy Clientless.

Podobna nazwa łatwo prowadzi do niewłaściwej konfiguracji: Clientless Users wewnętrznie przypisuje stały adres IP do tożsamości. Nie publikuje bookmarków i nie należy do tej procedury Remote Access.

Logowanie do VPN Portal i logowanie do systemu docelowego to dwa oddzielne etapy. Clientless SSL VPN nie obsługuje Credential Passthrough: hasło do VPN Portal nie jest automatycznie przekazywane jako dane logowania Windows lub SSH. Dwa logowania są więc normalne, dopóki dane logowania do celu nie zostaną zapisane w bookmarku.

Podstawowy proces jest krótki:

Określić stały system docelowy, port i uprawnioną grupę użytkowników.
W sekcji Remote access VPN > Clientless SSL VPN policy > Bookmarks utworzyć bookmark RDP lub SSH.
W sekcji Policies połączyć grupę użytkowników z bookmarkiem.
Zabezpieczyć VPN Portal, certyfikat, uwierzytelnianie, MFA i Device Access.
Przetestować dostęp z zewnątrz w sekcji VPN > Clientless access connections przy użyciu uprawnionego i nieuprawnionego użytkownika.

Kiedy Clientless SSL VPN jest odpowiedni, a kiedy nie

Clientless Access nadaje się szczególnie do kilku stałych celów, sporadycznego dostępu lub pracy zewnętrznych techników, gdy na używanym urządzeniu nie ma być instalowany klient VPN. Dzięki temu RDP i SSH nie muszą być publikowane bezpośrednio w Internecie za pomocą DNAT. Publicznie dostępny jest natomiast zabezpieczony VPN Portal.

Nie jest to jednak uproszczony zamiennik każdego Remote Access VPN:

Clientless SSL VPN pasuje do pojedynczych statycznych celów RDP, SSH, VNC lub serwerów plików, które można obsługiwać w przeglądarce.
Sophos Connect z IPsec lub SSL VPN sprawdza się lepiej, gdy zarządzane urządzenie potrzebuje dostępu do wielu sieci, aplikacji natywnych, DNS lub różnych protokołów. Warianty opisano w poradniku wyboru Remote Access.
ZTNA jest przeznaczone do stałego dostępu zorientowanego na aplikacje, opartego na tożsamości, stanie urządzenia i centralnych policies. Podstawy opisano w artykule Czym jest Zero Trust Network Access?.
Warto rozważyć RD Gateway, Jump Host lub PAM, gdy kluczowe znaczenie mają uprzywilejowana administracja, osobiste konta docelowe, rejestrowanie sesji lub procesy zatwierdzania.

W przypadku RDP należy również pamiętać, że schowek nie jest obsługiwany w sesjach Clientless od SFOS 19. Jeśli kopiowanie i wklejanie lub inne natywne funkcje RDP są niezbędne w danym procesie, lepszym wyborem będzie dostęp oparty na kliencie lub wyspecjalizowane rozwiązanie.

Clientless SSL VPN nie obsługuje dynamicznych docelowych adresów IP. Nazwa hosta jest dozwolona jako cel, ale Sophos Firewall musi rozwiązywać ją stabilnie na właściwy system. Często zmieniający się cel nie powinien być planowany jako niezawodnie aktualizowany scenariusz Dynamic DNS.

Przeglądarka jest tylko interfejsem: zestawia połączenie HTTPS z VPN Portal, a Sophos Firewall zestawia drugie połączenie z celem. Blokada wyskakujących okien musi zezwalać na nowe okno dla FQDN portalu. SFOS 22 nie publikuje dowolnych wewnętrznych aplikacji HTTP lub HTTPS jako bookmarków Clientless; zależnie od wymagań należy użyć WAF lub ZTNA.

Wymagania wstępne i wartości przykładowe

Przed konfiguracją należy ustalić cel, tożsamość i dostęp do portalu:

System docelowy jest osiągalny z Sophos Firewall za pomocą routingu i DNS, a wymagana usługa działa.
Na Sophos Firewall lub podłączonym serwerze uwierzytelniania istnieje użytkownik albo możliwie wąska grupa.
VPN Portal ma publicznie lub wewnętrznie osiągalny FQDN oraz odpowiedni, zaufany certyfikat.
W sekcji Authentication > Services wybrano odpowiednią metodę w polu VPN portal authentication methods.
Przygotowano MFA i niezależny dostęp awaryjny.
Ustalono, czy dane logowania do celu mogą być przechowywane w bookmarku.

Poniższy przykład RDP wykorzystuje:

VPN Portal: https://vpn.example.com
serwer docelowy: rdp-app01.intern.example
docelowy adres IP: 10.20.30.25
port RDP: 3389
bookmark: RDP-Fibu-Test
grupa: Clientless-RDP-Fibu
policy: Clientless-RDP-Fibu
zabezpieczenie RDP dla pierwszego testu: TLS
Automatic login: wyłączone
Share session: wyłączone

example.com jest zarezerwowaną domeną przykładową, a 10.20.30.25 prywatnym adresem przykładowym. FQDN, adres IP, grupa i nazwy muszą zostać zastąpione wartościami z własnego środowiska. Port 3389 jest prawidłowy tylko wtedy, gdy serwer Windows rzeczywiście używa standardowego portu RDP.

Konfiguracja bookmarka RDP

Bookmark z TLS i osobistym logowaniem do celu

W sekcji Remote access VPN > Clientless SSL VPN policy > Bookmarks za pomocą Add tworzy się nowy bookmark:

W polu Name wpisać RDP-Fibu-Test.
Jako Type wybrać RDP.
W polu URL wpisać rdp-app01.intern.example lub stały adres IP 10.20.30.25.
Użyć portu usługi 3389. Inny port wpisuje się tylko wtedy, gdy został on świadomie skonfigurowany inaczej na systemie docelowym.
Na potrzeby pierwszego testu pozostawić Automatic login wyłączone.
W razie potrzeby wpisać domenę sieciową Windows, na przykład CORP lub corp.example.com.
W polu Protocol security wybrać TLS. Trzecia opcja, RDP, używa własnych zabezpieczeń protokołu RDP; Sophos zaleca zamiast niej TLS lub NLA.
Pozostawić Share session wyłączone.
Zapisać przyciskiem Save.

Bez Automatic login użytkownik wpisuje swoje dane logowania w otwartym oknie RDP. Pozwala to zalogować się za pomocą osobistego konta Windows, o ile model zabezpieczeń serwera docelowego dopuszcza ten tryb TLS.

Certyfikat VPN Portal i Protocol security: TLS pełnią różne funkcje. Certyfikat portalu chroni połączenie przeglądarki z Sophos Firewall. Ustawienie RDP chroni dalsze połączenie Sophos Firewall z systemem Windows. Prawidłowy certyfikat portalu nie zastępuje więc odpowiedniego zabezpieczenia RDP.

Gdy serwer Windows wymaga NLA

Wiele systemów Windows wymaga Network Level Authentication (NLA). W takim przypadku w bookmarku wybiera się NLA. SFOS włącza przez to Automatic login, a nazwa użytkownika i hasło systemu docelowego muszą zostać zapisane w bookmarku.

Nie jest to wyłącznie opcja zwiększająca wygodę. Wszyscy uprawnieni użytkownicy tego bookmarka pracują na systemie docelowym z użyciem tej samej zapisanej tożsamości Windows. Do tego celu należy używać wyłącznie dedykowanego konta z minimalnymi uprawnieniami i możliwością rotacji. Konta Domain Admin, osobiste konta administracyjne i szeroko uprawnione konta usługowe nie powinny znajdować się w bookmarku Clientless.

NLA nie powinno być wyłączane na serwerze Windows tylko po to, aby zadziałała przykładowa ścieżka TLS. Jeśli zapisane dane logowania lub wspólna tożsamość docelowa są niedopuszczalne, Clientless RDP nie pasuje do tego serwera. Zwykły VPN, RD Gateway, PAM lub kontrolowany Jump Host lepiej zachowują osobistą rozliczalność.

Również Share session pozostaje wyłączone. Opcja jest przeznaczona do świadomie zaplanowanego przypadku współpracy. W sesji współdzielonej Stop session kończy połączenie dla wszystkich uczestników, natomiast Suspend session wstrzymuje je tylko dla bieżącego użytkownika. Sesji uprzywilejowanej administracji nie należy udostępniać.

Bookmark VNC dla systemów Linux i UNIX

Bookmark VNC działa według tej samej podstawowej zasady, ale używa Type: VNC. W polu URL wpisuje się stały adres IP systemu docelowego albo stabilnie rozwiązywaną nazwę hosta. Inny port VNC podaje się tylko wtedy, gdy usługa rzeczywiście nasłuchuje na porcie niestandardowym.

Po włączeniu Automatic login SFOS zapisuje hasło do celu w bookmarku VNC. Gdy opcja pozostaje wyłączona, użytkownik wpisuje hasło przy otwieraniu połączenia. W bookmarku VNC nie konfiguruje się nazwy użytkownika. Share session pozostaje wyłączone dla zwykłego dostępu indywidualnego i jest używane wyłącznie wtedy, gdy wspólna sesja jest wyraźnie wymagana.

ℹ️ Także w przypadku VNC logowanie do VPN Portal nie jest przekazywane do systemu docelowego. Prawidłowe logowanie do portalu nie dowodzi więc ani poprawności hasła VNC, ani osiągalności usługi VNC z firewalla.

Konfiguracja policy Clientless i VPN Portal

Łączenie użytkowników i bookmarka w policy

Sam istniejący bookmark nie udostępnia jeszcze celu użytkownikowi. Dopiero policy łączy tożsamość z zasobem:

Otworzyć Remote access VPN > Clientless SSL VPN policy.
W sekcji Policies kliknąć Add.
Jako Name wpisać Clientless-RDP-Fibu.
W polu Policy members wybrać tylko grupę Clientless-RDP-Fibu.
W polu Published bookmarks wybrać RDP-Fibu-Test.
Zapisać przyciskiem Apply.

Bookmark Group ma sens dopiero wtedy, gdy ci sami użytkownicy potrzebują kilku celów. Dla pojedynczego celu RDP tworzy tylko dodatkowy poziom zarządzania.

Zabezpieczanie VPN Portal

Użytkownik otwiera połączenia Clientless za pośrednictwem VPN Portal. Domyślny port to 443; port i certyfikat znajdują się w sekcji Administration > Admin and user settings > Admin console and end-user interaction. W przykładzie certyfikat musi zawierać vpn.example.com jako SAN i być akceptowany przez przeglądarkę bez ostrzeżenia. Ogólne przypisywanie certyfikatów opisano w artykule Importowanie i przypisywanie certyfikatów na Sophos Firewall.

W sekcji Administration > Device access usługa VPN portal musi być dozwolona dla rzeczywiście potrzebnego dostępu. Jeśli portal ma być osiągalny ze wszystkich źródeł WAN, w macierzy włącza się WAN. W przypadku znanych sieci źródłowych lepszy jest bardziej restrykcyjny wariant: pozostawić WAN wyłączone w macierzy i w sekcji Local service ACL exception rule utworzyć regułę z Source zone: WAN, konkretnym Source Network / Host, wymaganym adresem Sophos Firewall jako Destination host, Services: VPN portal oraz Action: Accept. Dodatkowy wyjątek Accept nie ogranicza już ogólnie włączonego dostępu WAN w macierzy. WebAdmin, User Portal, SSH ani SSL VPN nie są przez to automatycznie udostępniane. Firewall Rules nie sterują tymi usługami lokalnymi. Bezpieczne planowanie opisano w artykule Device Access i Local Service ACL.

⚠️ VPN Portal osiągalny ze strefy WAN jest publiczną powierzchnią logowania. Nie powinien działać bez MFA, zaufanego certyfikatu, wąskiego członkostwa w policy i monitorowania logowań. Jeśli VPN Portal i SSL VPN używają tego samego portu, Login security settings nie działają. Jeżeli używają także tego samego protokołu, zezwolenie na SSL VPN z danej strefy udostępnia również VPN Portal, nawet gdy w Device access jest on dla tej strefy wyłączony. Każda usługa lokalna powinna używać unikalnej kombinacji portu i protokołu, a po każdej zmianie portu trzeba ponownie sprawdzić dostępność.

Dla lokalnego Sophos OTP w sekcji Authentication > Multi-factor authentication najpierw wybiera się Specific users and groups. Aby umożliwić samodzielną rejestrację za pomocą aplikacji uwierzytelniającej, należy włączyć Generate OTP token with next sign-in, w sekcji Require MFA for wybrać VPN portal i zapisać przyciskiem Apply. Ten bezpośredni przepływ kodu QR w VPN Portal dotyczy SFOS 22. W SFOS 23, przy włączonym Generate OTP token with next sign-in, przed Apply należy dodatkowo wybrać Share QR code: Email wysyła kod QR e-mailem przy następnym logowaniu do VPN lub User Portal; Portals wyświetla go w User Portal i VPN Portal po następnym logowaniu do VPN Portal, User Portal lub WebAdmin. Dla przedstawionego przykładu skanowania w portalu wybrać jawnie Portals. SFOS 22 obsługuje SHA1, SHA256 i SHA512, a Sophos zaleca SHA256 lub SHA512. Aplikacja musi jednak obsługiwać wybrany algorytm: Intercept X for Mobile i Google Authenticator są zgodne, natomiast Microsoft Authenticator może zeskanować kod SHA256 lub SHA512, lecz późniejsze logowanie nie powiedzie się. Przy zmianie algorytmu należy usunąć istniejące tokeny w Issued tokens, a następnie ponownie zeskanować kod QR. Przed usunięciem sprawdzić, czy dla tego przepływu włączono Generate OTP token with next sign-in. Dostarczenie nowego kodu QR podlega temu samemu rozróżnieniu wersji: SFOS 22 wyświetla kod w portalu; SFOS 23 używa Email lub Portals w Share QR code, przy czym dla tego przykładu pozostaje wybrane Portals. Pilotaż i ścieżkę odzyskiwania opisano w artykule Aktywacja MFA dla Sophos Firewall. VPN Portal nie obsługuje MFA RADIUS opartego na challenge; istniejącą metodę RADIUS trzeba więc przetestować dokładnie dla tego logowania do portalu. Jeśli portal ma zamiast tego używać Microsoft Entra ID SSO i Conditional Access, pełny łańcuch tożsamości opisano w artykule Entra ID SSO dla Sophos Connect i VPN Portal.

W sekcji Authentication > Services można wybrać maksymalnie 20 serwerów dla każdej metody uwierzytelniania. Globalne ustawienia Maximum session timeout i Simultaneous logins nie dotyczą wyłącznie VPN Portal. SFOS sprawdza autoryzację co trzy minuty, a limit jednoczesnych logowań obejmuje tylko użytkowników dodanych po ustawieniu tej wartości. Nie należy więc traktować tych limitów jako natychmiastowych, specyficznych dla portalu mechanizmów kontroli dostępu.

Testowanie dostępu z zewnątrz

Test należy przeprowadzić z rzeczywistej sieci zewnętrznej, na przykład przez hotspot komórkowy. Test z sieci LAN nie dowodzi, że DNS, certyfikat, Device Access i router poprzedzający Sophos Firewall współdziałają prawidłowo od strony Internetu.

Otworzyć https://vpn.example.com w prywatnym oknie przeglądarki.
Sprawdzić nazwę certyfikatu, łańcuch certyfikatów i stan w przeglądarce.
Zalogować się jako członek Clientless-RDP-Fibu i ukończyć MFA.
W sekcji VPN > Clientless access connections sprawdzić, czy pojawia się RDP-Fibu-Test.
Kliknąć Connect. Sesja musi otworzyć się w nowym oknie przeglądarki.
Przy wyłączonym Automatic login wpisać osobiste dane logowania Windows i sprawdzić logowanie RDP.
Prawidłowo wylogować sesję w systemie Windows, a następnie opuścić VPN Portal.
Przeprowadzić test z użytkownikiem spoza grupy. Bookmark nie może się tam pojawić.
Tymczasowo usunąć użytkownika testowego z grupy policy i sprawdzić, czy dostęp znika po ponownym zalogowaniu.

Sukces oznacza nie tylko widoczny pulpit. Użytkownik pozytywnego testu widzi dokładnie przewidziane bookmarki, użytkownik negatywnego testu nie widzi żadnego, MFA działa, certyfikat jest zaufany, logowanie do celu przebiega prawidłowo, a sesja kończy się w sposób możliwy do prześledzenia zarówno w portalu, jak i na systemie docelowym.

Obsługa sesji i klawiatury w przeglądarce

W sesjach RDP, VNC, SSH i Telnet należy przesunąć wskaźnik do górnej krawędzi zdalnego ekranu, aby wyświetlić opcje sesji. W menu Connection dostępne są Stop session i Suspend session. Po Suspend session ten sam użytkownik wznawia sesję przy następnym kliknięciu Connect w VPN Portal. Pozostali uczestnicy sesji współdzielonej nadal pracują; Stop session kończy ją natomiast dla wszystkich.

W połączeniach RDP i VNC menu Keyboard pozwala wybierać skróty klawiaturowe i zmieniać język klawiatury. Aby zastosować język z listy inny niż angielski, udokumentowana procedura wymaga ustawienia języka serwera docelowego na US English. Wymóg ten dotyczy wyboru języka w Keyboard, a nie schowka.

SSH, VNC i serwery plików

Bookmark SSH ze sprawdzonym Host Key

Dla SSH w sekcji Bookmarks > Add jako Type wybiera się SSH. Przykład wykorzystuje srv-linux01.intern.example, port 22 i użytkownika clientless-test.

Public host key musi należeć do oczekiwanego serwera. W przypadku systemu docelowego Linux można wyświetlić publiczny Host Key bezpośrednio na zaufanej konsoli serwera i udokumentować jego fingerprint:

sudo cat /etc/ssh/ssh_host_ed25519_key.pub
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Polecenia te wykonuje się na docelowym serwerze Linux, a nie na Sophos Firewall. Jeśli serwer używa innego typu Host Key, nazwę pliku trzeba odpowiednio zmienić. Klucza z niezweryfikowanego ostrzeżenia przeglądarki lub dowolnego skanu sieciowego nie należy przejmować bez sprawdzenia.

Pierwsze polecenie wyświetla publiczny ED25519 Host Key jako przykład identyfikacji na zaufanej konsoli systemu docelowego. Nie potwierdza to, że zainstalowany build SSH clientless akceptuje ED25519 lub pokazaną reprezentację OpenSSH w polu Public host key. Przed wstawieniem należy potwierdzić zarówno akceptowany algorytm, jak i serializowaną reprezentację klucza publicznego w oficjalnej dokumentacji SSH clientless właściwej dla tego buildu lub z Sophos Support. Obsługa SSH w Linuksie, ustawienia SSH WebAdmin, SFTP i identyczne teksty źródłowe nie dowodzą tej zgodności pola. Drugie polecenie pokazuje tylko fingerprint do udokumentowanego porównania; fingerprintu nie kopiuje się do pola zamiast klucza.

Następnie należy utworzyć kompletny bookmark SSH:

W polu Name wpisać na przykład SSH-Linux-Test.
Jako Type wybrać SSH.
W polu URL wpisać srv-linux01.intern.example, a jako port 22.
W polu Username ustawić clientless-test lub przewidzianego użytkownika docelowego.
Pozostawić Automatic login wyłączone, jeśli użytkownik ma samodzielnie wpisywać hasło do celu.
W polu Public host key wkleić klucz publiczny sprawdzony bezpośrednio na systemie docelowym dopiero po potwierdzeniu algorytmu i reprezentacji dla zainstalowanego buildu SSH clientless.
Pozostawić Share session wyłączone i zapisać przyciskiem Save.
Dodać bookmark do policy Clientless w polu Published bookmarks i zapisać przyciskiem Apply.
W VPN Portal w sekcji VPN > Clientless access connections kliknąć Connect, wpisać hasło do celu i sprawdzić, czy pojawia się oczekiwany prompt terminala. Następnie prawidłowo zakończyć sesję SSH.

Bez Automatic login użytkownik wpisuje hasło do celu podczas nawiązywania połączenia; nazwa użytkownika pozostaje częścią bookmarka. Dla różnych osobistych nazw użytkowników SSH potrzebne są więc oddzielne bookmarki lub inna ścieżka dostępu. Z Automatic login SFOS może używać hasła lub Private Key. Uprzywilejowane lub szeroko wykorzystywane Private Keys nie powinny być zapisywane we wspólnie publikowanym bookmarku.

Serwery plików z FTP, FTPS, SFTP lub SMB

Bookmarki serwerów plików również tworzy się w Remote access VPN > Clientless SSL VPN policy > Bookmarks > Add. W polu Type dostępne są FTP, FTPS, SFTP i SMB. URL zawiera stały adres IP lub stabilną nazwę hosta; Clientless SSL VPN nie obsługuje dynamicznych adresów docelowych. W polu Init remote folder można opcjonalnie wskazać katalog początkowy po zestawieniu połączenia.

Metody różnią się głównie transportem i uwierzytelnianiem na celu:

FTP, FTPS i SMB mogą działać z Automatic login lub bez niego. Bez zapisanych danych logowania użytkownik loguje się do systemu docelowego po otwarciu bookmarka. FTP przesyła dane bez szyfrowania i nie należy używać go w nowych zewnętrznych workflowach.
Dla SMB można dodatkowo opcjonalnie wpisać domenę sieciową Windows, do której należą konto i system docelowy, na przykład CORP, corp.example lub corp.example.com. Przykłady należy zastąpić rzeczywistą domeną własnego środowiska.
FTPS chroni połączenie FTP za pomocą TLS. W polu Public host key zapisuje się również oczekiwany certyfikat serwera w formacie .pem. Certyfikat i nazwę sprawdza się bezpośrednio na zarządzanym systemie docelowym, a nie przejmuje z niezweryfikowanego połączenia.
SFTP używa SSH. Bookmark zawiera użytkownika docelowego oraz w Authentication method opcję Password albo Private key z odpowiednimi danymi logowania do celu. Public host key służy do weryfikacji tożsamości serwera. Prywatny klucz użytkownika i publiczny Host Key serwera mają różne zadania i nie wolno ich mylić.

⚠️ Format danych w polu Public host key dla SFTP pozostaje niejasny: instrukcje serwerów plików dla SFOS 22 i 23 wskazują certyfikat serwera w formacie .pem, natomiast oddzielna instrukcja SSH wymaga klucza publicznego serwera. Nie potwierdza to ani wymagania X.509, ani akceptacji wartości OpenSSH lub ED25519 w polu SFTP. Powyższe polecenia SSH nie są więc instrukcją formatu SFTP. Przed wdrożeniem produkcyjnym należy wyjaśnić z Sophos Support, jaką reprezentację SFTP akceptuje zainstalowany build, i sprawdzić tożsamość serwera bezpośrednio na zaufanym systemie docelowym; nie konwertować formatów na podstawie przypuszczeń ani nie omijać weryfikacji tożsamości.

Również w bookmarkach serwerów plików inny port usługi ustawia się tylko wtedy, gdy odpowiednia usługa na serwerze docelowym rzeczywiście korzysta z portu innego niż domyślny.

Po włączeniu Automatic login nazwa użytkownika i hasło systemu docelowego są zapisywane w bookmarku dla FTP, FTPS i SMB. Wszyscy uprawnieni użytkownicy korzystają wtedy z tej samej zapisanej tożsamości docelowej, dlatego obowiązują takie same wymagania dotyczące minimalnych uprawnień i rotacji jak w przykładzie NLA. Nie jest to Credential Passthrough z VPN Portal.

W tej procedurze SFTP SFOS automatycznie uwierzytelnia użytkownika przy użyciu danych logowania do celu zapisanych w bookmarku. Użytkownik nie jest proszony o hasło do celu; opcjonalne logowanie interaktywne dostępne dla SSH, FTP, FTPS i SMB nie dotyczy SFTP.

W przeglądarce sesje FTP, FTPS i SFTP pozwalają przesyłać pliki, tworzyć katalogi i poruszać się po strukturze folderów. SFOS rozpoczyna pobieranie bez dodatkowego pytania i zapisuje pliki w domyślnym katalogu pobierania urządzenia. Dlatego przed wdrożeniem produkcyjnym należy sprawdzić uprawnienia, katalog początkowy i test z niesensytywnymi plikami. Bookmark serwera plików nie tworzy zwykłego dysku sieciowego Windows i nie zastępuje kontroli osobistych uprawnień na serwerze docelowym.

Przyciski w prawym górnym rogu sesji FTP, FTPS i SFTP pozwalają zatrzymać sesję, przesłać plik na serwer, utworzyć katalog i przejść do katalogu nadrzędnego.

Telnet nadal jest dostępny jako typ terminala, ale nie szyfruje transportu. Nie należy używać go do nowych dostępów. Bookmarki HTTP i HTTPS nie należą do obecnie udokumentowanych typów Clientless dla SFOS 22. Dla wewnętrznych aplikacji webowych, zależnie od wymagań ochrony, lepszą architekturą jest Web Application Firewall lub ZTNA.

Jeśli starsze urządzenie tymczasowo wymaga Telnetu, należy wybrać Type: Telnet w Bookmarks > Add, wpisać stały host w URL i ustawić port tylko wtedy, gdy różni się od standardowego. Share session jest opcjonalne. Ten nieszyfrowany dostęp trzeba ograniczyć do wąskiej grupy i izolowanego celu zarządzania, a następnie zastąpić go SSH.

Jeśli te same cele trzeba przypisać do kilku policies, w Bookmark groups > Add tworzy się grupę: wpisać nazwę grupy w Name, wybrać istniejące bookmarki za pomocą Add new item i zapisać przyciskiem Save. Policy publikuje następnie grupę zamiast każdego celu osobno. Bookmark Group nie rozszerza uprawnień na systemie docelowym; upraszcza jedynie przypisanie w SFOS.

Przy tworzeniu lub modyfikowaniu grupy za pomocą XML API encja nazywa się SSLBookmarkGroup. Dokumentacja API dla SFOS 23.0 dopuszcza znaki UTF-8 w jej Name, zabrania przecinków i zachowuje limit 50 znaków. Dokumentacja SFOS 22.0 podaje już ten limit, ale nie dwie dodatkowe reguły dotyczące znaków; nie wynika z tego, jak egzekwują je starsze buildy. Poprawna przykładowa nazwa to Clientless-München, jak w <Name>Clientless-München</Name>; nazwę należy dostosować do własnego środowiska. Po wywołaniu API należy sprawdzić kod statusu i komunikat w odpowiedzi XML oraz ponownie odczytać zapisaną grupę: nazwa i zawarte bookmarki muszą odpowiadać zamierzonemu przypisaniu. Ta uwaga dotyczy nazwy grupy w API, a nie ogólnej reguły dla nazw pojedynczych bookmarków; w opisanym wyżej interfejsie obowiązują wymagania pól zainstalowanego buildu.

Pojedyncze bookmarki przez XML API: Przykład Add/Edit dla SSLBookmark w SFOS 22.0 i 23.0 jest materiałem referencyjnym z wariantami zależnymi od typu, a nie jednym payloadem do wykonania dla wszystkich protokołów. Zawarte w nim wartości HTTP i HTTPS nie dowodzą ani bieżącej obsługi w interfejsie użytkownika, ani obsługi w zainstalowanym buildzie. W przykładzie NLA wymaga włączonego AutoLogin; dla SSH/SFTP komentarz przy włączonym AutoLogin opisuje hasło lub Private Key jako alternatywy. Nie oznacza to zniesienia opisanych wyżej ograniczeń dotyczących SSH Host Key i formatu SFTP ani możliwości interaktywnego logowania SFTP.

Tabela parametrów oznacza jednak Private Key, Public Host Key i UserName jako pola obowiązkowe bez określenia typu, którego dotyczy ten wymóg. Ogranicza URL do znaków typowych dla nazw hostów, podczas gdy drugi wiersz Domains, dotyczący listy domen/URL-i przekierowań, wymaga początku HTTP:// lub HTTPS://. W przykładzie lista ta znajduje się pod dosłownym tokenem RefferredDomains; nie jest to domena Windows Domain dla RDP/SMB, mimo że tabela zawiera również wiersz RDP o nazwie Domains. Nie zmieniać nazw tokenów na podstawie przypuszczeń ani nie łączyć sprzecznych reguł tabeli w uniwersalny payload. Przed automatyczną zmianą należy ustalić akceptowane pola, warunki i reprezentacje dla danego typu i zainstalowanego buildu na podstawie odpowiedniej oficjalnej dokumentacji lub z Sophos Support; do tego czasu nie wykonywać niepotwierdzonej operacji modyfikującej. Wcześniej zapisać rzeczywisty bookmark i jego przypisania jako stan wyjściowy, a po zmianie sprawdzić status i komunikat XML oraz ponownie odczytać zapisany bookmark, członkostwo w grupach i publikację. W przypadku rozbieżności cofnąć wyłącznie własną zmianę, przywracając dokładnie ten stan wyjściowy, i powtórzyć testy dostępu; nie umieszczać haseł ani Private Keys w danych wyjściowych audytu ani w niezabezpieczonych plikach payloadów.

Rozwiązywanie typowych problemów

VPN Portal jest nieosiągalny: Sprawdzić publiczny rekord DNS, port, poprzedzający NAT, Administration > Device access i możliwy efekt Port Sharing.
Logowanie do portalu nie działa: W sekcji Authentication > Services sprawdzić uwierzytelnianie VPN Portal, stan użytkownika, MFA i access_server.log.
Brakuje Clientless access connections: Użytkownik nie jest przypisany do policy Clientless albo policy nie publikuje żadnego bookmarka.
Bookmark jest widoczny dla niewłaściwego użytkownika: Sprawdzić Policy members, członkostwo w grupach i Published bookmarks. W przypadku kilku pasujących grup Clientless SSL VPN może łączyć uprawnienia powiązanych policies. To, które bookmarki widzi przez to rzeczywisty użytkownik, należy sprawdzić w teście pozytywnym i negatywnym.
Bookmark otwiera się, ale cel jest nieosiągalny: Sprawdzić rozwiązywanie DNS z perspektywy Sophos Firewall, statyczny adres docelowy, routing, port docelowy, stan usługi i firewall hosta.
Logowanie do VPN Portal działa, ale logowanie Windows nie: Logowanie do portalu i do celu to oddzielne procesy. Sprawdzić domenę, konto docelowe, hasło oraz TLS lub NLA.
NLA włącza Automatic login: Jest to udokumentowane zachowanie. Nie wyłączać NLA bez planu, lecz ponownie ocenić model kont i dostępu.
SSH zgłasza inny Host Key: Zatrzymać połączenie i sprawdzić zmianę bezpośrednio na systemie docelowym lub u odpowiedzialnego administratora. Nieoczekiwany klucz może wskazywać na ponowną instalację, błędny cel lub atak.

W sekcji Diagnostics > Tools > Troubleshooting logs w poszczególnych etapach pomagają różne pliki:

vpnportal.log dla VPN Portal;
access_server.log dla uwierzytelniania i autoryzacji;
clientless_access.log dla połączeń Clientless i nawiązywania połączenia z celem;
oauth_sso_vpn.log w SFOS 22 dla logowań do VPN Portal z SSO; w SFOS 23, oauth_sso_svc.log dla OIDC/Entra SSO w VPN Portal. Dla tych logowań do VPN Portal sprawdzić także moduł Authentication w Log viewer.

Należy wspólnie udokumentować czas testu, użytkownika, bookmark i cel. Pozwala to rozdzielić w logach problemy portalu, tożsamości i celu. Ogólne przypisanie logów oraz dostęp przez Advanced Shell opisano w artykule Logi usług Sophos Firewall.

Eksploatacja i znane ograniczenia RDP

Przed zmianą produkcyjną należy zapisać przypisanie policy, macierz Device Access, wyjątki ACL, port portalu i wybrany certyfikat. Jeśli test pozytywny nie powiedzie się lub użytkownik negatywny zobaczy bookmark, należy usunąć nowe przypisanie lub publikację, przywrócić te wartości do poprzedniego stanu, zalogować się ponownie i powtórzyć test negatywny. Konta docelowe lub Host Keys przywraca się tylko wtedy, gdy rzeczywiście je zmieniono.

Policies Clientless należy regularnie sprawdzać tak jak inne uprawnienia Remote Access. Usuwa się niepotrzebnych użytkowników, bookmarki i konta docelowe. Zapisane hasła lub Private Keys otrzymują Ownera, datę wygaśnięcia i proces rotacji. Automatic login i Share session powinny być elementem każdej kontroli uprawnień.

Wycofanie publikacji nie jest usunięciem: Przed usuwaniem ustalić, czy chodzi o pojedynczy bookmark, czy o Bookmark Group, oraz zapisać dokładną nazwę, bieżące członkostwo w grupach i publikację we wszystkich objętych zmianą policies. Najpierw wycofać tylko niepożądaną już publikację lub przypisanie; nie usuwa to obiektu. Konkretny obiekt usunąć dopiero wtedy, gdy rzeczywiście nie jest używany i wyjaśniono jego zależności. Jeśli istnieją powiązania, zatrzymać operację i nie usuwać kaskadowo produkcyjnych grup ani policies tylko po to, aby wymusić usunięcie.

Dokumentacja referencyjna Delete dla SFOS 22.0 i 23.0 wymaga w obu wersjach Name o długości najwyżej 50 znaków i wymienia wartości statusu XML 200, 500 i 504. Przy 504 odwołuje się dla bookmarków do BookMarkDeleteRelationExists, a dla grup do BookMarkGroupDeleteRelationExists: są to identyfikatory komunikatów w dokumentacji, których nie rozwinięto do tekstu, a nie potwierdzone teksty komunikatów zwracanych podczas działania ani status HTTP. Dokumentacja ta nie zawiera ani przykładowego payloadu Delete, ani zapewnienia dotyczącego usuwania kaskadowego; nie wyprowadzać z niej składni usuwania. Po zmianie faktycznie ponownie odczytać pozostałe bookmarki, grupy i zamierzone publikacje oraz powtórzyć testy pozytywne i negatywne. W przypadku nieoczekiwanego dostępu cofnąć własne zmiany przypisań do zapisanego stanu wyjściowego; dlatego przy samym wycofywaniu publikacji należy unikać niepotrzebnego usuwania obiektów.

Aby zobaczyć na żywo zalogowanych użytkowników zdalnych, należy otworzyć Current activities > Remote users w konsoli administracyjnej. Połączenia można filtrować według daty połączenia, nazwy użytkownika, źródłowego adresu IP i przydzielonego adresu IP (leased IP). Administrator może wybrać Disconnect, aby rozłączyć wskazanego użytkownika zdalnego. Najpierw trzeba sprawdzić użytkownika i połączenie, ponieważ ta operacja przerywa dostęp. Nie zastępuje ona usunięcia użytkownika z policy Clientless ani prawidłowego wylogowania z systemu docelowego i nie gwarantuje zakończenia wszystkich dalszych sesji na systemach docelowych.

Dokumentacja kolumny Mode rozróżnia następujące przypadki:

SSL VPN (remote access): użytkownik jest połączony przez SSL VPN dostępu zdalnego.
User portal (clientless access): według tego przyporządkowania użytkownik jest zalogowany do User Portal i należy do policy Clientless SSL VPN.
User portal: według tego przyporządkowania użytkownik jest zalogowany do User Portal, ale nie należy do policy Clientless SSL VPN.

Te etykiety pochodzą z instrukcji Remote users dla SFOS 22 i 23. Instrukcje Clientless wskazują natomiast VPN portal jako ścieżkę dostępu. Terminologia jest więc niespójna; lista nie potwierdza ani aktualnych etykiet Mode zainstalowanego buildu, ani zmiany z SFOS 22 na 23. W konfiguracji nadal obowiązuje opisana wyżej procedura VPN Portal. Logowanie do portalu, członkostwo w policy i faktycznie widoczne bookmarki trzeba sprawdzać oddzielnie, zamiast wyprowadzać uprawnienia wyłącznie z etykiety Mode.

Przed zmianą firmware użyj runbooka Avanet dotyczącego decyzji o firmware, aby ustalić zmiany dotyczące zainstalowanego buildu i wersji docelowej. W kontroli uwzględnij Clientless Access, VPN portal, RDP oraz używaną metodę uwierzytelniania. Po aktualizacji powtórz pełny test pozytywny i negatywny.

RDP ma dwa aktualne ograniczenia, których nie należy traktować jako błędów konfiguracji:

Schowek nie jest obsługiwany w bookmarkach Clientless RDP od SFOS 19. Kopiowanie i wklejanie między urządzeniem lokalnym a sesją RDP nie jest więc niezawodnym sposobem pracy.
W sesji HTML5 RDP wskaźnik myszy może być wyświetlany jako krzyżyk lub X zamiast zwykłej strzałki. Sophos nie podaje obecnie żadnego obejścia.

Jeśli niezbędne są schowek, natywne funkcje RDP, szerszy dostęp do sieci albo osobiste konta docelowe na serwerze wymagającym NLA bez zapisanych danych logowania, Clientless SSL VPN nie jest odpowiednim skrótem. Należy wtedy świadomie przejść na Sophos Connect, RD Gateway, PAM, Jump Host lub ZTNA.