Konfiguracja zdalnego dostępu SSL VPN na Sophos Firewall

SSL VPN pozostaje ważnym sposobem zdalnego dostępu na Sophos Firewall, zwłaszcza gdy użytkownicy pracują z hoteli, sieci Wi-Fi dla gości, sieci komórkowych lub restrykcyjnych sieci zewnętrznych. Kluczowe jest nie tylko to, czy tunel zostanie nawiązany, ale także czy zapora prawidłowo ogranicza dostęp, czy DNS działa, czy MFA jest aktywne i czy reguły zapory kontrolują ruch z VPN-zone.

Artykuł opisuje konfigurację zdalnego dostępu SSL VPN na Sophos Firewall. Dla instalacji klienta odpowiednie są Konfiguracja Sophos SSL VPN z Sophos Connect na Windows, Konfiguracja Sophos SSL VPN z Sophos Connect na macOS, Konfiguracja Sophos SSL VPN na iPhone i iPad oraz Konfiguracja Sophos SSL VPN na Android.

Dla podstawowej decyzji między IPsec, SSL VPN, klientami mobilnymi i ZTNA odpowiedni jest Sophos Connect czy SSL VPN: Które rozwiązanie zdalnego dostępu jest odpowiednie?.

Który artykuł o SSL VPN jest odpowiedni?

SSL VPN składa się z konfiguracji zapory, portalu, klienta, uwierzytelniania i późniejszej analizy błędów. W zależności od zadania odpowiedni jest inny punkt startowy:

To rozdzielenie jest ważne: problem użytkownika w VPN Portal, przestarzały profil .ovpn, brakująca reguła zapory i problem z DNS wyglądają dla użytkownika często tak samo. Dla analizy te poziomy muszą być rozdzielone.

Docelowy obraz

Poprawna konfiguracja SSL VPN składa się z kilku elementów:

1. Użytkownicy lub grupy są uprawnieni w odpowiedniej polityce SSL VPN.
2. Globalne ustawienia SSL VPN definiują bramę, port, certyfikat, zakres dzierżawy, DNS i kryptografię.
3. VPN Portal jest dostępny tylko w takim zakresie, jak to konieczne, i chroniony przez MFA.
4. Reguły zapory pozwalają na ruch z VPN-zone tylko do potrzebnych celów.
5. Split Tunnel lub Full Tunnel jest świadomie wybrany.
6. Klienci importują aktualny profil .ovpn.
7. Logi, Packet Capture i dane wsparcia mogą być analizowane w przypadku błędów.

Wiele problemów z SSL VPN wynika z tego, że dokumentowany jest tylko pobieranie klienta. W praktyce trzeba rozważyć portal, uwierzytelnianie, politykę SSL VPN, regułę zapory, DNS i NAT razem.

⚠️ SSL VPN jest publicznie dostępnym punktem wejścia. MFA i silne hasła są ważne, ale nie zastępują ograniczeń przez Device access, wąskie grupy użytkowników, aktualne profile, logowanie i regularne przeglądy.

Wymagania wstępne

Przed konfiguracją należy wyjaśnić następujące kwestie:

• Sophos Firewall z aktualną wersją SFOS.
• Publiczna dostępność zapory lub przekierowanie portów.
• FQDN lub publiczny adres IP dla dostępu VPN.
• Certyfikat dla VPN Portal i SSL VPN, najlepiej pasujący do FQDN.
• Użytkownicy lub grupy dla zdalnego dostępu.
• Serwer uwierzytelniania: lokalny, Active Directory, RADIUS lub Microsoft Entra ID.
• Koncepcja MFA/OTP dla VPN Portal i zdalnego dostępu.
• Wewnętrzne sieci docelowe, serwery DNS i domena wyszukiwania.
• Decyzja o Split Tunnel lub Full Tunnel.
• Reguły zapory dla ruchu z VPN-zone.
• Proces aktualizacji klienta i ponownej dystrybucji pliku .ovpn.

Jeśli ma być używane Microsoft Entra ID SSO, uwierzytelnianie musi być poprawnie przygotowane przed pobraniem konfiguracji VPN. Procedura jest opisana w Konfiguracja Microsoft Entra ID SSO dla Sophos Connect i VPN Portal.

1. Przygotowanie lokalnych obiektów

Najpierw powinny istnieć sieci docelowe jako hosty lub obiekty sieciowe:

Hosts and services > IP host

Typowe obiekty:

Nie należy po prostu udostępniać całych wewnętrznych obszarów sieci, jeśli potrzebne są tylko pojedyncze serwery lub podsieci. Im bardziej precyzyjnie zdefiniowane są obiekty, tym łatwiejsza będzie później reguła zapory.

2. Sprawdzenie globalnych ustawień SSL VPN

Globalne ustawienia dotyczą wszystkich polityk zdalnego dostępu SSL VPN:

Remote access VPN > SSL VPN > SSL VPN global settings

Protokół i port

SSL VPN może używać TCP lub UDP w zależności od konfiguracji. UDP jest często bardziej wydajne, TCP może lepiej działać w restrykcyjnych sieciach. Decyzja powinna być przetestowana w sieciach, z których użytkownicy faktycznie pracują.

Przy wyborze portu należy unikać nakładania się:

• Standardowy port SSL VPN to często 8443.
• VPN Portal używa domyślnie 443 w aktualnych wersjach SFOS.
• Reguły WAF i SSL VPN nie mogą się nakładać na tej samej WAN-IP z tym samym portem i protokołem.
• Jeśli SSL VPN i VPN Portal używają tego samego portu, funkcje bezpieczeństwa logowania mogą nie działać zgodnie z oczekiwaniami.

Jeśli WAF, VPN Portal, User Portal i SSL VPN działają na tej samej WAN-IP, port, protokół i certyfikat powinny być świadomie udokumentowane. Dla podstaw WAF odpowiedni jest Konfiguracja WAF na Sophos Firewall i unikanie typowych błędów.

Certyfikat i Override Hostname

Pod SSL server certificate powinien być używany certyfikat pasujący do publicznego FQDN. Błąd certyfikatu w VPN Portal lub w profilu SSL VPN prowadzi później do niepotrzebnych przypadków wsparcia.

Pod Override hostname określa się, jaką nazwę hosta lub adres IP klienci używają w profilu .ovpn. Jest to szczególnie ważne przy:

• wielu adresach WAN-IP,
• routerze przed zaporą,
• NAT lub przekierowaniu portów przed zaporą,
• dynamicznym WAN-IP z DDNS,
• oddzielnych FQDN dla WebAdmin, VPN Portal i SSL VPN.

Jeśli pole pozostanie puste, w profilu mogą znaleźć się różne adresy interfejsów. Może to działać, ale w środowiskach produkcyjnych często jest mniej jednoznaczne niż czysty FQDN.

Zakres dzierżawy

Sophos Firewall przydziela klientom SSL VPN adresy z skonfigurowanego zakresu dzierżawy. Ten zakres nie może kolidować z wewnętrznymi sieciami, statycznymi trasami, VPNami site-to-site ani typowymi obszarami sieci domowych.

Należy unikać szczególnie popularnych podsieci, takich jak:

• 192.168.0.0/24
• 192.168.1.0/24
• 192.168.2.0/24
• 10.0.0.0/24
• 10.0.1.0/24

Jeśli zakres dzierżawy koliduje z siecią domową użytkownika, tunel czasami łączy się pomyślnie, ale wewnętrzne cele pozostają nieosiągalne. Wydaje się to wtedy problemem z regułą zapory, ale jest to problem z routingiem na końcówce.

Dla reguł zapory należy używać systemowych hostów ##ALL_SSLVPN_RW i przy IPv6 ##ALL_SSLVPN_RW6, a nie ręcznie tworzonych hostów z starymi zakresami dzierżawy.

Statyczne adresy IP SSL VPN i Key Lifetime

Statyczne adresy IP SSL VPN mogą być w niektórych przypadkach użyteczne, na przykład dla dostępu administracyjnego, ściśle logowanych specjalnych dostępów lub starszych aplikacji z uwierzytelnianiem opartym na IP. Jako standard dla wszystkich użytkowników nie są jednak odpowiednie. Im więcej istnieje statycznych przypisań, tym trudniejsza staje się eksploatacja, analiza błędów i późniejsze migracje.

Na liście znanych problemów jest udokumentowany konkretny przypadek: Przy SSL VPN z lokalnym uwierzytelnianiem i statycznie przypisanym adresem IP SSL VPN ponowne uwierzytelnianie po wygaśnięciu Key Lifetime może się nie powieść. Zapora może traktować już przydzielony adres dzierżawy jako konflikt. Użytkownicy muszą wtedy ręcznie ponownie się połączyć, mimo że tunel wcześniej działał. Typowa wartość Key Lifetime to 18000 sekund.

Jeśli użytkownik musi się ponownie logować po kilku godzinach, należy sprawdzić nie tylko MFA, wersję klienta i regułę zapory. Dodatkowo te punkty powinny być uwzględnione w analizie:

• Czy używane jest lokalne uwierzytelnianie dla SSL VPN?
• Czy użytkownik ma statyczny adres IP SSL VPN?
• Czy problem występuje mniej więcej po wygaśnięciu Key Lifetime?
• Czy ten sam użytkownik działa stabilniej z dynamicznym przypisaniem IP?
• Czy statyczny IP jest naprawdę potrzebny, czy wystarczy reguła dla grupy użytkowników, systemowego hosta SSL VPN i logowania?

Jako pragmatyczne środki zaradcze Sophos wymienia dwie opcje: planowanie Key Lifetime tak, aby obejmowało normalny dzień pracy, lub używanie dynamicznego przypisania IP. W wielu środowiskach dynamiczne przypisanie jest czystsze, ponieważ reguły zapory i tak powinny być kontrolowane przez VPN-zone, grupę użytkowników, obiekty docelowe i systemowe hosty SSL VPN.

DNS i Domain Name

Dla wewnętrznego rozwiązywania nazw w globalnych ustawieniach SSL VPN ustawiane są serwery DNS i opcjonalnie nazwa domeny. W środowiskach Active Directory jest to zazwyczaj wewnętrzny serwer DNS lub kontroler domeny.

Dodatkowo pod Administration > Device access DNS z VPN-zone musi być dozwolony, jeśli zapora sama jest używana jako resolver DNS w projekcie VPN.

Jeśli DNS w tunelu nie działa, należy przetestować oddzielnie:

• Czy cel jest osiągalny przez adres IP?
• Czy wewnętrzny serwer DNS jest dozwolony przez regułę zapory?
• Czy klient otrzymuje właściwą domenę wyszukiwania?
• Czy klient faktycznie używa aktualnego profilu .ovpn?
• Czy lokalna konfiguracja DNS lub DoH na końcówce nie przeszkadza?

3. Tworzenie polityki SSL VPN

Politykę tworzy się pod:

Remote access VPN > SSL VPN

Procedura:

1. Wybierz Add.
2. Użyj Configure manually.
3. Nadaj nazwę, na przykład SSLVPN-Remote-Users.
4. Pod Policy members wybierz uprawnionych użytkowników lub grupy.
5. Ustal Split Tunnel lub Full Tunnel.
6. Przy Split Tunnel wybierz Permitted network resources.
7. Opcjonalnie skonfiguruj Disconnect idle clients.
8. Zapisz i przetestuj z użytkownikiem testowym.

Ważne: Jeśli użytkownicy lub grupy są wpisani w nowszej polityce SSL VPN, która już istnieje w starszej polityce SSL VPN, Sophos Firewall usuwa to przypisanie z wcześniejszej polityki. Dlatego należy unikać nakładania się polityk i jasno definiować, która polityka obowiązuje dla każdej grupy użytkowników.

4. Decyzja o Split Tunnel lub Full Tunnel

Split Tunnel

Przy Split Tunnel tylko ruch do dozwolonych wewnętrznych zasobów przechodzi przez tunel VPN. Ruch internetowy użytkownika nadal przechodzi bezpośrednio przez lokalną sieć użytkownika.

Split Tunnel często pasuje do:

• Dostępu do kilku wewnętrznych aplikacji,
• Mniejszego obciążenia zapory,
• Lepszej wydajności użytkownika,
• Małych lokalizacji zewnętrznych i mobilnych użytkowników.

Bezpieczeństwo zależy wtedy bardziej od końcówki, lokalnego środowiska sieciowego i udostępnionych wewnętrznych zasobów.

Full Tunnel

Przy Full Tunnel cały ruch zdalnego użytkownika jest kierowany przez zaporę. Na Sophos Firewall odpowiada to opcji Use as default gateway.

Full Tunnel pasuje bardziej, gdy:

• Ruch internetowy ma być centralnie kontrolowany,
• Web Protection, DNS Protection lub logowanie dla użytkowników VPN ma działać,
• Użytkownicy pracują z niebezpiecznych sieci,
• Wymagana jest centralna analiza zgodności.

Przy Full Tunnel sama polityka SSL VPN nie wystarczy. Potrzebne są dodatkowe reguły zapory i NAT/SNAT dla ruchu internetowego z VPN-zone. Ponadto należy wcześniej przetestować wydajność, przepustowość, filtrowanie sieciowe i logowanie.

5. Tworzenie reguł zapory dla VPN-Zone

Nawiązanie tunelu nie oznacza jeszcze, że ruch jest dozwolony. Dla dostępu do wewnętrznych zasobów potrzebna jest odpowiednia reguła zapory:

Rules and policies > Firewall rules

Zalecana reguła dla Split Tunnel:

Dla Full Tunnel potrzebna jest dodatkowa reguła z VPN do WAN lub Any, w zależności od projektu. Sieci źródłowe powinny nadal być systemowymi hostami SSL VPN. Następnie należy sprawdzić, czy istnieje odpowiednia reguła SNAT.

Jeśli połączenie jest nawiązane, ale dostęp nie działa, należy najpierw sprawdzić Log Viewer. Dla metodologii odpowiedni jest Testowanie reguły zapory za pomocą Log Viewer, Policy Test i Packet Capture.

6. Zabezpieczenie VPN Portal i Device Access

Użytkownicy zazwyczaj pobierają Sophos Connect i plik .ovpn przez VPN Portal:

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

Przynajmniej sprawdź:

• Port i certyfikat VPN Portal.
• Metody uwierzytelniania VPN Portal.
• MFA dla VPN Portal i zdalnego dostępu.
• Device Access dla VPN Portal tylko w potrzebnych strefach.
• Device Access dla SSL VPN na strefie WAN tylko, jeśli jest to konieczne zewnętrznie.
• Brak trwałego otwartego User Portal na WAN, jeśli nie jest potrzebny.

Dla wzmocnienia lokalnych usług zapory odpowiedni jest Device Access i Local Service ACL na Sophos Firewall. Dla podstaw MFA odpowiedni jest Aktywacja MFA dla Sophos Firewall WebAdmin, VPN Portal i zdalnego dostępu.

VPN Portal jest sensowny dla użytkowników tylko wtedy, gdy oni lub ich grupy są zawarte w odpowiedniej polityce zdalnego dostępu. Jeśli brakuje przypisania polityki, użytkownik nie widzi potrzebnych pobrań konfiguracji.

Jeśli VPN Portal lub SSL VPN muszą być dozwolone na strefie WAN, powinno to być świadomie udokumentowane. W wielu środowiskach nie wystarczy otworzyć usługę na całym świecie i polegać na MFA. Tam, gdzie to możliwe, należy sprawdzić stałe sieci źródłowe, ograniczenia krajowe, Threat Feeds, sprawdzanie logów lub projekt zdalnego dostępu.

7. Dystrybucja profilu klienta

Po konfiguracji polityki i portalu plik .ovpn jest dystrybuowany. Może to odbywać się przez VPN Portal lub kontrolowane przez proces administracyjny.

Ważne:

• Po zmianach w bramie, porcie, certyfikacie, DNS, zakresie dzierżawy, polityce lub uwierzytelnianiu profil musi być ponownie załadowany.
• Aktualizacja Sophos Connect nie zastępuje starego profilu .ovpn.
• Nazwy profili powinny być jednoznaczne.
• Stare profile powinny być usuwane przy zmianie lokalizacji, bramy lub użytkownika.
• Windows, macOS, iOS, Android i Linux używają czasami różnych ścieżek klienta.

Dla aktualizacji klienta i zarządzania wersjami odpowiedni jest Sprawdzenie i bezpieczna aktualizacja wersji klienta Sophos Connect.

Testowanie po konfiguracji

Z użytkownikiem testowym należy sprawdzić nie tylko, czy Sophos Connect pokazuje Connected.

Lista testów:

• Użytkownik widzi w VPN Portal pobieranie Sophos Connect i konfigurację SSL VPN.
• Plik .ovpn można zaimportować.
• MFA jest wymagane zgodnie z oczekiwaniami.
• Klient otrzymuje adres z zakresu dzierżawy SSL VPN.
• Trasa do dozwolonych wewnętrznych sieci pojawia się na końcówce.
• Wewnętrzne nazwy DNS są rozwiązywane.
• Dostęp do dozwolonych serwerów działa.
• Niedozwolone sieci pozostają zablokowane.
• Log Viewer pokazuje właściwą regułę zapory.
• Packet Capture pokazuje ruch przez interfejs tun, jeśli to konieczne.
• Przy Full Tunnel działa również dostęp do internetu i SNAT.

Jeśli test jest przeprowadzany tylko z użytkownikiem administracyjnym, łatwo przeoczyć błędy grupowe i polityczne. Lepiej jest użyć normalnego użytkownika pilotażowego z docelowej grupy.

Test akceptacyjny według scenariusza

Przed szerokim wdrożeniem należy przynajmniej dokładnie udokumentować te przypadki testowe:

Dla środowisk produkcyjnych każdy test powinien zawierać godzinę, użytkownika, platformę klienta i konkretny cel. Stwierdzenia takie jak “VPN działa” lub “VPN nie działa” są zbyt nieprecyzyjne dla późniejszych przypadków wsparcia.

Zbieranie logów i dowodów

Przy problemach z SSL VPN należy najpierw ustalić, czy błąd leży przy logowaniu, nawiązywaniu tunelu czy dostępie do wewnętrznych celów. To rozdzielenie oszczędza czas, ponieważ w przeciwnym razie uwierzytelnianie, profil klienta, routing i reguły zapory są sprawdzane w sposób chaotyczny.

Dla powtarzalnego przypadku testowego należy zanotować te informacje:

Następnie należy przeprowadzić kontrolę w tej kolejności:

1. Sprawdzenie uwierzytelniania: W Log Viewer i w razie potrzeby w logach uwierzytelniania sprawdź, czy użytkownik, MFA, grupa i serwer uwierzytelniania są skuteczne. Przy Microsoft Entra ID SSO dodatkowo istotny jest oauth_sso_vpn.log.
2. Sprawdzenie statusu tunelu: Sprawdź połączenie SSL VPN, adres dzierżawy i status OpenVPN. Po stronie zapory pomocne są sslvpn.log i openvpn-status*.log.
3. Sprawdzenie reguły zapory: W Log Viewer szukaj ruchu z VPN-zone i kontroluj, która reguła faktycznie pasuje. Reguła powinna mieć aktywne Log firewall traffic.
4. Sprawdzenie przepływu pakietów: Jeśli Log Viewer nie wystarcza, użyj Packet Capture do filtrowania źródła, celu i usługi. Ważne jest, czy pakiety są tylko Incoming czy również Forwarded.
5. Sprawdzenie strony docelowej: Jeśli ruch opuszcza zaporę, ale nie ma odpowiedzi, bardziej prawdopodobne są trasa zwrotna, zapora serwera, lokalna zapora hosta lub konflikt sieciowy niż polityka SSL VPN.

Dla przypisania najważniejszych plików logów odpowiedni jest Rozwiązywanie problemów z Sophos Firewall: Usługi i logi. Dla analizy reguł za pomocą Log Viewer, Policy Test i Packet Capture odpowiedni jest Testowanie reguły zapory za pomocą Log Viewer, Policy Test i Packet Capture.

Rozwiązywanie problemów

Użytkownik nie widzi konfiguracji SSL VPN w VPN Portal

Zazwyczaj brakuje przypisania polityki. Należy sprawdzić, czy użytkownik lub jego grupa są zawarte w polityce SSL VPN pod Policy members. Dodatkowo należy sprawdzić uwierzytelnianie, MFA i dostępność VPN Portal.

Jeśli logowanie i przypisanie polityki wydają się poprawne, ale pobieranie pliku .ovpn nadal brakuje lub nie powodzi się, należy również sprawdzić Limit użytkowników Sophos Firewall User-ID. Jest to szczególnie istotne, gdy wielu użytkowników korzysta z portalu, ale tylko niektóre pobrania nieoczekiwanie się nie udają.

Tunel łączy się, ale wewnętrzne systemy są nieosiągalne

Najpierw sprawdź, czy na końcówce istnieje trasa do wewnętrznej sieci docelowej. Następnie w Log Viewer szukaj ruchu z VPN-zone. Jeśli ruch nie jest widoczny, klient nie osiąga zapory zgodnie z oczekiwaniami lub profil jest przestarzały.

Jeśli ruch jest widoczny, ale pasuje niewłaściwa reguła, należy skorygować kolejność reguł lub definicję usługi/celu. Jeśli nie ma żadnej odpowiedzi zwrotnej, bardziej prawdopodobne są routing, zapora docelowa, lokalna zapora serwera lub konflikt sieciowy.

DNS nie działa

Sprawdź, czy dostęp po adresie IP działa. Jeśli tak, błąd prawdopodobnie leży w DNS. Następnie sprawdź serwery DNS w globalnych ustawieniach SSL VPN, nazwę domeny, Device Access dla DNS z VPN-zone i zachowanie DNS na końcówce.

Dostęp działa tylko dla niektórych użytkowników

Wtedy bardziej prawdopodobne są członkostwo w grupie, przypisanie polityki, statyczne adresy IP SSL VPN, status MFA lub przestarzałe profile niż globalny błąd zapory. Należy również sprawdzić podwójne przypisania polityki.

Użytkownik musi się ponownie połączyć po kilku godzinach

Jeśli SSL VPN początkowo działa, ale po kilku godzinach wymagana jest ponowna rejestracja lub ręczne ponowne połączenie, należy najpierw sprawdzić wzorce czasowe, uwierzytelnianie i model dzierżawy. Jest to szczególnie istotne przy lokalnym uwierzytelnianiu ze statycznie przypisanym adresem IP SSL VPN.

Praktyczna procedura:

1. Zanotuj godzinę nawiązania połączenia i przerwania.
2. Porównaj czas z skonfigurowanym Key Lifetime.
3. Sprawdź, czy użytkownik ma statyczny adres IP SSL VPN.
4. Testowo sprawdź dynamiczne przypisanie IP dla użytkownika pilotażowego, jeśli to możliwe operacyjnie.
5. W sslvpn.log, openvpn-status*.log i Log Viewer szukaj uwierzytelniania, adresu dzierżawy i ponownej rejestracji.
6. Jeśli wybierana jest dłuższa Key Lifetime, dokumentuj zmianę i nie traktuj jej jako zamiennika dla MFA lub czystej kontroli sesji.

Jeśli statyczne IP są używane tylko po to, aby reguły zapory wyglądały prościej, należy przeprojektować projekt. Zazwyczaj grupy, jasno nazwane obiekty docelowe, wąskie usługi i logowanie są lepszą podstawą niż pojedyncze adresy IP użytkowników.

Full Tunnel nie ma dostępu do internetu

Przy Use as default gateway potrzebna jest reguła zapory dla ruchu z VPN-zone w kierunku internetu i odpowiednia reguła SNAT. Ponadto polityki Web, DNS i bezpieczeństwa muszą być tak zaplanowane, aby nie blokowały nieoczekiwanie użytkowników VPN.

Połączenie jest nawiązane, ale duże transfery się zawieszają

Jeśli logowanie, DNS i małe dostępy działają, ale RDP, transfery plików, aplikacje webowe lub duże pobrania się zawieszają, należy sprawdzić MTU i MSS. Obraz błędu często pasuje do fragmentacji, PPPoE, połączeń tunelowanych lub asymetrycznej ścieżki, nie tylko do samego SSL VPN.

Dla systematycznej analizy odpowiedni jest Sprawdzenie MTU i MSS na Sophos Firewall przy problemach z VPN.

WAF lub Portal koliduje z SSL VPN

Jeśli WAF, VPN Portal, User Portal i SSL VPN działają na tej samej WAN-IP, port i protokół muszą być czysto rozdzielone. Szczególnie krytyczne są wspólnie używane kombinacje WAN-IP, portu i TCP. Przy niejasnych dropach sprawdź Log Viewer i Packet Capture.

Profil jest przestarzały po zmianie

Po zmianach w polityce SSL VPN, bramie, DNS, certyfikacie, porcie lub uwierzytelnianiu plik .ovpn powinien być ponownie pobrany i zaimportowany. Wiele pozornych problemów z klientem to przestarzałe profile.

Lista kontrolna operacji

Przed wdrożeniem produkcyjnym

• Sprawdzone FQDN i certyfikat dla VPN Portal i SSL VPN.
• Zakres dzierżawy SSL VPN nie koliduje z wewnętrznymi lub typowymi sieciami domowymi.
• Polityka SSL VPN zawiera właściwych użytkowników lub grupy.
• Split Tunnel lub Full Tunnel jest świadomie wybrany.
• Dozwolone zasoby sieciowe są przy Split Tunnel wąsko zdefiniowane.
• Serwery DNS i nazwa domeny są poprawnie ustawione.
• Istnieje reguła zapory z VPN do wewnętrznych celów i loguje.
• Przy Full Tunnel istnieją reguła internetowa i SNAT.
• Device Access dla SSL VPN i VPN Portal jest świadomie ustawiony.
• MFA jest przetestowane dla zdalnego dostępu.
• Użytkownik testowy może pobrać, zaimportować profil i osiągnąć wewnętrzne cele.

Dla bieżącej eksploatacji

• Wymuszaj MFA dla VPN Portal i zdalnego dostępu.
• Regularnie sprawdzaj grupy VPN.
• Trzymaj reguły zapory dla VPN wąskie i loguj.
• Kontroluj zakres dzierżawy przed zmianami sieci.
• Używaj statycznych adresów IP SSL VPN tylko celowo i regularnie sprawdzaj.
• Dokumentuj DNS i domenę wyszukiwania.
• Odnawiaj certyfikaty Portal i SSL VPN przed wygaśnięciem.
• Śledź wersje Sophos Connect.
• Planuj ponowną dystrybucję profilu po zmianach.
• Długoterminowo analizuj logi przez Syslog lub Sophos Central, jeśli ważna jest możliwość śledzenia.

Dla plików logów i usług odpowiedni jest Rozwiązywanie problemów z Sophos Firewall: Usługi i logi.

Regularnie sprawdzaj przypadki specjalne

• Statyczne adresy IP SSL VPN są uzasadnione i udokumentowane.
• Key Lifetime pasuje do modelu operacyjnego i został przetestowany z ponownym połączeniem.
• Stary profil .ovpn jest ponownie dystrybuowany po zmianach.
• VPN Portal, User Portal, WAF i SSL VPN nie kolidują na tej samej WAN-IP z portem i protokołem.
• Użytkownicy z uprawnieniami specjalnymi lub dostępem administracyjnym są oddzielnie sprawdzani.

FAQ