Konfiguracja SSL VPN Site-to-Site na Sophos Firewall

SSL VPN Site-to-Site łączy wewnętrzne sieci dwóch Sophos Firewall przez szyfrowany tunel. W przeciwieństwie do IPsec obie strony mają stałe role: firewall kliencki zawsze nawiązuje połączenie, a firewall serwerowy je przyjmuje.

To rozwiązanie sprawdza się szczególnie wtedy, gdy oddział ma dynamiczny publiczny adres IP albo IPsec sprawia problemy w sieci nadrzędnej. Centrala ze statycznym adresem lub stabilną nazwą FQDN pełni rolę serwera, a oddział — klienta. W przypadku rosnących sieci, routingu dynamicznego, redundancji lub urządzenia innego producenta route-based IPsec jest zazwyczaj bardziej elastyczny; przy niewielkim połączeniu między dwiema Sophos Firewall SSL Site-to-Site może być prostsze.

W instrukcji użyto konkretnego przykładu:

Centrala, serwer: vpn.example.com, sieć lokalna 10.10.0.0/24
Oddział, klient: dynamiczny publiczny adres IP, sieć lokalna 10.20.0.0/24
Połączenie: HQ-to-Branch
Port SSL VPN: 8443

vpn.example.com, nazwy obiektów i obie sieci to symbole zastępcze, które należy zastąpić wartościami z własnego środowiska. 8443 jest portem domyślnym; pozostaje bez zmian tylko wtedy, gdy odpowiada to wykorzystaniu portów i projektowi bezpieczeństwa.

Skrócony przebieg: ustalić role i sieci, sprawdzić globalne wartości SSL VPN, zezwolić na SSL VPN w strefie WAN serwera, utworzyć połączenie serwerowe, wyeksportować plik .apc, zaimportować go na firewallu klienckim, a następnie sprawdzić trasy, reguły i rzeczywisty ruch użytkowy.

⚠️ Globalne ustawienia SSL VPN są także używane przez Remote Access SSL VPN. Dlatego portu, protokołu, certyfikatu, zakresu adresów ani kryptografii nie należy zmieniać wyłącznie dla tego tunelu. Najpierw trzeba sprawdzić wpływ na istniejące połączenia użytkowników i profile.

Planowanie ról, sieci i dostępu publicznego

Firewall serwerowy powinien być stabilniejszym, a w przypadku różnych modeli także wydajniejszym urządzeniem. Jeśli tylko jedna strona ma statyczny publiczny adres IP, powinna pełnić rolę serwera. Klient może znajdować się za NAT lub korzystać z łącza z dynamicznym adresem, o ile może dotrzeć do serwera.

Przed konfiguracją trzeba ustalić następujące punkty:

publiczny adres IP lub FQDN firewalla serwerowego;
protokół i port dla SSL VPN;
sieć lokalną centrali i sieć lokalną oddziału;
jednoznaczne, niepokrywające się zakresy adresów;
wymagane usługi i dozwolone kierunki połączeń;
ścieżkę powrotną po obu stronach;
alternatywny dostęp administracyjny na czas zmiany;
aktualne wersje SFOS na obu firewallach.

Jeśli sieci się pokrywają, ta standardowa konfiguracja nie wystarczy. Potrzebny jest wtedy świadomie zaprojektowany mechanizm translacji i routingu; w praktyce lepiej sprawdza się zwykle IPsec z zaplanowanym NAT.

Sprawdzenie kompatybilności przed zmianą

Kroki konfiguracji porównano z zachowanymi tekstami pomocy dla SFOS 22 i 23, bez testowania na firewallu. Obie wersje pomocy nadal zawierają ostrzeżenie dotyczące migracji do SFOS 20.0 MR1: SFOS 20.0 MR1 i późniejsze wersje nie zestawiają połączeń SSL Site-to-Site z SFOS 18.5 ani starszymi wersjami, ani z UTM 9. Ostrzeżenie nie jest pełną macierzą kompatybilności dla wszystkich późniejszych buildów. Przed aktualizacją należy sprawdzić konkretną kombinację; w przypadku połączenia objętego ograniczeniem zaktualizować obie Sophos Firewall do kompatybilnych, wspieranych wersji albo zaplanować IPsec lub tunel RED. UTM 9 nie można po prostu zaktualizować przez zastosowanie aktualizacji SFOS.

Kontrola globalnych ustawień SSL VPN

Wspólne ustawienia znajdują się na przyszłym firewallu serwerowym w obszarze:

Remote access VPN > SSL VPN > SSL VPN global settings

W przykładzie sprawdzane są przede wszystkim następujące wartości:

Protocol: UDP jest zazwyczaj wydajniejszym wyborem początkowym; TCP może pomóc w restrykcyjnych sieciach.
SSL server certificate: musi być ważny. Certyfikat zewnętrzny importuje się z kluczem prywatnym w Certificates > Certificates; w przypadku zewnętrznego łańcucha trzeba też wczytać pośredni i główny urząd CA. Przy publicznej nazwie FQDN certyfikat powinien być zgodny z tą nazwą.
Override hostname: vpn.example.com, jeśli klienci mają używać dokładnie tej nazwy FQDN.
Port: 8443, jeśli nie zaplanowano świadomie innego schematu portów.
Assign IPv4 addresses: nie może kolidować z obiema sieciami lokalizacji ani z innymi pulami VPN.
Cryptographic settings: nie zmieniać istniejących wartości bez testu kompatybilności i działania.

Jeśli firewall serwerowy znajduje się za routerem nadrzędnym, router musi przekazywać wybrany port i protokół do firewalla. FQDN wskazuje wtedy na publiczny adres routera. WAF i SSL VPN nie mogą używać tej samej kombinacji adresu WAN IP, portu i protokołu.

Jeśli później zmienią się Port, Protocol, SSL server certificate lub Override hostname, konfigurację serwera trzeba pobrać ponownie i ponownie zaimportować na firewallu klienckim. Dotychczasowy eksport .apc nie zawiera nowych wartości.

Pełne zależności ustawień globalnych wyjaśnia artykuł Remote Access SSL VPN na Sophos Firewall. Zmiany planuje się tam z uwzględnieniem istniejących profili użytkowników, zakresów dzierżawy, DNS i usług dostępnych publicznie.

Zezwolenie na SSL VPN w strefie WAN serwera

Na firewallu serwerowym zezwala się na lokalną usługę SSL VPN dla strefy przychodzącej:

Administration > Device access

Jeśli firewall kliencki ma dynamiczny albo niemożliwy do sensownego ograniczenia adres publiczny, w sekcji VPN services włącza się SSL VPN dla WAN. Pozwala to jedynie na zestawienie tunelu do firewalla; nie zastępuje reguły firewall dla ruchu użytkowego między lokalizacjami.

To zezwolenie jest potrzebne tylko na firewallu serwerowym. Firewall kliencki zestawia tunel wychodząco, dlatego nie należy zapobiegawczo włączać tam SSL VPN dla WAN w Device Access.

Jeśli publiczne sieci źródłowe po stronie klienta są znane i stabilne, SSL VPN pozostaje wyłączone w macierzy WAN. Zamiast tego tworzy się precyzyjny wyjątek Accept Local Service ACL Exception z Source zone WAN, znanymi Source Networks/Hosts, adresem WAN serwera jako Destination host i usługą SSL VPN. Wyjątek Accept nie zawęża już aktywnego zezwolenia w macierzy WAN. Planowanie opisano w artykule Bezpieczna konfiguracja Device Access na Sophos Firewall.

Tworzenie połączenia serwerowego w centrali

Najpierw na firewallu serwerowym tworzy się obie sieci jako obiekty hostów IP:

Hosts and services > IP host

HQ-LAN: 10.10.0.0/24
Branch-LAN: 10.20.0.0/24

Następnie tworzy się połączenie serwerowe:

Otworzyć Site-to-site VPN > SSL VPN.
W obszarze Server kliknąć Add.
Wprowadzić nazwę HQ-to-Branch.
W sekcji Local networks wybrać HQ-LAN.
W sekcji Remote networks wybrać Branch-LAN.
Use static virtual IP address włączyć tylko przy uzasadnionej potrzebie i wybrać wolny adres spoza globalnych statycznych i dynamicznych zakresów SSL VPN, który nie koliduje z żadnym innym prywatnym adresem IP.
Zapisać przyciskiem Save.

Z perspektywy firewalla serwerowego Local networks to sieci centrali. Remote networks znajdują się za firewallem klienckim. Ta perspektywa jest ważna: po zamianie obiektów tunel może mieć zielony status, mimo że trasy i reguły nie odpowiadają oczekiwanemu połączeniu.

Bez Use static virtual IP address firewall automatycznie przydziela klientowi adres z zakresu dzierżawy w SSL VPN global settings. Przy stałym przydziale wybrany adres wpisuje się w Static peer IP; jest to wirtualny adres tunelu klienta, a nie sieć LAN oddziału.

Teksty pomocy podają maksymalnie 1024 hosty dla każdego z pól Local networks i Remote networks. Nie wyjaśniają tutaj, jak obiekty sieciowe są liczone w porównaniu z pojedynczymi adresami IP. Nie można z tego wywnioskować ogólnego limitu wielkości podsieci ani uznać podziału tych samych sieci za obejście. Jeśli konfiguracja zbliża się do tego limitu, należy sprawdzić wybór obiektów i zapis na konkretnym buildzie oraz wyjaśnić sposób liczenia przed zmianą w środowisku produkcyjnym.

Bezpieczny eksport konfiguracji serwera

Na liście serwerów przy HQ-to-Branch wybiera się Download. Eksport ma rozszerzenie .apc i zawiera dane połączenia dla firewalla klienckiego.

Aby bezpiecznie przesłać plik, należy włączyć Encrypt configuration file, wprowadzić i potwierdzić silne hasło tymczasowe, a następnie kliknąć Download. Plik i hasło przekazuje się oddzielnymi kanałami. Pliku .apc nie należy umieszczać w publicznym zgłoszeniu, niezabezpieczonym czacie ani stałym katalogu pobierania.

Import konfiguracji na firewallu klienckim

Na firewallu oddziału import odbywa się w tej samej ścieżce menu:

Otworzyć Site-to-site VPN > SSL VPN.
W obszarze Client kliknąć Add.
Wprowadzić nazwę Branch-to-HQ.
Kliknąć Choose file i wybrać wyeksportowany plik .apc.
Dla zaszyfrowanego eksportu wprowadzić hasło.
Use HTTP proxy server włączyć tylko wtedy, gdy oddział faktycznie osiąga serwer przez jawnie skonfigurowany HTTP proxy. Następnie wprowadzić zatwierdzony serwer proxy i jego rzeczywisty port nasłuchiwania. Proxy requires authentication włączyć tylko wtedy, gdy ten proxy wymaga logowania; użyć przeznaczonej do tego nazwy użytkownika proxy i odpowiadającego jej hasła. Nie zakładać numeru portu ani nie zmieniać globalnych ustawień proxy jako obejścia.
Override peer hostname ustawić tylko wtedy, gdy adres serwera zawarty w eksporcie nie jest routowalny lub rozwiązywalny z sieci klienta. W przykładzie pole pozostaje puste, ponieważ vpn.example.com jest już eksportowane globalnie.
Zapisać przyciskiem Save i aktywować połączenie.

Hasło do importu zaszyfrowanego pliku .apc odszyfrowuje plik; nie jest hasłem proxy. Override peer hostname określa zdalny serwer, a nie proxy. Oba hasła traktować jako poufne i nie umieszczać ich na zrzutach ekranu, w logach ani zgłoszeniach. Po zapisaniu ponownie otworzyć wpis klienta i porównać serwer proxy, port, opcję uwierzytelniania i drugą stronę z zatwierdzonymi wartościami, bez ujawniania sekretów; następnie sprawdzić tunel i ruch aplikacyjny zgodnie z opisem poniżej.

W automatyzacji przez XML API zachowane przykłady Add/Edit dla SFOS 22 i 23 pokazują ProxyServer, ProxyPort i ProxyAuthentication tylko przy HttpProxyServer = Enable, a Username i Password tylko przy włączonym uwierzytelnianiu proxy. FilePassword należy do ServerConfigurationFile; PeerHost/HostName to osobna gałąź. Tabela oznacza serwer proxy i port jako wymagane, choć przykład pokazuje je warunkowo, i podaje domyślną wartość OFF dla uwierzytelniania proxy, ale dopuszczalne wartości Disable/Enable. Nie wyprowadzać z tego serializatora ani poprawnego żądania: jeśli nie jest jasne, które pola uwzględnić lub jak zapisać wartości, wstrzymać automatyzację, użyć wspieranej ścieżki w interfejsie i wyjaśnić schemat konkretnego buildu z Sophos Support.

Status zmienia się na zielony, gdy firewall kliencki osiągnie serwer i tunel zostanie zestawiony. Zielony status potwierdza tylko samo połączenie, a nie dostęp do serwerów, DNS ani aplikacji.

Kontrola tras i reguł firewall

Sieci wybrane w Local networks i Remote networks stają się aktywne dla routingu tunelu. Należą do klasy routingu static i muszą pasować do pozostałej konfiguracji routingu. Bardziej szczegółowa trasa statyczna, SD-WAN lub VPN może w przeciwnym razie skierować ruch inną drogą niż oczekiwana. Kolejność wyjaśnia artykuł Priorytet routingu na Sophos Firewall.

Reguły firewall dla ruchu użytkowego tworzy się świadomie na obu firewallach albo porównuje z istniejącymi regułami. W przykładzie, w którym oddział inicjuje połączenia do centrali, potrzebne są co najmniej:

na firewallu oddziału precyzyjna reguła z LAN do VPN dla Branch-LAN do wymaganych celów w HQ-LAN;
na firewallu serwerowym odpowiednia reguła z VPN do LAN dla Branch-LAN do tych celów;
tylko wymagane usługi, na przykład DNS, RDP i HTTPS;
Log firewall traffic do testu odbiorczego;
brak reguły SNAT lub MASQ zmieniającej ruch między lokalizacjami bez uzasadnienia technicznego.

Te dwie reguły obejmują nowe połączenie inicjowane przez oddział oraz jego stateful ruch powrotny; ten przepływ nie wymaga dwóch dodatkowych reguł lustrzanych. Nie należy kopiować stref z instrukcji IPsec. W Log Viewer lub Packet Capture przepływ testowy musi przechodzić na firewallu oddziału z LAN do tunelu SSL VPN, a na firewallu serwerowym z tunelu SSL VPN do LAN. Jeśli obserwowana strefa, Out interface lub Rule ID jest inna, najpierw koryguje się routing i dopasowanie reguły, zamiast rozszerzać ją do Any.

Jeśli centrala ma również inicjować nowe połączenia do oddziału, kierunki odwrotne zezwala się osobno. Szeroka reguła Any nie jest gotowym projektem bezpieczeństwa. Artykuł Testowanie reguły firewall pokazuje, jak wspólnie sprawdzić pozycję reguły, Rule ID i Packet Capture.

Planowanie failover i rollbacku

Tunel SSL Site-to-Site nie należy do grupy failover IPsec. Plik .apc przekazuje klientowi wyeksportowane połączenie serwerowe. Sam FQDN lub kilka ścieżek WAN nie zapewnia bezprzerwowej redundancji: podczas zmiany WAN istniejąca sesja zostaje przerwana, a klient musi ponownie osiągnąć skonfigurowany serwer nową ścieżką. Jeśli wymagany jest automatyczny failover tunelu między kilkoma zdefiniowanymi połączeniami, należy użyć route-based IPsec.

W prostym teście failover WAN aktywny FQDN serwera musi być rozwiązywalny i osiągalny ścieżką zapasową; nadrzędny NAT i przekierowanie portów muszą tam udostępniać ten sam protokół i port SSL VPN. Następnie sprawdza się ponowne połączenie klienta oraz prawidłową obsługę dozwolonego i blokowanego ruchu użytkowego. Sam zielony tunel również tutaj nie jest kryterium odbioru.

Przed zmianą należy zapisać poprzednie globalne wartości SSL VPN, zezwolenia Device Access, wpisy serwera i klienta, reguły oraz ostatni działający plik .apc. Podczas rollbacku najpierw wyłącza się nowe reguły i połączenia, następnie przywraca poprzednie wartości globalne i ustawienia Device Access, a na kliencie importuje wcześniejszy plik .apc. Nowe obiekty usuwa się dopiero po ponownym zaliczeniu testu tunelu, testu pozytywnego i testu negatywnego.

Przed autoryzowanym usunięciem w Site-to-site VPN > SSL VPN wybrać dokładną zapisaną nazwę połączenia, firewall oraz rolę Client lub Server, sprawdzić zależne urządzenia po drugiej stronie i reguły produkcyjne oraz zachować działający eksport i ścieżkę przywracania. Zachowane strony XML Delete dla SFOS 22 i 23 oznaczają Name jako opcjonalne, ale nie zawierają przykładu żądania Delete. Nie uprawnia to do usuwania bez wskazania celu lub na szeroką skalę ani nie oznacza zamienności operacji klienta i serwera. Jeśli tożsamość celu lub schemat nie są jasne, nie wykonywać usuwania przez XML: pozostać przy wspieranej ścieżce w interfejsie i uzyskać wyjaśnienie dla konkretnego buildu. Po usunięciu sprawdzić odpowiedź właściwą dla operacji i rzeczywisty stan dokładnego wpisu docelowego; ponownie sprawdzić inne połączenia produkcyjne oraz ich dozwolony i blokowany ruch.

Testowanie tunelu i ruchu użytkowego

Test zaczyna się od konkretnego klienta i konkretnego celu. W przykładzie urządzenie z 10.20.0.0/24 uzyskuje dostęp do dozwolonego serwera w 10.10.0.0/24.

Na obu firewallach sprawdzić zielony status i rosnące liczniki bajtów.
Najpierw przetestować cel po adresie IP, a następnie po hostname.
Uruchomić rzeczywiście dozwoloną usługę, na przykład HTTPS lub RDP.
W Log Viewer sprawdzić oczekiwany Firewall Rule ID oraz niezmienione adresy źródłowe i docelowe.
Przetestować niedozwoloną usługę lub nieudostępniony cel i potwierdzić odrzucenie ruchu.
Osobno sprawdzić kierunek odwrotny, jeśli ma być dozwolony ze względów operacyjnych.
Po restarcie lub zmianie łącza WAN sprawdzić, czy firewall kliencki ponownie zestawia tunel.

Udany ping nie wystarcza. Nie potwierdza ani DNS, ani wymaganej usługi aplikacyjnej. Przy wewnętrznym systemie docelowym reguła firewall, ścieżka powrotna i firewall endpointu muszą odpowiadać testowi; Device Access ma znaczenie tylko wtedy, gdy pingowany jest adres samej Sophos Firewall.

Odczytywanie logów w razie błędu

W obszarze Site-to-site VPN > SSL VPN > Logs można bezpośrednio otworzyć logowanie SSL VPN. Aby przeprowadzić dokładniejszą kontrolę, należy zalogować się przez SSH, wybrać 5. Device Management > 3. Advanced Shell i odczytać bieżący log usługi:

tail -n 200 /log/sslvpn.log

Polecenie nie zmienia konfiguracji. Należy wspólnie udokumentować czas, nazwę połączenia oraz stronę serwerową lub kliencką. W zależności od liczby procesów mogą występować dodatkowe pliki statusu OpenVPN, takie jak openvpn-status0.log, openvpn-status1.log i kolejne; ich przypisanie opisano w artykule Logi usług Sophos Firewall.

Precyzyjne zawężanie typowych błędów

Tunel pozostaje czerwony: sprawdzić publiczną nazwę FQDN, DNS, przekierowanie portu, protokół, certyfikat i SSL VPN w Device Access dla strefy WAN serwera. Następnie odczytać sslvpn.log dla tego samego czasu.
Po zmianie ustawienia globalnego tunel już się nie zestawia: ponownie wyeksportować konfigurację serwera i zaimportować ją na kliencie. Szczególnie port, protokół, certyfikat i Override hostname zależą od eksportu.
Tunel jest zielony, ale ruch nie przepływa: sprawdzić routing tunelu, priorytet routingu, reguły na obu firewallach, Rule ID, ścieżkę powrotną, NAT i firewall endpointu. Następnie prześledzić pojedynczy przepływ w Packet Capture.
Nie działają tylko nazwy: przetestować dostęp po IP, sprawdzić serwer DNS i domenę wyszukiwania oraz upewnić się, że serwer DNS jest osiągalny i dozwolony przez tunel.
Obiekt hosta FQDN nadal wskazuje stary adres: Od SFOS 20.0 hosty i grupy FQDN można wybierać jako Local networks i Remote networks. Po zmianie DNS najpierw porównać adres rozwiązany na firewallu z oczekiwanym adresem IP, a następnie sprawdzić wybrane obiekty, trasę i pojedynczy przepływ aplikacyjny. Dostępne tutaj dowody nie potwierdzają, że rozłączenie i ponowne połączenie tunelu SSL Site-to-Site odświeża te adresy; nie przerywać działającego tunelu wyłącznie w celu wymuszenia odświeżenia DNS. Jeśli trasa pozostaje nieaktualna, zapisać build, wynik rozwiązania nazwy, trasę i logi do dalszej analizy. Nie mylić FQDN obiektu docelowego z FQDN serwera: brak rozwiązania tej drugiej nazwy może uniemożliwić samo zestawienie tunelu.
Klient osiąga serwer tylko przez proxy: użyć Use HTTP proxy server z zatwierdzonymi wartościami proxy; nie wpisywać przypadkowych danych proxy jako ogólnego workaroundu.
Awaria po migracji, z drugą stroną na SFOS 18.5 lub starszej wersji albo UTM 9: przed zmianą portu lub certyfikatu sprawdzić kombinację wersji zgodnie z opisanym wyżej ostrzeżeniem dla SFOS 20.0 MR1. Połączenie objęte ograniczeniem wymaga kompatybilnych urządzeń po obu stronach albo zaplanowanej alternatywy z IPsec lub RED.

Jeśli po kontrolowanym teście tunel nadal jest niejasny, należy zabezpieczyć wersję i build SFOS obu firewalli, czas ze strefą czasową, nazwę połączenia, sslvpn.log, Rule IDs oraz krótki Packet Capture. Dopiero potem należy dalej zmieniać reguły, sieci lub globalne wartości SSL VPN.