Przejdz do tresci
Avanet

Konfiguracja SSL VPN Site-to-Site na Sophos Firewall

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ą

Od SFOS 20.0 MR1 Sophos używa nowszego komponentu OpenVPN. Tunele SSL Site-to-Site w SFOS 20.0 MR1 i nowszych nie łączą się z SFOS 18.5 ani starszymi wersjami, a także z UTM 9. W takiej kombinacji trzeba zaktualizować obie Sophos Firewall albo użyć IPsec lub tunelu RED.

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 i zaimportowany z kluczem prywatnym oraz pełnym łańcuchem certyfikatów. 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.

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:

  1. Otworzyć Site-to-site VPN > SSL VPN.
  2. W obszarze Server kliknąć Add.
  3. Wprowadzić nazwę HQ-to-Branch.
  4. W sekcji Local networks wybrać HQ-LAN.
  5. W sekcji Remote networks wybrać Branch-LAN.
  6. Use static virtual IP address włączyć tylko przy uzasadnionej potrzebie i wybrać wolny adres spoza globalnych statycznych i dynamicznych zakresów SSL VPN.
  7. 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.

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 i ustawić silne hasło tymczasowe. 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:

  1. Otworzyć Site-to-site VPN > SSL VPN.
  2. W obszarze Client kliknąć Add.
  3. Wprowadzić nazwę Branch-to-HQ.
  4. W sekcji Configuration file wybrać wyeksportowany plik .apc.
  5. Dla zaszyfrowanego eksportu wprowadzić hasło.
  6. Use HTTP proxy server włączyć tylko wtedy, gdy oddział faktycznie osiąga serwer przez jawnie skonfigurowany HTTP proxy.
  7. 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.
  8. Zapisać przyciskiem Save i aktywować połączenie.

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.

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.

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.

  1. Na obu firewallach sprawdzić zielony status i rosnące liczniki bajtów.
  2. Najpierw przetestować cel po adresie IP, a następnie po hostname.
  3. Uruchomić rzeczywiście dozwoloną usługę, na przykład HTTPS lub RDP.
  4. W Log Viewer sprawdzić oczekiwany Firewall Rule ID oraz niezmienione adresy źródłowe i docelowe.
  5. Przetestować niedozwoloną usługę lub nieudostępniony cel i potwierdzić odrzucenie ruchu.
  6. Osobno sprawdzić kierunek odwrotny, jeśli ma być dozwolony ze względów operacyjnych.
  7. 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: hosty i grupy FQDN są obsługiwane jako sieci lokalne i zdalne. Po zmianie DNS należy kontrolowanie rozłączyć i ponownie połączyć tunel, a następnie sprawdzić trasę oraz ruch użytkowy do nowo rozwiązanego adresu IP. Brak rozwiązania nazwy jest w pierwszej kolejności błędem ruchu lub routingu, a nie automatycznie błędem zestawiania 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.
  • Jedna strona działa na SFOS 18.5 lub UTM 9: nie szukać dalej przyczyny w porcie ani certyfikacie. Taka kombinacja jest niezgodna z aktualną drugą stroną; zaktualizować obie strony albo użyć 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.