Konfiguracja zdalnego dostępu SSL VPN na Sophos Firewall

Zdalny dostęp SSL VPN konfiguruje się na Sophos Firewall w obszarze Remote access VPN > SSL VPN. Bezpieczny dostęp wymaga spójnej konfiguracji sześciu elementów:

Przypisania użytkowników lub grup do polityki SSL VPN.
Globalnej konfiguracji protokołu, certyfikatu, bramy, zakresu dzierżawy i DNS.
Świadomego wyboru między Split Tunnel a Use as default gateway.
Zezwolenia na ruch ze strefy VPN za pomocą precyzyjnych reguł zapory.
Zabezpieczenia VPN Portal, uwierzytelniania, MFA i Device Access.
Dystrybucji aktualnego profilu .ovpn lub w systemie Windows pliku provisioningowego .pro oraz wykonania pozytywnych i negatywnych testów dostępu.

⚠️ SSL VPN jest publicznie osiągalnym punktem dostępu. MFA i silne hasła nie zastępują precyzyjnych grup użytkowników, Local Service ACLs, reguł zapory, aktualnych profili, logów ani regularnych przeglądów.

Ten artykuł opisuje konfigurację po stronie zapory. Instalację przedstawiono osobno dla systemów Windows, macOS, iPhone i iPad, Android oraz Linux. W podjęciu wcześniejszej decyzji między SSL VPN, IPsec i ZTNA pomaga artykuł Sophos Connect czy SSL VPN.

Przygotowanie wymagań i obiektów

Przed konfiguracją trzeba ustalić sposób publicznego dostępu, uprawnionych użytkowników i cele wewnętrzne:

aktualna wersja SFOS i aktualny klient Sophos Connect;
publiczna nazwa FQDN lub publiczny adres IP;
certyfikaty dla tunelu SSL VPN i VPN Portal;
użytkownicy lub grupy oraz serwery uwierzytelniające;
metoda MFA dla portalu i tunelu;
niekolidujący zakres dzierżawy SSL VPN;
wewnętrzne sieci docelowe, serwery DNS i domena wyszukiwania;
decyzja między Split Tunnel a Full Tunnel;
proces dystrybucji profili i aktualizacji klientów.

Cele wewnętrzne tworzy się najpierw jako hosty lub obiekty sieciowe:

Hosts and services > IP host

W dalszym przykładzie używane są następujące obiekty:

LAN_Server: 10.10.10.0/24 dla serwerów wewnętrznych;
LAN_Client: 10.10.20.0/24, jeśli użytkownicy zdalni rzeczywiście potrzebują dostępu do tej sieci klienckiej;
DNS_Internal: 10.10.10.10 dla wewnętrznego DNS lub kontrolera domeny;
SSLVPN_Users: grupa użytkowników dla Policy members.

Nie należy udostępniać całych sieci wewnętrznych, jeśli wystarczą pojedyncze serwery lub podsieci. Serwery DNS również wymagają jednoznacznego obiektu, aby później można było prześledzić trasę i regułę zapory.

Konfiguracja globalnych ustawień SSL VPN

Ustawienia globalne obowiązują dla wszystkich polityk zdalnego dostępu SSL VPN i są częścią konfiguracji .ovpn:

Remote access VPN > SSL VPN > SSL VPN global settings

Te wartości są również używane przez połączenia SSL Site-to-Site między dwiema Sophos Firewall. Po zmianie portu, protokołu, certyfikatu lub Override hostname trzeba więc sprawdzić zarówno profile Remote Access, jak i istniejące tunele SSL Site-to-Site, a następnie ponownie rozprowadzić ich konfigurację.

Protokół, certyfikaty, brama i port

SSL VPN obsługuje TCP i UDP. UDP jest zwykle wydajniejszym wyborem początkowym; TCP może być przetestowaną alternatywą, gdy sieci zewnętrzne blokują UDP. Wybrane ustawienie należy sprawdzić w rzeczywistych sieciach hotelowych, komórkowych i gościnnych.

Domyślny port SSL VPN to 8443, a VPN Portal używa domyślnie portu 443. Najbardziej przejrzyste jest użycie unikatowej kombinacji adresu WAN IP, portu i protokołu dla każdej publicznie dostępnej usługi.

Sophos rozdziela dwa certyfikaty:

SSL server certificate w globalnych ustawieniach SSL VPN uwierzytelnia serwer tunelu.
Certyfikat HTTPS dla VPN Portal wybiera się w obszarze Administration > Admin and user settings.

Oba certyfikaty powinny pasować do używanej publicznej nazwy FQDN. W przypadku certyfikatów z zewnętrznego urzędu CA musi być dostępny także wymagany łańcuch certyfikatów.

Override hostname określa nazwę FQDN lub publiczny adres IP w profilu klienta. Ma to szczególne znaczenie przy nadrzędnym NAT, wielu interfejsach WAN lub DDNS. Jeśli pole pozostanie puste, profil może zawierać adresy wielu interfejsów. Sophos Connect nadaje pierwszeństwo bramom DDNS, a pozostałe wpisy sprawdza w odwrotnej kolejności; jedna jednoznaczna nazwa FQDN jest więc łatwiejsza do testowania i utrzymania.

VPN Portal i SSL VPN mogą technicznie korzystać z tego samego portu i protokołu. Ustawienia Login Security nie działają wtedy zgodnie z założeniem, a VPN Portal staje się dostępny ze stref, w których włączono SSL VPN. WAF musi różnić się od VPN Portal adresem WAN IP lub portem, a od SSL VPN adresem WAN IP, portem lub protokołem. Dalsze zależności opisuje artykuł Sophos Firewall WAF.

Zakres dzierżawy i DNS

Zakres dzierżawy IPv4 musi być prywatny i nie może kolidować z sieciami wewnętrznymi, VPN typu site-to-site, trasami statycznymi, innymi pulami Remote Access ani popularnymi sieciami domowymi. Często spotykane przykłady to 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, 10.0.0.0/24 i 10.0.1.0/24.

W tym miejscu SFOS akceptuje dla IPv4 maksymalnie sieć /24; mniejszych sieci, takich jak /25, nie można wybrać. Dostępu nie ogranicza się sztucznie małą pulą, lecz polityką i regułami zapory. W regułach używa się hostów systemowych ##ALL_SSLVPN_RW, a dla IPv6 ##ALL_SSLVPN_RW6.

W polu IPv4 DNS wprowadza się wewnętrzne serwery DNS. Domain name zawiera domenę wyszukiwania dodawaną do krótkich nazw hostów. Przy Split Tunnel serwer DNS lub jego sieć muszą także znajdować się w Permitted network resources i być osiągalne przez regułę zapory ze strefy VPN. Przy Full Tunnel znika trasa Split Tunnel, lecz reguła zapory nadal jest wymagana.

Jeśli sama zapora działa jako resolver DNS, należy zamiast tego zezwolić na DNS dla strefy VPN w Administration > Device access. Oddzielny test po adresie IP i po nazwie hosta pozwala odróżnić problemy z routingiem od problemów z DNS.

Statyczne adresy IP, równoległe sesje i wartości czasowe

Statyczne adresy IP SSL VPN można stosować w uzasadnionych przypadkach szczególnych, na przykład dla starszej aplikacji z autoryzacją opartą na adresie IP, i muszą mieścić się w skonfigurowanej do tego puli. Użytkownik ze statycznym adresem IP SSL VPN nie może jednak nawiązywać równoległych sesji Remote Access.

Niezależnie od tego ustawienie Simultaneous logins w Authentication > Services lub bezpośrednio przy lokalnym użytkowniku ogranicza liczbę równoległych logowań. Wartość globalna obowiązuje tylko użytkowników utworzonych później.

Key lifetime określa moment ponownego uzgadniania kluczy i nie jest czasem bezczynności ani maksymalnym czasem sesji. Połączeniami bezczynnymi sterują globalne ustawienia idle i opcjonalnie Disconnect idle clients w polityce. Przy nieoczekiwanych rozłączeniach trzeba osobno sprawdzić te wartości, statyczne przypisanie adresu IP, równoległe logowania i logi.

Tworzenie polityki SSL VPN

Politykę można utworzyć ręcznie lub za pomocą asystenta:

Remote access VPN > SSL VPN

Asystent wyświetla ustawienia globalne tylko do kontroli i nie pozwala ich zmienić. Tworzy politykę, ustawia wybrane uwierzytelnianie oraz Device Access dla VPN Portal i SSL VPN, a także tworzy regułę zapory. W istniejących środowiskach bardziej przejrzysta jest zwykle opcja Configure manually:

Wybrać Add > Configure manually.
Jako Name wpisać na przykład SSLVPN-Remote-Users.
W Policy members wybrać grupę SSLVPN_Users.
Wybrać Split Tunnel albo Use as default gateway.
Przy Split Tunnel wybrać LAN_Server i DNS_Internal jako Permitted network resources.
Opcjonalnie ustawić Disconnect idle clients i Override global timeout.
Zapisać i sprawdzić konfigurację przy użyciu zwykłego członka grupy docelowej.

Użytkownicy i grupy gościnne nie mogą być używani jako Policy members. Jeśli użytkownik lub grupa znajduje się już w starszej polityce SSL VPN, SFOS usunie przypisanie z wcześniejszej polityki. Przed zapisaniem należy więc sprawdzić nakładanie się polityk.

Ustawienie Override global timeout dla konkretnej polityki działa tylko wtedy, gdy jest mniejsze od globalnej wartości idle. Większa wartość nie znosi globalnego ograniczenia.

Split Tunnel albo Full Tunnel

Przy Split Tunnel przez VPN kierowane są wyłącznie sieci IPv4 i IPv6 oraz obsługiwane cele FQDN wybrane w Permitted network resources. Cele FQDN są obsługiwane tylko dla IPv4. Pozostały ruch internetowy pozostaje lokalny. Zmniejsza to obciążenie zapory i opóźnienia, ale wymaga precyzyjnego planowania zasobów i DNS.

Jeśli zmieni się adres IP dozwolonego celu FQDN, istniejące tunele nie są aktualizowane automatycznie. Użytkownicy muszą się rozłączyć i połączyć ponownie.

Przy Full Tunnel włącza się Use as default gateway. Cały ruch użytkownika przechodzi wtedy przez zaporę. Permitted network resources nie są w tym trybie wymuszane jako ograniczenie dostępu. Cele wewnętrzne i Services trzeba ograniczyć regułami zapory, a dostęp IPv4 do Internetu wymaga dodatkowo odpowiedniej reguły SNAT/MASQ.

Full Tunnel umożliwia centralną kontrolę ruchu webowego, DNS i logów, ale zwiększa zapotrzebowanie na przepustowość, obciążenie zapory oraz nakład związany z prywatnością i pomocą techniczną. Tryb należy więc przetestować z rzeczywistymi aplikacjami i równoczesnymi użytkownikami.

Reguły zapory, Device Access i uwierzytelnianie

Reguły zapory i DNS

Samo zestawienie tunelu nie umożliwia jeszcze dostępu do zasobów wewnętrznych. Potrzebna jest do tego reguła:

Rules and policies > Firewall rules

Przykład dla Split Tunnel:

Rule name: VPN_SSLVPN_to_Internal_Servers
Action: Accept
Source zone: VPN
Source networks and devices: ##ALL_SSLVPN_RW
Destination zones: LAN
Destination networks: LAN_Server, DNS_Internal
Services: tylko wymagane usługi aplikacyjne i DNS
Log firewall traffic: włączone

Reguła powinna znajdować się nad szerszymi regułami VPN. Negatywny test połączenia z niedozwolonym celem pokaże, czy ogólna reguła umieszczona niżej nie zezwala niezamierzenie na dostęp.

Dla IPv4 Full Tunnel potrzebna jest dodatkowo reguła z VPN do WAN i odpowiednia reguła SNAT/MASQ. IPv6 wymaga natomiast świadomie skonfigurowanego routingu IPv6 oraz osobnych reguł zapory IPv6. Przy braku dostępu pomagają Log Viewer, Rule ID i instrukcja testowania reguł zapory.

VPN Portal, Device Access i MFA

Portal, usługi lokalne i uwierzytelnianie sprawdza się w oddzielnych miejscach:

Administration > Admin and user settings
Administration > Device access
Authentication > Services
Authentication > Multi-factor Authentication

Wymagane jest co najmniej:

SSL VPN w strefach, z których można zestawiać tunel;
VPN Portal tylko w rzeczywiście potrzebnych strefach;
DNS w strefie VPN tylko wtedy, gdy zapora działa jako resolver;
właściwe VPN portal authentication methods;
właściwe SSL VPN authentication methods;
MFA dla portalu i tunelu.

Zwykłe reguły zapory nie sterują tymi usługami lokalnymi. Węższe sieci źródłowe, pojedyncze adresy IP lub kraje konfiguruje się za pomocą Local Service ACL Exception Rules. Pełną procedurę zabezpieczenia opisuje Device Access i Local Service ACL.

Third-party Threat Feeds mogą blokować także ruch skierowany do systemowych usług VPN. Pozwala to dodatkowo blokować znane niepożądane źródła; konfigurację i ograniczenia opisano w artykule Threat Feeds na Sophos Firewall.

VPN portal authentication methods sterują logowaniem do portalu i pobieraniem profili, a SSL VPN authentication methods — właściwym logowaniem do tunelu. WebAdmin jest oddzielnym interfejsem administracyjnym i nie trzeba udostępniać go ze strefy WAN na potrzeby SSL VPN.

W przypadku Microsoft Entra ID ten sam serwer Entra musi być wybrany dla VPN Portal i SSL VPN. Pełną konfigurację przedstawiono w artykule Microsoft Entra ID SSO dla Sophos Connect.

VPN Portal nie obsługuje uwierzytelniania RADIUS z Challenge-MFA. Sophos Connect także nie obsługuje wyzwania OTP, lecz przesyła hasło i OTP razem; obsługiwane są metody call i push. Wybraną metodę trzeba przetestować ze zwykłym użytkownikiem pilotażowym. Dalsze podstawy opisano w artykule MFA dla Sophos Firewall.

Dystrybucja i aktualizacja profilu klienta

Po ręcznym zaimportowaniu pliku .ovpn zmiany globalne mające wpływ na profil wymagają ponownego pobrania i importu. Dotyczy to w szczególności protokołu, portu, interfejsu, certyfikatu serwera i innych wartości globalnej konfiguracji SSL VPN. Aktualizacja Sophos Connect nie zastępuje nieaktualnego profilu.

Po zmianie Override hostname lub portu należy sprawdzić na kliencie, czy ponownie zaimportowany profil rzeczywiście korzysta z nowej nazwy bramy i nowego portu.

Po zmianie Policy members, Permitted network resources lub adresu IP celu FQDN zwykle wystarczy rozłączenie i ponowne połączenie. Zmiany te nie wymagają pobrania nowego pliku .ovpn.

Plik provisioningowy .pro jest obsługiwany tylko w systemach Windows 10 i 11. Automatycznie pobiera dostępne dla użytkownika konfiguracje IPsec i SSL VPN oraz ich późniejsze zmiany. Jeśli zmieni się gateway provisioningu lub port VPN Portal, trzeba także zmienić i ponownie rozprowadzić plik .pro. Podczas pierwszego wdrożenia logowanie może pojawić się dwa razy: najpierw w celu pobrania profilu, a następnie w celu zestawienia tunelu.

Jeśli plik .pro udostępnia tylko połączenie IPsec albo nie udostępnia konfiguracji SSL VPN, należy najpierw sprawdzić Policy members, członkostwo w grupie, osiągalność VPN Portal i uwierzytelnianie.

Po włączeniu lub zmianie Microsoft Entra ID SSO klient musi używać aktualnej konfiguracji. Entra SSO w Sophos Connect jest scenariuszem dla systemu Windows od wersji klienta 2.4.

Nazwy profili powinny być jednoznaczne. Po zmianie bramy lub użytkownika należy usunąć stare wpisy połączeń i sprawdzić dystrybucję przy użyciu zwykłego użytkownika docelowego. Informacje o wersjach klienta znajdują się w artykule Bezpieczna aktualizacja Sophos Connect.

Testowanie konfiguracji i lokalizowanie błędów

Test odbiorczy

Pełny test wykorzystuje zwykłego użytkownika pilotażowego i jeden konkretny cel wewnętrzny:

Użytkownik widzi w VPN Portal dokładnie oczekiwaną konfigurację SSL VPN.
MFA jest testowane z prawidłowym i nieprawidłowym czynnikiem.
Importuje się .ovpn lub .pro i sprawdza przydzielony adres dzierżawy.
Przy Split Tunnel kontroluje się trasę do LAN_Server i DNS_Internal.
Cel wewnętrzny testuje się najpierw po adresie IP, a następnie po nazwie hosta.
Uruchamia się dozwoloną usługę i sprawdza Firewall Rule ID w Log Viewer.
Wywołuje się niedozwolone połączenie i potwierdza drop.
Przy Full Tunnel dodatkowo sprawdza się publiczny dostęp do Internetu, DNS, Web Policy i IPv4-SNAT.
Po zmianie polityki lub FQDN rozłącza się tunel, łączy ponownie i powtarza ten sam test.

Każdy test powinien zawierać czas, użytkownika i grupę, platformę oraz wersję klienta, sieć źródłową, cel i usługę. Jeśli testuje tylko administrator, błędy grup, MFA i polityk łatwo pozostają niezauważone.

Logi według etapu błędu

Najpierw należy ustalić, czy błąd występuje podczas dostępu do portalu, uwierzytelniania, zestawiania tunelu, czy dopiero podczas dostępu do celu:

VPN Portal: vpnportal.log
Zwykłe uwierzytelnianie: access_server.log
Microsoft Entra SSO: oauth_sso_vpn.log
Certyfikaty SSL VPN właściwe dla użytkownika: peruser_cert_sslvpn.log
Usługa SSL VPN: sslvpn.log
Aktywne połączenia: openvpn-status*.log
Ruch do celu: log zapory, Rule ID i w razie potrzeby Packet Capture

W Packet Capture status Incoming potwierdza tylko, że zapora odebrała pakiet. Przy Forwarded bez odpowiedzi należy sprawdzić trasę zwrotną, NAT, system docelowy i jego lokalną zaporę.

Powiązanie dalszych procesów i plików opisano w artykule Sophos Firewall Services i logi.

Typowe objawy błędów

Brak pliku .ovpn lub pusty plik w VPN Portal: Artykuł Rozwiązywanie problemu z brakującym lub pustym plikiem OVPN rozróżnia błędy policy, User ID, certyfikatu, pamięci masowej, firmware i HA. Konta gościnne są niedozwolone. Sophos Connect obsługuje wyłącznie nazwy użytkowników ASCII; nazwa użytkownika i domena mogą mieć łącznie najwyżej 51 znaków.
Logowanie nie powiedzie się: porównać access_server.log, vpnportal.log lub oauth_sso_vpn.log z czasem testu. Przy Entra sprawdzić ten sam serwer dla portalu i SSL VPN oraz pełny łańcuch certyfikatów.
Tunel działa, ale brakuje celów wewnętrznych: sprawdzić trasę na endpoincie, Permitted Resources przy Split Tunnel, regułę zapory, trasę zwrotną, zaporę celu i kolizję z lokalną siecią domową.
Adres IP działa, nazwa hosta nie: sprawdzić serwer DNS, domenę wyszukiwania, trasę Split Tunnel, regułę zapory dla DNS, lokalny DoH lub DNS endpointa i ewentualnie Device Access dla DNS.
Problem dotyczy tylko niektórych użytkowników: porównać członkostwo w grupie, przypisanie polityki, MFA, statyczny adres IP, Simultaneous logins i załadowany profil.
Problem dotyczy tylko starych klientów: po zmianach globalnych zaimportować aktualny plik .ovpn. Po samych zmianach polityki lub FQDN najpierw połączyć się ponownie i sprawdzić załadowany routing.
Full Tunnel bez Internetu: sprawdzić regułę z VPN do WAN, IPv4-SNAT, DNS oraz zastosowane polityki webowe i bezpieczeństwa.
Duże transfery zawieszają się: jeśli małe połączenia działają, sprawdzić MTU i MSS na rzeczywistej ścieżce. Służy do tego procedura MTU i MSS przy problemach z VPN.
Połączenie kończy się po dłuższym czasie: porównać czas rozpoczęcia i przerwania z Idle Timeout, Disconnect idle clients i Key lifetime. Sprawdzić statyczny adres IP i Simultaneous logins, w razie potrzeby przydzielić użytkownikowi pilotażowemu adres dynamiczny i przeanalizować sslvpn.log oraz openvpn-status*.log w czasie testu.
Tunel nie zestawia się dla żadnego użytkownika: oprócz Device Access i udostępnienia portu wyszukać szeroką regułę DNAT z Original destination: Any i Services: Any albo portem SSL VPN, która wcześniej przechwytuje próbę połączenia.
WAF, portal lub SSL VPN kolidują: porównać adres WAN IP, port i protokół wszystkich usług lokalnych oraz reguł WAF. Współdzielone kombinacje mogą powodować dodatkową ekspozycję portalu lub brak Login Security.

W codziennej eksploatacji należy regularnie sprawdzać grupy, MFA, przypisania statycznych adresów IP, ważność certyfikatów, zakres dzierżawy, Device Access, reguły zapory, dystrybucję profili i logi. Nowe wersje SFOS i Sophos Connect zatwierdza się najpierw z użytkownikiem pilotażowym oraz pozytywnym i negatywnym testem celu.