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ę.

Przed zmianą globalnych wartości profilu trzeba udokumentować Protocol, Port, Override hostname, SSL server certificate, wartości dzierżawy i DNS oraz konfigurację objętych zmianą peerów SSL Site-to-Site. W planie mechanizmu rezerwowego należy też uwzględnić pośredniczący NAT lub przekierowania portów. Jeśli test odbiorczy nie powiedzie się, należy przywrócić te wartości i poprzednią konfigurację Site-to-Site, a następnie powtórzyć ze starym profilem testy portalu, tunelu oraz dostępu dozwolonego i blokowanego.

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 wybrany w globalnych ustawieniach SSL VPN jest używany przez serwer SSL VPN.
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.

Dokumentacja SFOS 22 zawiera sprzeczne informacje o dozwolonym prefiksie mniejszych pul IPv4. Pomoc pola podaje /24 jako limit i stwierdza, że podsieci /25 lub mniejszych nie można wybrać, natomiast aktualne FAQ opisuje także mniejsze podsieci rozdzielane wewnętrznie między wiele instancji OpenVPN. Rozstrzygająca jest zatem używana wersja SFOS: trzeba sprawdzić, jaki prefiks oferuje jej interfejs, a następnie zweryfikować rzeczywistą liczbę dostępnych dzierżaw.

Według FAQ Sophos liczba równoczesnych instancji SSL VPN zależy od CPU w modelu firewalla. Każda instancja tworzy interfejs tun0 i wymaga własnej podsieci do routingu oraz wewnętrznego rozdzielania ruchu. SFOS dzieli skonfigurowaną pulę; te adresy są zużywane przed przydzielaniem dzierżaw klientom. FAQ ilustruje to siecią 192.168.0.0/27, ośmioma równoczesnymi instancjami i tylko jednym pozostałym adresem IP do dzierżawy. Nie jest to uniwersalna pojemność ani zalecana sieć przykładowa: sprawdź rzeczywiste dzierżawy na docelowym buildzie i modelu; opisany wyżej konflikt pomocy pola z FAQ pozostaje.

SFOS 23: Dostępny do wyboru zakres IPv4 zależy od modelu firewalla; większe modele obsługują podsieci z większą liczbą adresów IP. Pomoc SFOS 23 podaje /24 jako najmniejszą podsieć dostępną do wyboru. Jest to ograniczenie wyboru zależne od modelu, a nie gwarancja konkretnej liczby dzierżaw dla klientów. Wewnętrzny podział zależny od CPU wyjaśnia zużycie adresów, ale nie obsługiwane zakresy wyboru. Nie rozwiązuje to konfliktu SFOS 22 ani nie zmienia ilustracji /27 w zalecenie konfiguracji.

Przed zmianą zapisz build SFOS, model, poprzedni zakres i przypisania statyczne oraz zachowaj poprzednie wartości na potrzeby wycofania zmiany. W interfejsie wybierz tylko zakres obsługiwany przez model docelowy, utrzymuj statyczne adresy użytkowników w wynikowym zakresie statycznym i sprawdź rzeczywiście dostępne dzierżawy. Następnie połącz ponownie użytkownika pilotażowego i przetestuj dzierżawę, DNS oraz dozwolone i blokowane cele. Jeśli testy odbiorcze się nie powiodą, przywróć poprzednie wartości i przypisania oraz powtórz testy. Jeśli build, interfejs, pomoc lub FAQ są sprzeczne, zatrzymaj zależne od tego wdrożenie większej pojemności do wyjaśnienia z pomocą techniczną; nie wymuszaj maski.

API XML SFOS 23 – status 551: Surowy wiersz statusu dla Configure SSLVPN Tunnel Access odwołuje się do nierozstrzygniętego identyfikatora środowiska wykonawczego Message.SSLVPNInvalidLeaseIPv4Mask. Nie pozwala to ustalić potwierdzonego brzmienia komunikatu, pewnej przyczyny odrzucenia ani nowego obsługiwanego zakresu masek. Jeśli API zwróci 551, zachowaj pełną odpowiedź i poprzednie ustawienia. Przed każdą zmianą sprawdź StartIP, SubnetMask oraz wybór puli obsługiwany przez zainstalowany build i model, korzystając z pomocy zatwierdzonej dla tego środowiska lub konsultując się z Sophos Support; nie wymuszaj maski.

Po obsługiwanej korekcie sprawdź odpowiedź API, ustawienia faktycznie zapisane na docelowej zaporze i dzierżawę ponownie połączonego użytkownika pilotażowego. Zachowaj poprzednie wartości i przypisania na potrzeby wycofania zmiany opisanego powyżej. Jeśli diagnoza lub brzmienie komunikatu nadal mają znaczenie dla zatwierdzenia i pozostają niewyjaśnione, pozostaw wdrożenie w oczekiwaniu.

Mała pula nie jest zabezpieczeniem dostępu; do tego służą polityka i reguły 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, jej właściwy adres należy wprowadzić w IPv4 DNS. Dodatkowo trzeba 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.

Disconnect dead peer after to globalna wartość podawana w sekundach, która zamyka połączenia klientów nieodpowiadających. Wartości domyślne wynoszą 180 sekund dla TCP i 100 sekund dla UDP; dla UDP SFOS przyjmuje wartości od 60 do 110. Disconnect idle peer after jest natomiast podawane w minutach i zamyka rzeczywiście bezczynne sesje. Przed zwiększeniem wartości należy na podstawie sslvpn.log, logu klienta i danych o utracie pakietów ustalić, który timer faktycznie zadziałał.

Ustawienie Override global timeout w polityce może jedynie skrócić globalny limit bezczynności. Jeżeli wartość polityki jest wyższa, nadal obowiązuje wartość globalna. Starsza strona Sophos dotycząca rozwiązywania problemów zaleca dla pojedynczych użytkowników wyższą wartość w polityce, ale aktualna pomoc pól SFOS 22 wyraźnie temu przeczy. Aby zezwolić na dłuższe sesje, nie należy bezskutecznie zwiększać wartości w polityce; trzeba dostosować wartość globalną po ocenie wpływu i ponownie przeprowadzić test z tą samą grupą użytkowników.

Tworzenie polityki SSL VPN

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

Remote access VPN > SSL VPN

Sophos zaleca asystenta szczególnie przy tworzeniu pierwszej polityki SSL VPN. Wyświetla on ustawienia globalne tylko do kontroli i nie pozwala ich zmienić. Stosuje wybrane serwery i metody uwierzytelniania, konfiguruje Device Access dla VPN Portal i SSL VPN oraz tworzy politykę i regułę zapory. Przy pierwszym użyciu tworzy grupę reguł Automatic VPN rules na początku tabeli reguł i włącza nową regułę. Kolejne reguły asystenta trafiają na koniec tej grupy. Po każdym uruchomieniu trzeba sprawdzić ich położenie i Rule ID, która faktycznie pasuje. W istniejących środowiskach bardziej przejrzysta jest często 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. Należy używać obiektów sieciowych lub hostów, a nie interfejsów: wybranie interfejsu nie gwarantuje dostępu do jego podsieci.
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.

Jeśli metoda uwierzytelniania zawiera wiele serwerów, SFOS odpytuje je w wyświetlanej kolejności. Dla jednej metody można wybrać maksymalnie 20 serwerów. Przy identycznych nazwach użytkowników lub mechanizmie rezerwowym trzeba sprawdzić, który serwer faktycznie przetwarza żądanie.

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.

Web proxy zapory jest przypadkiem szczególnym: przechodzące przez niego żądania HTTP i HTTPS są traktowane jako wewnętrzne na potrzeby usług lokalnych. Użytkownicy z dostępem do proxy mogą więc osiągnąć VPN Portal, nawet jeśli nie jest włączony dla ich strefy źródłowej. Przy użyciu proxy tę osiągalność należy sprawdzić osobno, zamiast polegać wyłącznie na macierzy stref w Device Access.

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.

SSO według wersji SFOS: W SFOS 22 skonfiguruj Microsoft Entra ID z Server type: Microsoft Entra ID SSO. W SFOS 23 otwórz Authentication > Servers > Add, wybierz Server type: OpenID Connect, a następnie IdP vendor: Microsoft Entra ID lub IdP vendor: Google Workspace. Konfigurację aplikacji, serwera, Redirect URIs i grup opisują odpowiednio Microsoft Entra ID SSO dla Sophos Connect i Google Workspace OIDC na Sophos Firewall. Te warianty wersji nie potwierdzają dostępności GA żadnego buildu.

Przed pobraniem profilu wybierz ten sam skonfigurowany serwer IdP w Authentication > Services dla VPN portal authentication methods i SSL VPN authentication methods, a następnie kliknij Apply dla każdej usługi; w SFOS 22 jest to ten sam serwer Entra. Porównaj pełny Redirect URI u wybranego dostawcy, wraz z FQDN, portem i ścieżką, oraz sprawdź wymagane punkty końcowe logowania. Udane SSO nie zastępuje członkostwa w grupach, Policy members ani wąsko ograniczonych reguł firewalla. Przed przełączeniem zachowaj przypisania usług, kolejność serwerów i działające profile. Po zmianach SSO ponownie pobierz i zaimportuj aktualną konfigurację, a następnie ze zwykłym użytkownikiem pilotażowym przetestuj portal, tunel, MFA u IdP, DNS oraz dozwolone i blokowane cele. W razie błędów przywróć zapisane przypisania usług, kolejność i odpowiadające im profile oraz powtórz te same testy; nie usuwaj poprzedniej metody dostępu przed pomyślnym odbiorem.

W przypadku natywnego OTP SFOS należy wybrać docelowych użytkowników lub grupy w Authentication > Multi-factor authentication, a następnie w Require MFA for włączyć zarówno VPN portal, jak i SSL VPN remote access. Przy Generate OTP token with next sign-in użytkownik musi najpierw zeskanować kod QR w VPN Portal; dopiero potem można rozpocząć test tunelu.

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

Jeśli zmienią się globalne wartości mające wpływ na profil, takie jak protokół, port, interfejs, certyfikat serwera lub Override hostname, należy ponownie pobrać aktualny plik .ovpn z VPN Portal, rozprowadzić go w bezpieczny sposób, a przy ręcznym wdrożeniu ponownie zaimportować w kliencie. Update policy nie jest tutaj pierwszym krokiem i nie zastępuje ręcznego ponownego importu. Udokumentowane zastosowanie dotyczy połączenia skonfigurowanego przez provisioning za pomocą .pro: po zmianie portu SSL VPN lub protokołu należy dla tego połączenia uruchomić Update policy; pozostałe zmiany konfiguracji ten mechanizm provisioningu pobiera automatycznie. Przy zmianach dotyczących na przykład portu, bramy, certyfikatu serwera lub protokołu może być wymagane ponowne logowanie. Aktualizacja oprogramowania Sophos Connect nie zastępuje nieaktualnego profilu. Należy bezpiecznie zachować sprawdzony, działający profil i odpowiadające mu globalne wartości konfiguracji zapory na potrzeby wycofania zmian; przed szeroką dystrybucją należy z użyciem zwykłego użytkownika pilotażowego sprawdzić nowo zaimportowany profil pod kątem bramy/portu, uwierzytelniania/MFA, tras, DNS oraz dostępu do dozwolonych i zablokowanych zasobów docelowych. Jeśli weryfikacja odbiorcza nie powiedzie się, należy przywrócić odpowiadające sobie poprzednie wartości i sprawdzony, działający profil, a następnie powtórzyć te same kontrole.

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. Dozwolone sieci nie są zapisane statycznie w pliku .ovpn; SFOS dodaje zasoby właściwe dla użytkownika podczas zestawiania tunelu. Zmiany te nie wymagają więc pobrania nowego pliku .ovpn.

.pro pobiera IPsec (.scx) i konfiguracje SSL VPN dozwolone dla użytkownika (.ovpn) przez VPN Portal, a także późniejsze zmiany; sam nie jest profilem tunelu. Obsługiwane są zgodne klienty Windows oraz Sophos Connect dla macOS od 2.1, ale nie klient macOS 2.0 ani starszy. Provisioning IPsec wymaga Sophos Connect 2.1 lub nowszego. W kliencie macOS 2.0 nadal konieczne są bezpośredni import i kontrolowane ręczne aktualizacje.

Jeśli zmieni się gateway provisioningu lub vpn_portal_port, trzeba także zmienić i ponownie rozprowadzić plik .pro. Starsze pole user_portal_port jest akceptowane wyłącznie ze względu na zgodność. Podczas pierwszego wdrożenia z OTP lub inną metodą MFA 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.

Dla provisioningu SSO z .pro w Windows z Sophos Connect 2.4 lub nowszym SFOS 22 opisuje Entra ID; SFOS 23 obsługuje dostawców tożsamości OIDC wspieranych w tym scenariuszu, a nie dowolnych dostawców. W Authentication > Services VPN Portal, IPsec VPN i SSL VPN muszą używać tego samego skonfigurowanego serwera IdP. gateway zawiera tylko FQDN lub adres IP firewalla z sekcji Redirect URI tego serwera, a nie pełny URI wywołania zwrotnego; port portalu ustawia się osobno w vpn_portal_port. W zakresie SSO macOS z Sophos Connect 2.1 lub nowszym pozostaje tutaj ograniczony do Entra ID, bez rozszerzenia na ogólną obsługę OIDC; nadal obowiązuje opisane poniżej potwierdzenie wsparcia przed wdrożeniem. Poniższy artykuł o provisioningu wyjaśnia wymagania zależne od dostawcy i wersji.

Provisioning Sophos Connect z .pro i GPO opisuje pełną strukturę JSON, pola MFA, wybór bram i dystrybucję przez GPO.

W przypadku Google Workspace SSO ta instrukcja dotyczy tylko Windows z Sophos Connect 2.4 lub nowszym; wskazówki Entra dla macOS nie mają zastosowania do Google. Dla Entra strony przeglądowe podają macOS od 2.1, nie 2.0, natomiast strony wymagań podają tylko Windows od 2.4. Ta sprzeczność pozostaje nierozstrzygnięta także w podlinkowanym artykule szczegółowym: zatrzymaj wdrożenie macOS do czasu osobnego potwierdzenia i przetestowania obsługi docelowego buildu, platformy/wersji klienta oraz wymaganego typu VPN. Dla każdej zatwierdzonej ścieżki sprawdź zgodne ustawienia SFOS, aktualną konfigurację klienta, metody uwierzytelniania i Redirect URI; przetestuj MFA u IdP. Nie gwarantuje się identycznego przebiegu w przeglądarce ani możliwości zastosowania wdrożenia GPO Windows na macOS.

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.

SSL VPN z Sophos Connect: Windows 10/11; klient macOS 2.0 na macOS 13+, a klient 2.1 lub nowszy na macOS 14+. Linux, iOS i Android używają zgodnego klienta OpenVPN.

W sekcji Current activities > Remote users można filtrować zalogowanych użytkowników zdalnych według Connection date, Username, Source IP address i Leased IP address. Kolumna Mode rozróżnia trzy stany:

SSL VPN (remote access): zestawiony tunel dostępu zdalnego
User portal (clientless access): logowanie do portalu użytkownika należącego do polityki clientless SSL VPN
User portal: logowanie do portalu bez takiego członkostwa

Wpis portalu nie potwierdza więc zestawienia tunelu SSL VPN. Disconnect kończy wybraną sesję. Przed testem wsparcia lub odbioru należy zapisać użytkownika, adresy, tryb i czas.

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 w SFOS 22: oauth_sso_vpn.log; dla SFOS 23 użyj wskazówek dotyczących logów dla danej wersji w odpowiednim artykule szczegółowym Entra lub Google.
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ę.

W przypadku ruchu TUN logi SFOS mogą wskazywać adres interfejsu TUN jako źródło, a dzierżawiony adres klienta jako cel. Nie oznacza to, że adresy zostały zamienione. Wpis należy interpretować łącznie z użytkownikiem, dzierżawą, kierunkiem ruchu, Rule ID i czasem testu.

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

Żaden użytkownik nie może zestawić tunelu: usługa i limity zalewania

Jeśli problem dotyczy wszystkich użytkowników, przed zmianą zasad, limitów zalewania lub usług należy najpierw wykonać kontrole tylko do odczytu. Należy zapisać czas testu, skonfigurowany protokół i port SSL VPN, bieżące ustawienia DoS oraz informację, czy istnieje co najmniej jedna zasada SSL VPN.

Zaloguj się do CLI, wybierz 5. Device management, a następnie 3. Advanced shell, i sprawdź stan usługi za pomocą polecenia udokumentowanego przez Sophos:
```
service -S | grep sslvpn
```
Usługa musi mieć stan Running. Stan UNREGISTERED oznacza, że nie zarejestrowano żadnej zasady SSL VPN; sprawdź, czy istnieje co najmniej jedna taka zasada. Jeśli zasada istnieje, ale usługa nadal nie ma stanu Running, skoreluj sslvpn.log z czasem testu i zbadaj tę rozbieżność zamiast ponownie uruchamiać usługi bez udokumentowanej procedury.
W sekcji Intrusion prevention > DoS & spoof protection > DoS settings sprawdź włączone opcje i limity zalewania UDP, TCP oraz ICMP/ICMPv6. Do kontroli ruchu tunelowego użyj skonfigurowanego protokołu SSL VPN. SFOS odrzuca ruch SSL VPN i żądania ping po przekroczeniu odpowiedniego limitu zalewania; sam nieudany ping nie jest tego dowodem. Przed utworzeniem wyjątku skoreluj próbę połączenia z dowodami odrzucenia.
Tylko po potwierdzeniu dopasowania do limitu zalewania zapisz istniejącą konfigurację i utwórz w DoS bypass rules możliwie najbardziej zawężoną tymczasową regułę inbound. Przykład Sophos używa odpowiedniego źródłowego adresu IP/maski (lub * tylko wtedy, gdy jest to nieuniknione), adresu dozwolonego zasobu sieciowego jako celu, rzeczywistego protokołu TCP lub UDP, portu źródłowego Any oraz skonfigurowanego portu docelowego SSL VPN (domyślnie 8443). Jeśli test na to pozwala, dodatkowo ogranicz źródło i cel; nie wyłączaj globalnie ochrony przed zalewaniem.
Powtórz te same testy połączenia i dostępu do dozwolonego zasobu, zapisując ich czas. Jeśli reguła obejścia nie wyjaśnia odrzucenia, natychmiast ją usuń. Po diagnozie usuń regułę tymczasową albo formalnie zatwierdź i udokumentuj zawężony wyjątek. Przywróć osobno zmienione limity zalewania do zapisanych wartości, a następnie powtórz testy dostępu dozwolonego i blokowanego.

Żądanie dociera do serwera, ale brakuje odpowiedzi

Jeżeli żądanie klienta SSL VPN bezspornie dociera do dozwolonego zasobu wewnętrznego, ale odpowiedź nie wraca do klienta, należy sprawdzić ścieżkę zwrotną w dwóch etapach: najpierw od zasobu do zapory, a następnie od zapory do przydzielonego adresu SSL VPN. Zielony status tunelu nie pozwala zawęzić tego błędu.

Na zasobie wewnętrznym lub jego routerze sprawdzić, czy ścieżka zwrotna do puli adresów SSL VPN prowadzi przez Sophos Firewall. Konkretna trasa zwrotna jest bardziej przejrzysta niż SNAT. SNAT stosować tylko w wąskim zakresie, gdy nie można wyznaczyć trasy zwrotnej, a wynikająca z tego zmiana adresu źródłowego jest akceptowalna.
Za pomocą Packet Capture potwierdzić, że odpowiedź dociera do zapory. Adres źródłowy, przydzielony adres docelowy, usługa i czas testu muszą odpowiadać pierwotnej próbie dostępu.
W Routing > SD-WAN routes sprawdzić bieżącą Route Precedence i szerokie trasy SD-WAN. SSL VPN należy do kategorii static. Jeżeli sdwan_policyroute znajduje się wcześniej, trasa z zasobem wewnętrznym lub Any jako źródłem oraz Any jako celem i usługą może skierować odpowiedź poza tunel.
Najlepiej zawęzić odpowiednią trasę SD-WAN tak, aby pula adresów SSL VPN nie pasowała już jako cel. Sophos wskazuje alternatywnie wyjątek usługi dla portu i protokołu SSL VPN; ten wariant musi odpowiadać rzeczywistemu projektowi reguł i ruchu.
Globalną Route Precedence zmieniać dopiero po ocenie wpływu. Zmiana dotyczy nie tylko tego połączenia. Przygotować kolejność początkową, dostęp administracyjny i rollback zgodnie z artykułem Route Precedence w Sophos Firewall.
Ponowić dostęp i w przechwyconych pakietach sprawdzić wejście odpowiedzi od zasobu oraz przekazanie jej do przydzielonego adresu. Następnie połączyć się ponownie i powtórzyć test z tą samą aplikacją.

⚠️ Szeroka reguła z Any, ogólna reguła SNAT lub globalna zmiana Route Precedence mogą przenieść widoczny problem i zakłócić inne ścieżki VPN, WAN albo zarządzania. Należy przerwać, jeśli nie potwierdzono ścieżki zwrotnej do zapory lub faktycznie pasującej trasy SD-WAN.

Sieć domowa i wewnętrzna sieć docelowa nakładają się

Jeśli na przykład klient zewnętrzny używa sieci 192.168.1.0/24, a dozwolony zasób wewnętrzny również znajduje się w 192.168.1.0/24, system operacyjny zwykle uznaje cel za lokalny. Pakiet nie trafia wtedy w ogóle do tunelu SSL VPN. Prawidłowym trwałym rozwiązaniem jest zmiana adresacji jednej z tych sieci.

Jeśli nie można zrobić tego od razu, Sophos opisuje ściśle ograniczone obejście z użyciem DNAT. Należy wybrać wolny wirtualny adres docelowy, który nie nakłada się na żadną sieć lokalną, wewnętrzną, VPN, statyczną ani SD-WAN. Przy Split Tunnel adres ten musi zostać przekazany klientowi jako Permitted network resource, po czym wymagane jest ponowne połączenie. Reguła DNAT używa zakresu dzierżaw SSL VPN jako Original source, Original jako Translated source, adresu wirtualnego jako Original destination oraz rzeczywistego hosta wewnętrznego jako Translated destination. Usługi i powiązana reguła zapory z VPN do strefy docelowej pozostają ograniczone do faktycznie potrzebnego dostępu.

Użytkownik łączy się następnie z adresem wirtualnym lub przeznaczoną dla niego nazwą DNS. Log Viewer musi pokazać oczekiwane Firewall Rule ID i NAT Rule ID, a Packet Capture potwierdza translację oraz trasę zwrotną. Nie należy tworzyć całego zakresu zastępczego, jeśli potrzebny jest tylko jeden host. Należy przerwać, jeśli nie ma pewności, że adres wirtualny jest wolny, albo potrzebna byłaby szeroka reguła NAT.

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 i vpnportal.log z czasem testu; dla Entra w SFOS 22 użyć także oauth_sso_vpn.log, a w SFOS 23 wskazówek dotyczących logów OIDC dla danej wersji w odpowiednim artykule szczegółowym. Sprawdzić ten sam serwer IdP dla portalu i SSL VPN, Redirect URIs 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.