Sophos Firewall SSL VPN Skonfiguruj dostęp zdalny

SSL VPN pozostaje ważną ścieżką zdalnego dostępu do Sophos Firewall, szczególnie gdy użytkownicy pracują w hotelach, gościnnych sieciach WLAN, sieciach komórkowych lub restrykcyjnych sieciach innych firm. Ale nie tylko to, czy tunel zostanie zbudowany, jest ważne. Kluczowe jest to, czy firewall prawidłowo ogranicza dostęp, czy działa DNS, czy działa MFA i czy reguły firewalla dopuszczają ruch ze strefy VPN w sposób kontrolowany.

Artykuł opisuje konfigurację dostępu zdalnego SSL VPN po stronie zapory ogniowej na platformie Sophos Firewall. W przypadku instalacji klienta, Skonfiguruj Sophos SSL VPN z Sophos Connect na Windows, Skonfiguruj Sophos SSL VPN z Sophos Connect na macOS, Skonfiguruj Sophos SSL VPN na iPhonie i iPadzie i Sophos SSL VPN na Androidzie są odpowiednie dla zestawu instalacyjnego klienta w górę.

W przypadku podstawowej decyzji pomiędzy IPsec, SSL VPN, klientami mobilnymi i ZTNA, Sophos Connect lub SSL VPN: Które rozwiązanie zdalnego dostępu jest odpowiednie? pasuje jako pierwsze.

Który artykuł SSL VPN pasuje?

SSL VPN obejmuje konfigurację zapory ogniowej, portal, klienta, uwierzytelnianie i późniejszą analizę błędów. W zależności od zadania odpowiednie jest inne podejście:

• Konfigurowanie SSL VPN na zaporze ogniowej: Ten artykuł.
• Sophos Connect lub SSL VPN w zasadzie porównaj: Sophos Connect lub SSL VPN: Które rozwiązanie zdalnego dostępu jest odpowiednie?.
• Sophos Connect Utrzymuj wersje i profile klientów: Sophos Connect Sprawdź wersję klienta i bezpiecznie aktualizuj.
• Skonfiguruj klienta SSL VPN w systemie Windows: Skonfiguruj Sophos SSL VPN z Sophos Connect w systemie Windows.
• Skonfiguruj SSL VPN na macOS, iOS lub Android: macOS, iPhone/iPad lub Android.
• Microsoft Entra ID Użyj SSO lub Entra-MFA: Microsoft Entra ID Skonfiguruj SSO dla Sophos Connect i VPN Portal.
• VPN jest podłączony, ale ruch nie działa: Przetestuj regułę zapory sieciowej za pomocą Log Viewer, Test zasad i Packet Capture.
• Duże transfery zawieszają się lub poszczególne aplikacje nie ładują się: Sophos Firewall Sprawdź MTU i MSS pod kątem problemów z VPN.

To rozdzielenie jest ważne: problem użytkownika w VPN Portal, nieaktualny profil .ovpn, brakująca reguła zapory sieciowej i problem DNS często wyglądają dla użytkownika tak samo. Do analizy poziomy te muszą zostać oddzielone.

Obraz docelowy

Czysta struktura SSL VPN składa się z kilku elementów:

1. Użytkownicy lub grupy są autoryzowane w ramach prawidłowej polityki 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 tak szerokim zakresie, jak to konieczne i chroniony za pomocą MFA.
4. Reguły zapory sieciowej zezwalają na ruch ze strefy VPN tylko do wymaganych miejsc docelowych.
5. Tunel podzielony lub pełny tunel to świadoma decyzja.
6. Klienci importują bieżący profil .ovpn.
7. W przypadku błędu można ocenić logi, Packet Capture i dane pomocnicze.

Wiele problemów z SSL VPN pojawia się, ponieważ dokumentowane jest tylko pobieranie klienta. W praktyce jednak trzeba brać pod uwagę portal, uwierzytelnianie, politykę SSL VPN, regułę zapory sieciowej, DNS i NAT łącznie.

⚠️ SSL VPN to publicznie dostępny punkt wejścia. MFA i silne hasła są ważne, ale nie zastępują ograniczeń dostępu do urządzenia, wąskich grup użytkowników, aktualnych profili, logowania i regularnych przeglądów.

⚠️ Zmiany w bramie, porcie, certyfikacie, DNS, zakresie dzierżawy lub zasadach nie trafiają automatycznie do już zaimportowanych profili klientów. Po odpowiednich zmianach plik .ovpn należy ponownie pobrać, rozpowszechnić i zastąpić na klientach.

Wymagania wstępne

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

• Sophos Firewall z aktualną wersją SFOS.
• Publiczna dostępność zapory lub przekierowanie portów nadrzędnych.
• FQDN lub publiczny adres IP dla dostępu VPN.
• Certyfikat dla VPN Portal i SSL VPN, idealnie pasujący do FQDN.
• Użytkownicy lub grupy umożliwiające zdalny dostęp.
• Serwer uwierzytelniający dla VPN Portal i SSL VPN: lokalny, Active Directory, RADIUS lub Microsoft Entra ID.
• Koncepcja MFA/OTP dla VPN Portal i dostępu zdalnego.
• Wewnętrzne sieci docelowe, serwery DNS i domena wyszukiwania.
• Decyzja o tunelu podzielonym lub pełnym.
• Reguły zapory sieciowej dla ruchu ze strefy VPN.
• Proces aktualizacji klienta i redystrybucji pliku .ovpn.

Jeśli ma zostać użyte Microsoft Entra ID SSO, przed pobraniem konfiguracji VPN należy poprawnie przygotować uwierzytelnianie. Proces odbywa się w Microsoft Entra ID Skonfiguruj logowanie jednokrotne dla Sophos Connect i VPN Portal.

1. Przygotuj obiekty lokalne

Po pierwsze, sieci docelowe powinny istnieć jako hosty lub obiekty sieciowe:

Hosts and services > IP host

Typowe obiekty:

• LAN_Server: 10.10.10.0/24 dla serwerów wewnętrznych.
• LAN_Client: 10.10.20.0/24 dla sieci klienckiej, jeśli jest to naprawdę potrzebne.
• 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 po prostu zwalniać całych obszarów sieci wewnętrznej, jeśli potrzebne są tylko pojedyncze serwery lub podsieci. Im ściślej zdefiniowane są obiekty, tym prostsza będzie później reguła zapory.

Jeśli w tunelu używane są serwery DNS, powinny one nie tylko znajdować się w globalnych ustawieniach SSL VPN, ale także istnieć jako cele. Szczególnie w przypadku pełnych tuneli lub ściśle ograniczonych zasobów tunel jest w inny sposób połączony, ale rozpoznawanie nazw pozostaje zepsute.

2. Sprawdź globalne ustawienia SSL VPN

Ustawienia globalne mają zastosowanie do wszystkich zasad SSL VPN dostępu zdalnego:

Remote access VPN > SSL VPN > SSL VPN global settings

Protokół i port

SSL VPN może używać protokołu TCP lub UDP w zależności od konfiguracji. UDP jest często bardziej wydajny, TCP może działać lepiej w sieciach restrykcyjnych. Decyzję należy przetestować na sieciach, z których faktycznie pracują użytkownicy.

Port musi unikać nakładania się:

• SSL VPN Domyślnym portem jest często 8443.
• VPN Portal wersja aktualna SFOS — wersja standardowa 443.
• Reguły WAF i SSL VPN nie mogą nakładać się na ten sam adres IP WAN z tym samym portem i protokołem.
• Jeśli SSL VPN i VPN Portal używają tego samego portu, funkcje Login Security mogą nie działać zgodnie z oczekiwaniami.

Jeśli WAF, VPN Portal, User Portal i SSL VPN działają na tym samym IP WAN, należy świadomie udokumentować port, protokół i certyfikat. Dla podstaw WAF pasuje artykuł konfiguracja Sophos Firewall WAF i unikanie typowych błędów.

Certyfikat i zastąpienie nazwy hosta

W obszarze Certyfikat serwera SSL należy użyć certyfikatu zgodnego z publicznym FQDN. Błąd certyfikatu w profilu VPN Portal lub w profilu SSL VPN doprowadzi później do niepotrzebnych zgłoszeń do pomocy technicznej.

W obszarze Override hostname określasz, jakiej nazwy hosta lub adresu IP używają klienci w profilu .ovpn. Jest to szczególnie ważne dla:

• multiple WAN IP addresses,
• router nadrzędny,
• NAT lub przekierowanie portów przed zaporą sieciową,
• dynamiczny WAN IP z DDNS,
• oddzielne nazwy FQDN dla WebAdmin, VPN Portal i SSL VPN.

Jeśli pole pozostanie puste, w profilu może pojawić się wiele adresów interfejsów. Może to zadziałać, ale w środowiskach produkcyjnych jest często mniej wyraźne niż czysty FQDN. Sophos Connect nie wypróbowuje po prostu bram z pliku .ovpn w widocznej kolejności; Dynamiczne bramki DNS i kolejność kilku wpisów mogą więc w praktyce działać inaczej niż oczekiwano. W przypadku konfiguracji produktywnych łatwiej jest testować i obsługiwać unikalną zastępującą nazwę hosta.

Po zmianie zastępującej nazwy hosta musisz pobrać nowy profil i sprawdzić, czy klient rzeczywiście ma nowy FQDN lub nowy publiczny adres IP. W przeciwnym razie możesz zakończyć testowanie starego połączenia, mimo że konfiguracja zapory jest już poprawna.

Powierzchnia najmu

Sophos Firewall przypisuje adresy klientom SSL VPN ze skonfigurowanego zakresu dzierżawy. Obszar ten nie może zakłócać sieci wewnętrznych, tras statycznych, sieci VPN typu site-to-site, innych pul dostępu zdalnego ani typowych obszarów sieci domowej.

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 Lease koliduje z siecią domową użytkownika, tunel czasem zestawia się poprawnie, ale cele wewnętrzne pozostają nieosiągalne. Wygląda to jak problem z regułami firewalla, ale w rzeczywistości jest problemem routingu na endpoincie.

W przypadku IPv4, Sophos Firewall akceptuje tylko podsieci do /24 w globalnych ustawieniach SSL VPN. Nie można tam wybrać mniejszych sieci, takich jak /25. Jeśli oczekuje się tylko kilku użytkowników, nadal warto zaplanować czystą, nie powodującą konfliktów sieć VPN i ograniczyć dostęp poprzez reguły firewalla, a nie sztucznie zawężony zakres dzierżawy.

W przypadku reguł zapory sieciowej należy używać hostów systemowych ##ALL_SSLVPN_RW i IPv6 ##ALL_SSLVPN_RW6, a nie ręcznie utworzonych hostów ze starymi obszarami dzierżawy.

Statyczne adresy IP SSL VPN i czas życia klucza

Statyczne adresy IP SSL VPN mogą być przydatne w indywidualnych przypadkach, na przykład w przypadku dostępu administratora, ściśle rejestrowanego dostępu specjalnego lub starszych aplikacji z zatwierdzeniem opartym na protokole IP. Nie są one jednak odpowiednie jako standard dla wszystkich użytkowników. Im więcej jest przypisań statycznych, tym trudniejsza jest obsługa, analiza błędów i późniejsze migracje.

Dodatkowo Sophos Firewall nie obsługuje jednoczesnego logowania się w trybie zdalnego dostępu dla użytkowników ze statycznie przypisanym adresem IP SSL VPN. Jest to ważne w przypadku kont współdzielonych, urządzeń równoległych lub przypadków testowych, w których użytkownik musi być podłączony jednocześnie do notebooka i drugiego urządzenia. Takie projekty nie powinny być rozwiązywane za pomocą statycznych adresów IP.

Na liście znanych problemów udokumentowano konkretny przypadek specjalny: W przypadku SSL VPN z uwierzytelnianiem lokalnym i statycznie przypisanym adresem IP SSL VPN ponowne uwierzytelnienie może zakończyć się niepowodzeniem po wygaśnięciu ważności klucza. Zapora może potraktować już przypisany adres dzierżawy jako konflikt. Użytkownicy muszą następnie ręcznie ponownie nawiązać połączenie, mimo że tunel wcześniej działał. Typowa wartość życia klucza to 18000 sekund.

Jeśli użytkownik musi logować się wielokrotnie po kilku godzinach, powinieneś nie tylko sprawdzić MFA, wersję klienta i regułę zapory. Dodatkowo do analizy zaliczają się następujące punkty:

• Czy dla SSL VPN używane jest uwierzytelnianie lokalne?
• Czy użytkownik ma statyczny adres IP SSL VPN?
• Czy problem występuje mniej więcej po upływie okresu ważności klucza?
• Czy ten sam użytkownik działa stabilniej przy dynamicznym przydzielaniu adresu IP?
• Czy statyczny adres IP jest naprawdę konieczny, czy też wystarczy reguła dotycząca grupy użytkowników, hosta systemu SSL VPN i rejestrowania?

Sophos wymienia dwa pragmatyczne środki zaradcze: zaplanuj czas życia klucza na normalny dzień pracy lub użyj dynamicznej alokacji adresów IP. W wielu środowiskach alokacja dynamiczna jest czystsza, ponieważ reguły zapory powinny być kontrolowane w strefie VPN, grupie użytkowników, obiektach docelowych i hostach systemu SSL VPN.

DNS i nazwa domeny

Do wewnętrznego rozpoznawania nazw serwery DNS i opcjonalnie nazwa domeny są ustawione w globalnych ustawieniach SSL VPN. W środowiskach Active Directory jest to zwykle wewnętrzny serwer DNS lub kontroler domeny.

Dodatkowo należy zezwolić na Administration > Device access DNS ze strefy VPN, jeśli sama zapora sieciowa jest używana jako moduł rozpoznawania nazw DNS w projekcie VPN.

Jeśli chcesz uzyskać bezpośredni dostęp do wewnętrznego serwera DNS, użytkownik VPN również potrzebuje dostępu do tego serwera DNS. Oznacza to: Serwer DNS należy do dozwolonych zasobów lub ma zezwolenie na dostęp do strefy VPN poprzez odpowiednią regułę zapory sieciowej. W przypadku Full Tunnel DNS nie należy traktować jako efektu ubocznego reguły Internetu, ale należy go świadomie testować.

Jeśli DNS nie działa w tunelu, powinieneś przetestować osobno:

• Czy cel jest osiągalny poprzez adres IP?
• Czy wewnętrzny serwer DNS jest dozwolony przez regułę zapory?
• Czy klient otrzymuje prawidłową domenę wyszukiwania?
• Czy klient naprawdę używa bieżącego profilu .ovpn?
• Czy lokalna konfiguracja DNS punktu końcowego lub konfiguracja DoH punktu końcowego interweniuje?

DNS należy zaplanować szczególnie ostrożnie w przypadku tuneli dzielonych. Jeśli tunelem przechodzą tylko wewnętrzne sieci docelowe, musi być jasne, czy nazwy wewnętrzne są rozpoznawane przez wewnętrzny serwer DNS i czy nazwy publiczne działają lokalnie, czy przez zaporę ogniową. W przeciwnym razie powstają błędy, w których działa dostęp IP, ale wewnętrzne nazwy hostów są rozpoznawane tylko na poszczególnych klientach.

3. Utwórz politykę SSL VPN

Polityka została utworzona w:

Remote access VPN > SSL VPN

Sophos oferuje w tym celu kreator SSL VPN lub ręczną konfigurację. Kreator może utworzyć politykę, VPN Portal, serwer uwierzytelniania, regułę zapory sieciowej i Device Access w jednym procesie. Jest to przydatne w przypadku nowych konfiguracji. W istniejących środowiskach Configure manually jest często lepszy, ponieważ można świadomie sprawdzić pozycję reguły, obiekty docelowe, logowanie i dostęp do portalu.

Ręczny przebieg konfiguracji:

1. Wybierz Add.
2. Użyj Configure manually.
3. Przypisz nazwę, na przykład SSLVPN-Remote-Users.
4. Wybierz autoryzowanych użytkowników lub grupy w Policy members.
5. Ustaw tunel podzielony lub pełny.
6. Wybierz Permitted network resources dla tunelu dzielonego; Przy pełnym tunelu przygotuj późniejsze obiekty docelowe przede wszystkim pod kątem reguł zapory sieciowej.
7. Opcjonalnie skonfiguruj Disconnect idle clients.
8. Zapisz, a następnie sprawdź u użytkownika testowego.

Permitted network resources w dzielonym tunelu ogranicza wewnętrzne miejsca docelowe, do których powinni dotrzeć zdalni użytkownicy. Ten punkt jest inny w przypadku Use as default gateway: Sophos Firewall nie wymusza wówczas dozwolonych zasobów jako limitu dostępu. Cały ruch przechodzi przez zaporę, a faktyczne ograniczenie musi nastąpić poprzez reguły zapory, strefy, cele, Services i rejestrowanie.

W przypadku pełnych tuneli należy nadal modelować wewnętrzne sieci docelowe w sposób przejrzysty jako obiekty, ale nie należy polegać wyłącznie na zasadach SSL VPN w celu ich ograniczenia. Interfejsy nie są dobrym zamiennikiem tego, ponieważ interfejs nie opisuje automatycznie, które podsieci za nim są technicznie dozwolone.

Jeśli obiekty FQDN są używane jako dozwolone zasoby w tunelach dzielonych, operację należy zaplanować świadomie. Dzienniki SSL VPN pokazują rozwiązane adresy IP, a dynamiczne zmiany FQDN nie trafiają automatycznie do istniejących wcześniej tuneli. Aby zmiany adresów docelowych zaczęły obowiązywać, użytkownicy, których to dotyczy, muszą rozłączyć się i ponownie połączyć.

Ważne: Podczas rejestrowania użytkowników lub grup w nowszej zasadzie SSL VPN, która jest już uwzględniona w starszej zasadzie SSL VPN, Sophos Firewall usuwa to powiązanie z wcześniejszej polityki. Dlatego należy unikać nakładania się zasad i jasno określić, która polityka ma zastosowanie do każdej grupy użytkowników.

Po zmianie polityki zwykły użytkownik z grupy docelowej powinien zostać zarejestrowany w VPN Portal. Powinna być widoczna dokładnie oczekiwana konfiguracja SSL VPN, a nie kilka starych profili lub brak jakiejkolwiek konfiguracji. Ten test portalu wykrywa błędy grupowe szybciej niż zwykły test administratora ze specjalnymi uprawnieniami.

4. Zdecyduj o tunelu podzielonym lub pełnym

Podzielone tunele

W przypadku tuneli dzielonych przez tunel VPN przechodzi wyłącznie ruch do dozwolonych zasobów wewnętrznych. Ruch internetowy użytkownika jest kontynuowany bezpośrednio w sieci lokalnej użytkownika.

Tunel dzielony często pasuje do:

• Dostęp do kilku aplikacji wewnętrznych,
• mniejsze obciążenie zapory ogniowej,
• lepsza wydajność użytkownika,
• mniejsze odległe lokalizacje i użytkownicy mobilni.

Bezpieczeństwo zależy zatem bardziej od punktu końcowego, środowiska sieci lokalnej i współdzielonych zasobów wewnętrznych.

Pełny tunel

W trybie pełnego tunelu cały ruch użytkowników zdalnych jest kierowany przez zaporę. W Sophos Firewall odpowiada to opcji Use as default gateway.

Pełny tunel jest bardziej odpowiedni, jeśli:

• Ruch internetowy powinien być kontrolowany centralnie,
• Ochrona sieci, DNS Protection lub rejestrowanie powinny obowiązywać dla użytkowników VPN,
• Użytkownicy z niezabezpieczonych sieci pracują,
• Wymagana centralna ocena zgodności.

W przypadku Full Tunnel sama polityka SSL VPN nie wystarczy. Potrzebujesz także reguł zapory sieciowej i NAT/SNAT dla ruchu internetowego ze strefy VPN. Powinieneś także wcześniej przetestować wydajność, przepustowość, filtrowanie sieci i rejestrowanie.

Nie należy włączać pełnego tunelu tylko dlatego, że utrzymanie poszczególnych celów podzielonego tunelu jest trudne. Kiedy cały ruch internetowy przechodzi przez zaporę ogniową, częścią projektu staje się pojemność, filtrowanie sieci, DNS, rejestrowanie, ochrona danych i koszty obsługi.

Nawet przy pełnym tunelu wewnętrzne sieci docelowe i serwery DNS powinny być wyraźnie modelowane jako cele zapory ogniowej. W przeciwnym razie działa domyślna ścieżka bramy, ale aplikacje wewnętrzne lub rozpoznawanie nazw zależą od reguły internetowej, która jest zbyt szeroka.

5. Utwórz reguły zapory sieciowej dla strefy VPN

Utworzenie tunelu nie oznacza, że ruch jest dozwolony. Aby uzyskać dostęp do zasobów wewnętrznych, potrzebujesz odpowiedniej reguły zapory sieciowej:

Rules and policies > Firewall rules

Zalecana zasada dla dzielonego tunelu:

• Rule name: VPN_SSLVPN_to_Internal_Servers
• Source zone: VPN
• Sieci i urządzenia źródłowe: ##ALL_SSLVPN_RW
• Strefy docelowe: wewnętrzne strefy docelowe, na przykład LAN lub DMZ
• Sieci docelowe: dozwolone są tylko serwery lub podsieci
• Services: tylko wymagane usługi
• Włącz Log firewall traffic:

W przypadku pełnego tunelu wymagana jest dodatkowa reguła od VPN do WAN lub Any, w zależności od projektu. Sieci źródłowe powinny nadal być hostami systemu SSL VPN. Następnie należy sprawdzić, czy istnieje odpowiednia reguła SNAT.

Jeśli istnieje połączenie, ale nie działa dostęp, powinieneś najpierw sprawdzić Log Viewer. Przetestuj regułę zapory sieciowej za pomocą Log Viewer, test zasad i Packet Capture jest odpowiednie dla tej metodologii.

Reguły dla SSL VPN powinny znajdować się w jasno nazwanej grupie, na przykład VPN Remote Access. Ogólna zasada, taka jak VPN_to_LAN_Any, jest wygodna, ale utrudnia późniejszą analizę błędów i często pozwala na większy dostęp, niż jest to technicznie konieczne. Lepsze są oddzielne reguły dla obszaru docelowego lub klasy usługi z aktywnym rejestrowaniem.

6. Zabezpiecz VPN Portal i Device Access

Użytkownicy zazwyczaj ładują Sophos Connect i plik .ovpn poprzez VPN Portal:

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

Sprawdź co najmniej:

• VPN Portal Port i certyfikat.
• VPN Portal Authentication Metody.
• SSL VPN Authentication Methods.
• MFA dla VPN Portal i dostępu zdalnego.
• Device Access dla VPN Portal tylko w wymaganych strefach.
• Device Access dla SSL VPN w strefie WAN tylko wtedy, gdy jest to wymagane zewnętrznie.
• Brak stałego otwarcia User Portal na WAN, gdy nie jest potrzebne.

Aby wzmocnić lokalne usługi zapory ogniowej, Device Access i Local Service ACL odpowiadają Sophos Firewall. W przypadku podstaw MFA, MFA pasuje do Sophos Firewall WebAdmin, VPN Portal i umożliwia dostęp zdalny.

VPN Portal wydaje się przydatne użytkownikom tylko wtedy, gdy oni sami lub ich grupy są objęci odpowiednią polityką zdalnego dostępu. Jeśli brakuje przypisania polityki, użytkownik nie zobaczy wymaganych plików konfiguracyjnych do pobrania.

Pod Authentication > Services, VPN Portal i SSL VPN należy zaznaczyć osobno. VPN Portal kontroluje rejestrację pobierania i dostępu do profilu, SSL VPN authentication methods kontroluje faktyczną rejestrację tunelu. Obydwa obszary mogą korzystać z tego samego serwera, ale nie muszą być automatycznie zgodne. Dla RADIUS jest to również ważne: MFA oparte na wyzwaniach dla VPN Portal nie jest obsługiwane; takie projekty należy przetestować z prawdziwym użytkownikiem testowym przed wdrożeniem.

Jeśli VPN Portal lub SSL VPN musi mieć zezwolenie na dostęp do strefy WAN, należy to celowo udokumentować. W wielu środowiskach nie wystarczy otworzyć usługę na całym świecie i polegać na MFA. Tam, gdzie to możliwe, należy sprawdzić sieci stacjonarne, ograniczenia krajowe, źródła zagrożeń, sprawdzenie logów lub projekt zdalnego dostępu wyższego szczebla.

Ważne jest oddzielenie WebAdmin i VPN Portal. WebAdmin to interfejs administracyjny zapory ogniowej. VPN Portal to dostęp użytkownika do plików do pobrania i profili VPN. Obie usługi nie powinny być grupowane razem, ponieważ wiążą się z różnymi zagrożeniami, portami, uprawnieniami i odbiorcami.

7. Rozpowszechnij profil klienta

Po skonfigurowaniu polityki i portalu rozpowszechniany jest plik .ovpn. Może się to zdarzyć poprzez VPN Portal lub kontrolowane przez proces administracyjny.

Ważne:

• Po zmianach bramy, portu, certyfikatu, DNS, zakresu dzierżawy, zasad lub uwierzytelniania, profil musi zostać ponownie załadowany.
• Aktualizacja Sophos Connect nie zastępuje starego profilu .ovpn.
• Nazwy profili powinny być unikalne.
• W przypadku zmiany lokalizacji, bramy lub użytkownika należy usunąć stare profile.
• Windows, macOS, iOS, Android i Linux czasami używają różnych ścieżek klienta.
• Pliki udostępniania Sophos Connect (.pro) mogą automatycznie importować konfiguracje IPsec i SSL VPN, ale stanowią model operacyjny Sophos Connect i nie zastępują czystej polityki SSL VPN.

W przypadku Sophos Connect powinieneś aktywnie sprawdzić ograniczenia platformy: obecni klienci obsługują Windows 10 i 11, macOS 13 lub nowszy oraz Windows ARM od Sophos Connect 2.5. Microsoft Entra ID SSO w kliencie Sophos Connect to scenariusz Windows z Sophos Connect 2.4 lub nowszym. Platformy mobilne, takie jak iOS i Android, nie używają Sophos Connect dla SSL VPN, ale raczej aplikacje kompatybilne z OpenVPN lub inne ścieżki klienta.

Typowe zmiany profilu podczas pracy:

• Nowy FQDN lub nowy publiczny adres IP: pobierz ponownie .ovpn i zastąp stary profil.
• Zmieniono port lub protokół: Zaimportuj ponownie profil i usuń stary wpis połączenia.
• Certyfikat odnowiony lub zmieniony: Redystrybuuj profil i aktywnie sprawdzaj ostrzeżenia dotyczące certyfikatu.
• DNS nazwa serwera lub domeny została zmieniona: Zaimportuj nowy profil i przetestuj rozpoznawanie nazw.
• Zmieniono obszar najmu: Zaimportuj ponownie profil i sprawdź trasę lub adres klienta.
• Zmieniono grupę użytkowników lub politykę: Przetestuj pobieranie portalu przy użyciu zwykłego użytkownika docelowego.

Do aktualizacji klienta i konserwacji wersji odpowiednie jest Sophos Connect Sprawdź wersję klienta i bezpiecznie zaktualizuj.

W Sophos Connect plik informacyjny ładuje konfigurację .ovpn tylko dla użytkowników powiązanych z polityką SSL VPN. Jeśli użytkownik otrzyma tylko IPsec lub nie otrzyma żadnego połączenia SSL VPN za pośrednictwem pliku .pro, plik udostępniania nie zostanie automatycznie uszkodzony. Najpierw sprawdź Policy members, dostępność portalu VPN, metody uwierzytelniania i grupę użytkowników.

Test po konfiguracji

Korzystając z użytkownika testowego, powinieneś nie tylko sprawdzić, czy Sophos Connect pokazuje Connected.

Lista testów:

• Użytkownik widzi pobranie Sophos Connect i konfigurację SSL VPN w VPN Portal.
• Można zaimportować plik .ovpn.
• MFA jest odpytywane zgodnie z oczekiwaniami.
• Klient otrzymuje adres z zakresu dzierżawy SSL VPN.
• W punkcie końcowym pojawia się trasa do dozwolonych sieci wewnętrznych.
• W przypadku Full Tunnel jasne jest, że dostęp wewnętrzny jest ograniczony przez reguły zapory sieciowej, a nie tylko przez dozwolone zasoby.
• Test ponownego połączenia po zmianie DNS działa w przypadku zasobów FQDN.
• Trwa rozpoznawanie wewnętrznych nazw DNS.
• Dostęp do dozwolonych serwerów działa.
• Nieautoryzowane sieci pozostają zablokowane.
• Log Viewer pokazuje poprawną regułę zapory.
• Celowo negatywny test został odrzucony i zarejestrowany.
• Packet Capture pokazuje, jeśli to konieczne, ruch przez interfejs tun.
• Dostęp do Internetu i SNAT działają również z Full Tunnel.

Jeśli test jest wykonywany tylko przez administratora, łatwo przeoczyć błędy dotyczące grup i zasad. Lepszy jest zwykły użytkownik pilotażowy z grupy docelowej.

Dobry test akceptacyjny zawsze obejmuje zablokowany dostęp. Tylko w ten sposób można sprawdzić, czy reguły zapory sieciowej rzeczywiście ograniczają lub czy reguła, która jest zbyt ogólna w dalszej części zestawu reguł, nadal umożliwia dostęp.

Test akceptacyjny według scenariusza

Przed szerokim wdrożeniem przynajmniej te przypadki testowe powinny zostać odpowiednio udokumentowane:

• Nowy użytkownik: Zaloguj się do VPN Portal i przetestuj import profilu. Użytkownik powinien zobaczyć jedynie odpowiednią konfigurację SSL VPN i móc zaimportować profil.
• MFA aktywny: Testuj logowanie z poprawnym i niepoprawnym hasłem jednorazowym. Właściwy czynnik umożliwia dostęp, zły czynnik jest odrzucany i rejestrowany.
• Podział tunelu: Sprawdź dostęp do dozwolonego i niedozwolonego wewnętrznego miejsca docelowego. Dozwolone cele działają, inne sieci pozostają zablokowane.
• Pełny tunel: Przetestuj dostęp do Internetu przez VPN. Reguła zapory sieciowej, SNAT, DNS i zasady sieciowe/bezpieczeństwa działają zgodnie z planem.
• DNS: Testuj dostęp według nazwy i adresu IP. Umożliwia to oddzielenie błędów DNS od problemów z routingiem lub sterowaniem.
• Zmiana profilu: Importuj nowy profil .ovpn. Zmieniony FQDN, port, DNS lub certyfikat powinien być widoczny w profilu klienta.
• Przypadek błędu: Sprawdź Log Viewer i Packet Capture. Reguła zapory sieciowej, która faktycznie pasuje, i przepływ pakietów powinny być identyfikowalne.

W środowiskach produkcyjnych każdy test powinien zawierać czas, użytkownika, platformę kliencką i konkretny cel. Stwierdzenia takie jak „VPN działa” lub „VPN nie działa” są zbyt nieprecyzyjne, aby można je było zastosować w późniejszych przypadkach pomocy technicznej.

Zbierz dzienniki i dowody

Jeśli masz problemy z SSL VPN, powinieneś najpierw wyjaśnić, czy błąd dotyczy logowania, konfiguracji tunelu, czy dostępu do wewnętrznych miejsc docelowych. To oddzielenie oszczędza czas, ponieważ w przeciwnym razie uwierzytelnianie, profil klienta, routing i reguły zapory są sprawdzane razem.

W przypadku powtarzalnego przypadku testowego należy zanotować tę informację:

• Nazwa użytkownika i grupa: pokazuje, która polityka SSL VPN i uwierzytelnianie powinny mieć zastosowanie.
• Platforma kliencka i wersja Sophos Connect: oddzielają błędy klienta od konfiguracji zapory ogniowej.
• Czas testu: umożliwia porównanie Log Viewer, sslvpn.log i dzienników uwierzytelniania.
• Sieć źródłowa użytkownika: pomaga w przypadku hotelowej sieci Wi-Fi, sieci komórkowej, CGNAT, restrykcyjnych zapór sieciowych lub problemów z portami.
• System docelowy i usługa: zapobiega zbyt ogólnym stwierdzeniom, takim jak „VPN nie działa”.
• Wynik według adresu IP i nazwy DNS: oddziela problemy z routingiem i DNS.

Następnie należy przeprowadzić test w następującej kolejności:

1. Sprawdź uwierzytelnienie: Sprawdź Log Viewer i, jeśli to konieczne, w dziennikach uwierzytelniania, czy użytkownik, MFA, grupa i serwer uwierzytelniania powiodły się. W przypadku Microsoft Entra ID SSO istotne jest również oauth_sso_vpn.log.
2. Sprawdź status tunelu: Sprawdź połączenie SSL VPN, adres dzierżawy i status OpenVPN. sslvpn.log i openvpn-status*.log pomagają po stronie zapory ogniowej.
3. Sprawdź regułę zapory sieciowej: Wyszukaj ruch ze strefy VPN w Log Viewer i sprawdź, która reguła rzeczywiście pasuje. Reguła powinna mieć aktywną opcję Log firewall traffic.
4. Sprawdź przepływ pakietów: Jeśli Log Viewer nie wystarczy, przefiltruj źródło, miejsce docelowe i usługę za pomocą Packet Capture. Ważne jest, czy pakiety są tylko Incoming, czy też stają się Forwarded.
5. Sprawdź stronę docelową: Jeśli ruch opuszcza zaporę, ale nie wraca żadna odpowiedź, bardziej prawdopodobna jest trasa powrotna, zapora serwera, zapora hosta lokalnego lub konflikt sieciowy niż zasady SSL VPN.

Do przypisania najważniejszych plików dziennika odpowiednie jest Sophos Firewall Rozwiązywanie problemów: Services i logi. Do analizy reguł za pomocą Log Viewer, Test zasad i Packet Capture odpowiednia jest opcja Przetestuj regułę zapory sieciowej za pomocą Log Viewer, Test zasad i Packet Capture.

Rozwiązywanie problemów

Użytkownik nie widzi konfiguracji SSL VPN w VPN Portal

Zwykle brakuje przypisania zasad. Sprawdź, czy użytkownik lub jego grupa jest objęta polityką SSL VPN pod adresem Policy members. Dodatkowo należy sprawdzić uwierzytelnienie, MFA i dostępność portalu VPN.

Jeśli logowanie i mapowanie zasad działają poprawnie, ale pobieranie pliku .ovpn nadal nie jest pobierane lub kończy się niepowodzeniem, należy również sprawdzić Sophos Firewall limit identyfikatora użytkownika. Jest to szczególnie istotne, jeśli z portalu korzysta kilku użytkowników, ale tylko pojedyncze pobrania niespodziewanie kończą się niepowodzeniem.

Tunel łączy się, ale nie można uzyskać dostępu do systemów wewnętrznych

Najpierw sprawdź, czy w punkcie końcowym istnieje trasa do wewnętrznej sieci docelowej. Następnie wyszukaj Log Viewer ruch ze strefy VPN. Jeśli nie widać żadnego ruchu, klient nie łączy się z zaporą zgodnie z oczekiwaniami lub profil jest nieaktualny.

Jeśli ruch jest widoczny, ale zastosowano niewłaściwą regułę, należy poprawić kolejność reguł lub definicję usługi/miejsca docelowego. Jeśli w ogóle nie ma odpowiedzi, prawdopodobny jest routing, zapora docelowa, zapora serwera lokalnego lub konflikt sieciowy.

Po zmianie działają tylko niektórzy klienci

Jeśli nowi użytkownicy działają, a starzy klienci nie, problemem jest zazwyczaj dystrybucja profili. Sprawdzasz, czy klienci, których to dotyczy, rzeczywiście zaimportowali bieżący profil .ovpn i czy stare wpisy połączeń zostały usunięte.

Zwłaszcza po zmianach w FQDN, porcie, certyfikacie, DNS, obszarze dzierżawy, zasadach lub uwierzytelnianiu, powinieneś nie tylko zapisać zaporę, ale także aktywnie przetestować pobieranie profilu ze zwykłym użytkownikiem. Następnie możesz sprawdzić w punkcie końcowym, czy bramka, DNS i trasy odpowiadają aktualnemu projektowi.

DNS nie działa

Sprawdź, czy działa dostęp poprzez adres IP. Jeśli tak, błąd prawdopodobnie leży w DNS. Następnie sprawdź serwer DNS w globalnych ustawieniach SSL VPN, nazwę domeny, Device Access dla DNS ze strefy VPN i zachowanie punktu końcowego DNS.

Jeśli wewnętrzny serwer DNS nie jest ujęty jako dozwolony zasób albo nie jest osiągalny przez odpowiednią regułę firewall ze strefy VPN, nie pomoże nawet poprawny profil .ovpn. Dlatego DNS należy zawsze testować z konkretnym serwerem DNS, konkretną nazwą wewnętrzną i filtrem Log Viewer dla usługi DNS.

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

Wtedy członkostwo w grupach, mapowanie zasad, statyczne adresy IP SSL VPN, status MFA lub nieaktualne profile są bardziej prawdopodobne niż globalny błąd zapory. Należy również sprawdzić, czy nie ma zduplikowanych przypisań zasad.

Jeśli użytkownik korzysta z wielu urządzeń równolegle lub z konta współdzielonego, szczególnie krytycznie sprawdź statyczne adresy IP SSL VPN. Sophos nie obsługuje jednoczesnego logowania zdalnego dostępu dla tego samego użytkownika, gdy adres IP SSL VPN jest przypisany statycznie.

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

Jeśli SSL VPN początkowo działa, ale po kilku godzinach konieczne jest nowe logowanie lub ręczna przebudowa, powinieneś najpierw sprawdzić wzorzec czasowy, model uwierzytelniania i dzierżawy. Jest to szczególnie istotne w przypadku uwierzytelniania lokalnego ze statycznie przypisanym adresem IP SSL VPN.

Proces praktyczny:

1. Zanotuj godzinę nawiązania i przerwania połączenia.
2. Porównaj czas ze skonfigurowanym czasem życia klucza.
3. Sprawdź, czy użytkownik ma statyczny adres IP SSL VPN.
4. Przetestuj dynamiczne przypisanie adresu IP dla użytkownika pilotażowego, jeśli jest to operacyjnie możliwe.
5. Sprawdź sslvpn.log, openvpn-status*.log i Log Viewer pod kątem uwierzytelnienia, adresu dzierżawy i ponownego logowania.
6. Jeśli wybrano dłuższy Key Lifetime, udokumentować zmianę i nie traktować jej jako zamiennika MFA ani czystej kontroli sesji.

Jeśli statyczne adresy IP są używane tylko w celu uproszczenia reguł zapory sieciowej, należy przerobić projekt. W większości przypadków grupy, jasno określone cele, wąskie usługi i rejestrowanie stanowią lepszą podstawę niż indywidualne adresy IP użytkowników.

Pełny tunel nie ma dostępu do Internetu

W przypadku Use as default gateway wymagana jest reguła zapory sieciowej dla ruchu ze strefy VPN w kierunku Internetu oraz odpowiednia reguła SNAT. Ponadto należy zaplanować zasady sieciowe, DNS i bezpieczeństwa, aby nie blokowały nieoczekiwanie użytkowników VPN.

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

Jeśli logowanie, DNS i małe dostępy działają, ale protokół RDP, przesyłanie plików, aplikacje internetowe lub pobieranie dużych plików zawiesza się, powinieneś sprawdzić MTU i MSS. Wzorzec błędu często pasuje do fragmentacji, PPPoE, połączeń tunelowych lub ścieżki asymetrycznej, a nie tylko do samego SSL VPN.

Do systematycznej analizy pasuje Sophos Firewall Sprawdź MTU i MSS pod kątem problemów z VPN.

WAF lub portal koliduje z SSL VPN

Jeśli WAF, VPN Portal, User Portal i SSL VPN działają na tym samym adresie IP WAN, port i protokół muszą być wyraźnie oddzielone. Szczególnie krytyczne są wspólne kombinacje WAN-IP, portu i protokołu TCP. Jeśli krople są niejasne, sprawdź Log Viewer i Packet Capture.

Profil jest nieaktualny po zmianie

Po zmianach w polityce SSL VPN, bramie, DNS, certyfikacie, porcie lub uwierzytelnieniu, należy ponownie pobrać i zaimportować plik .ovpn. Wiele widocznych problemów klientów to przestarzałe profile.

Jeśli Sophos Connect jest obsługiwany z plikiem informacyjnym .pro, sprawdź także, czy klient rzeczywiście zaktualizował profil i czy nadal używany jest stary wpis połączenia. W przypadku współdzielonych urządzeń Windows z Entra-ID SSO, po zmianie użytkownika należy wymusić nowe logowanie SSO, aby poprzedni kontekst użytkownika nie był nadal stosowany.

Operacyjna lista kontrolna

Przed wdrożeniem produktywnym

• FQDN i certyfikat dla VPN Portal i SSL VPN zostały sprawdzone.
• Zakres dzierżawy SSL VPN nie koliduje z wewnętrznymi lub typowymi sieciami domowymi.
• Obszar najmu IPv4 planowany jest jako /24 lub większa sieć do wyboru, a nie mniejszy projekt /25.
• Zasada SSL VPN zawiera poprawnych użytkowników lub grupy.
• Tunel podzielony lub pełny tunel to świadoma decyzja.
• W przypadku tuneli dzielonych Permitted network resources są wąsko zdefiniowane.
• W trybie Full Tunnel reguły zapory ograniczają cele wewnętrzne i Services.
• Serwer DNS i nazwa domeny są ustawione poprawnie.
• Wewnętrzne serwery DNS są dostępne jako dozwolony zasób lub poprzez odpowiednią regułę.
• Reguła zapory sieciowej od VPN do celów wewnętrznych istnieje i jest rejestrowana.
• Reguła internetowa i SNAT istnieją dla pełnego tunelu.
• Device Access dla SSL VPN i VPN Portal jest ustawione celowo.
• MFA jest testowany pod kątem dostępu zdalnego.
• Użytkownik testowy może pobrać, zaimportować profil i osiągnąć cele wewnętrzne.

Dla bieżących operacji

• MFA dla VPN Portal i wymuś zdalny dostęp.
• Regularnie sprawdzaj grupy VPN.
• Zachowaj ścisłe reguły zapory dla VPN i zarejestruj się.
• Sprawdź obszar dzierżawy przed zmianami sieci.
• Używaj wyłącznie statycznych adresów IP SSL VPN i regularnie je sprawdzaj.
• Dokument DNS i przeszukaj domenę.
• Odnów certyfikaty portalu i SSL VPN przed wygaśnięciem.
• Sophos Connect Śledź wersje.
• Zaplanuj redystrybucję profilu po zmianach.
• Oceniaj logi w dłuższej perspektywie poprzez Syslog lub Sophos Central, jeśli ważna jest identyfikowalność.

W przypadku plików dziennika i usług odpowiednie jest Sophos Firewall Rozwiązywanie problemów: Services i dzienniki.

Regularnie sprawdzaj przypadki specjalne

• Statyczne adresy IP SSL VPN są uzasadnione i udokumentowane.
• Statyczne adresy IP SSL VPN nie są wymagane dla użytkowników wymagających równoległego logowania się w trybie dostępu zdalnego.
• Czas życia klucza jest zgodny z modelem operacyjnym i został przetestowany z programem Reconnect.
• Stary profil .ovpn zostanie ponownie rozpowszechniony po zmianach.
• Trwa testowanie zasobów FQDN pod kątem ponownego łączenia.
• VPN Portal, User Portal, WAF i SSL VPN nie kolidują z portem i protokołem tego samego adresu IP WAN.
• Użytkownicy ze specjalnymi uprawnieniami lub dostępem administracyjnym są sprawdzani osobno.

Często zadawane pytania