Konfiguracja i weryfikacja grupy połączeń SD-WAN w Sophos Central

Grupa połączeń SD-WAN pozwala Sophos Central budować połączenia IPsec oparte na trasach między wieloma zarządzanymi firewallami. Eliminuje to znaczną część powtarzalnej konfiguracji w topologiach hub-and-spoke lub full mesh. Central może generować tunele, interfejsy XFRM, trasy, obiekty sieciowe oraz, po wybraniu odpowiedniej opcji, powiązane reguły firewalla.

Automatyzacja nie zastępuje planowania sieci i weryfikacji. Zielony status grupy potwierdza przede wszystkim, że uczestniczące firewalle są aktywne. Nie dowodzi, że konkretny klient może dotrzeć do zdalnego celu przez oczekiwaną regułę, trasę i obsługę NAT.

Szybka ścieżka do działającej grupy połączeń

Sprawdzić licencję Central Orchestration, zarządzanie przez Central i przynależność każdego firewalla do grupy firewalli.
Udokumentować sieci lokalne, adresy WAN, warunki NAT, redundancję i planowaną topologię.
Upewnić się, że pule adresów XFRM nie nakładają się na żadną sieć produkcyjną.
Utworzyć grupę w My Products > Firewall Management > SD-WAN Connection Groups.
Wybrać firewalle, udostępniane zasoby, usługi i opcjonalnie automatyczne tworzenie reguł firewalla.
Osobno rozwiązać każdy konflikt sieci i WAN wykryty przez Central.
Monitorować Tasks Queue i status grupy do czasu przetworzenia wszystkich uczestniczących firewalli.
Na każdym firewallu sprawdzić tunele, obiekty Central_, adresy XFRM, trasy i reguły.
Wygenerować rzeczywisty ruch dwukierunkowy i sprawdzić Firewall Rule ID, trasę, NAT i drogę powrotną.
Dalsze zasoby lub firewalle dodawać dopiero po pomyślnej weryfikacji pierwszego zakresu.

⚠️ Nie należy bez planu usuwać aktywnej grupy połączeń ani wyrejestrowywać firewalla z Central podczas normalnej pracy. Wyrejestrowanie powoduje, że Sophos Central usuwa powiązaną grupę połączeń i automatycznie utworzone tunele. Taka zmiana wymaga aktualnej kopii zapasowej, okna serwisowego i udokumentowanej drogi odzyskiwania.

Co Central tworzy automatycznie

Grupa połączeń SD-WAN wykorzystuje VPN IPsec oparty na trasach. W zależności od topologii Sophos Central tworzy wymagane połączenia i obiekty konfiguracji na firewallach należących do grupy. Automatycznie wygenerowane obiekty mają w konfiguracji lokalnej nazwy z prefiksem Central_. Obejmują między innymi połączenia IPsec, interfejsy XFRM, obiekty sieciowe i trasy.

W topologii hub-and-spoke udostępniane zasoby znajdują się za firewallem centralnym. Hub odpowiada jako zdalna brama na tunele inicjowane przez oddziały. Takie rozwiązanie pasuje na przykład do centrali z sieciami serwerowymi i wieloma oddziałami.

W topologii full mesh Central łączy każdy firewall ze wszystkimi pozostałymi członkami grupy. Może to skrócić bezpośrednie ścieżki między lokalizacjami, ale tworzy znacznie więcej tuneli i zależności. Przed wyborem trzeba więc ustalić, czy wszystkie lokalizacje naprawdę muszą komunikować się bezpośrednio ze wszystkimi pozostałymi.

Opcja automatycznego tworzenia reguł firewalla jest wygodna, ale nie zastępuje kontroli dozwolonych źródeł, celów i usług. Jeżeli opcja nie zostanie wybrana, wymagane reguły muszą istnieć lokalnie lub w odpowiedniej polityce grupy Central. Jeżeli zostanie wybrana, wygenerowane reguły nadal trzeba sprawdzić pod kątem kolejności, zakresu i logowania. Podstawy opisano w artykule Planowanie i tworzenie reguł firewalla w Sophos Firewall.

Planowanie topologii i wartości przykładowych

Poniższa przykładowa grupa połączeń łączy trzy firewalle:

FW-HQ udostępnia sieć serwerową 10.10.0.0/16.
FW-BE udostępnia sieć oddziału 10.20.0.0/16.
FW-ZH udostępnia sieć oddziału 10.30.0.0/16.
Początkowo wymagane są tylko HTTPS i RDP do wybranych systemów w sieci serwerowej.
Przykład wykorzystuje hub-and-spoke z FW-HQ jako hubem.

Te nazwy i sieci są wyłącznie wartościami dokumentacyjnymi. Należy je zastąpić rzeczywistymi nazwami firewalli, zasobami lokalnymi i usługami. Planowanie nie może ograniczać się do bezpośrednich nakładań między trzema lokalizacjami. Z planowanymi zasobami i pulami XFRM trzeba również porównać zdalne sieci chmurowe, partnerskie, klientów VPN, RED i zarządzania.

Zrozumienie pul adresów XFRM

Central używa sieci /30 dla interfejsów XFRM. Jeśli nie skonfigurowano własnej puli, Sophos Central domyślnie używa 10.252.0.0/15 i 10.254.0.0/16. Jeśli któryś z tych zakresów już występuje w środowisku, przed utworzeniem pierwszej grupy należy wybrać wolną pulę niestandardową.

Ustawienie znajduje się w:

My Products > Firewall Management > SD-WAN Connection Groups > Add IP Pool

Zmiana puli dotyczy tylko nowych grup połączeń. Istniejące grupy zachowują przypisane adresy XFRM. Zmiana puli nie jest więc działaniem naprawczym dla istniejącej grupy produkcyjnej.

Wymagania przed utworzeniem

Wszystkie uczestniczące firewalle wymagają zarządzania przez Central oraz odpowiedniej licencji Central Orchestration. Muszą też wcześniej należeć do grupy firewalli w Sophos Central. Firewall jedynie zarejestrowany, ale nieprzypisany do grupy firewalli Central, nie będzie dostępny dla grupy połączeń zgodnie z oczekiwaniami.

Przed utworzeniem należy również sprawdzić:

osiągalny publiczny adres IP lub FQDN dla każdej ścieżki WAN
nadrzędny NAT i wynikającą z niego rolę inicjatora lub respondera
unikalne zasoby lokalne bez nakładania
wolne sieci XFRM
aktywne łącza WAN i planowane bramy zapasowe
usługi dozwolone między lokalizacjami
istniejące lokalne konfiguracje IPsec, routingu, NAT i SD-WAN
niezależny dostęp administracyjny i aktualną kopię zapasową konfiguracji

Konfiguracja VPN IPsec site-to-site w Sophos Firewall wyjaśnia strukturę pojedynczego połączenia opartego na trasach. W grupie połączeń Central wykonuje wiele z tych kroków, ale podstawowe wymagania dotyczące routingu, reguł i drogi powrotnej pozostają takie same.

Tworzenie grupy połączeń w Sophos Central

Wybór firewalli i zasobów

Proces rozpoczyna się w:

My Products > Firewall Management > SD-WAN Connection Groups > Create Connection Group

Najpierw należy nadać grupie jednoznaczną nazwę, na przykład HQ-Branches, a następnie wybrać uczestniczące firewalle i topologię. Dla każdego firewalla definiuje się lokalne sieci lub hosty, które będą dostępne dla pozostałych lokalizacji jako Shared resources.

Zasoby należy dobierać możliwie wąsko. Zamiast udostępniać całą sieć centrali często wystarczy sieć serwerowa lub aplikacyjna. Również dla usług nie należy zapobiegawczo wybierać Any, jeżeli potrzebnych jest tylko kilka aplikacji.

Central może opcjonalnie tworzyć reguły firewalla. Opcje obejmują też uwierzytelnionych użytkowników i Security Heartbeat. Przed zapisaniem należy udokumentować, czy reguły są generowane automatycznie, czy zarządzane oddzielnie. Dzięki temu później będzie jasne, czy brak reguły jest błędem, czy decyzją projektową.

Rozwiązywanie konfliktów sieci i WAN

Central sprawdza wybrane zasoby i połączenia WAN pod kątem konfliktów. Konflikt nie oznacza automatycznie, że sieć jest błędna. Oznacza, że Central nie może wygenerować jednoznacznego połączenia bez dodatkowej decyzji.

W zależności od wyniku dostępne są na przykład następujące decyzje:

wyłączenie nakładającej się podsieci dla tego połączenia
przypisanie do podsieci unikalnego adresu NAT
zdefiniowanie dodatkowego obiektu sieciowego
wybór odpowiedniego łącza WAN
wybór bramy zapasowej
zastąpienie adresu wykrytego przez Central

Każda decyzja zmienia wynikową ścieżkę danych. Adresy NAT, nadpisania WAN i wyłączone sieci są więc zapisywane w planie adresacji i routingu, a nie tylko konfigurowane do momentu uzyskania zielonego statusu.

Symbol wieloznaczny * jako adres publiczny lub FQDN jest właściwy tylko po stronie zdalnej bramy działającej jako responder. Nie wolno go używać do ukrywania niewyjaśnionej sytuacji WAN lub NAT. Inicjator, DNS, publiczna osiągalność i tożsamość peera nadal muszą być jednoznaczne.

Zapisywanie grupy i monitorowanie zadań

Po zapisaniu Central tworzy wymagane zadania dla wszystkich uczestniczących firewalli. Podczas tego procesu istniejąca sesja administracyjna pozostaje otwarta na co najmniej jednym firewallu. W Central sprawdza się status i szczegóły grupy połączeń oraz:

My Products > Firewall Management > Tasks Queue

Stanów Pending, Failed lub Partial Success nie należy po prostu pomijać. Trzeba udokumentować firewall, encję, błąd i czas, a następnie porównać je z konfiguracją lokalną. Sprawdzanie Sophos Central Firewall Tasks Queue szczegółowo opisuje Retry, Skip, Force Sync i lokalną weryfikację.

Lokalna weryfikacja wygenerowanej konfiguracji

Po pomyślnym zadaniu Central należy osobno otworzyć każdy uczestniczący firewall i sprawdzić:

W Site-to-site VPN > IPsec oczekiwane połączenia Central są aktywne.
W Network > Interfaces interfejsy XFRM mają unikalne adresy /30 z planowanej puli.
W Routing wygenerowane trasy wskazują oczekiwany interfejs XFRM.
Obiekty sieciowe, hostów i usług z Central_ odpowiadają udostępnianym zasobom.
Automatycznie lub oddzielnie utworzone reguły firewalla zezwalają tylko na planowane źródła, cele i usługi.
NAT jest stosowany wyłącznie tam, gdzie świadomie wybrano go do rozwiązania konfliktu.
Przy wielu ścieżkach WAN status bramy i SD-WAN odpowiada planowanemu wyborowi podstawowemu i zapasowemu.

Central zarządza wygenerowanymi obiektami. Ręczne lokalne zmiany obiektów Central_ mogą zostać nadpisane podczas późniejszej zmiany grupy lub spowodować niespójności. Zmiany należy więc wprowadzać w projekcie grupy połączeń albo we właściwej polityce Central.

Weryfikacja za pomocą rzeczywistego ruchu

Podczas pierwszej weryfikacji wykonuje się co najmniej jeden rzeczywisty test dla każdej ścieżki udostępnianych zasobów. W przykładzie klient z 10.20.0.0/16 łączy się przez HTTPS z jawnie dozwolonym serwerem w 10.10.0.0/16, a następnie przeprowadza się test z 10.30.0.0/16.

Po obu stronach sprawdza się:

aktywne IKE i Child SA
właściwy Firewall Rule ID
interfejsy wejściowe i wyjściowe w Packet Capture
oczekiwane adresy źródłowe i docelowe po świadomie zastosowanym tłumaczeniu NAT
ścieżkę w obie strony
wynik działania aplikacji, a nie tylko ping

Zielony status tunelu lub grupy jest tylko wynikiem pośrednim. Testowanie reguły Sophos Firewall opisuje pełną weryfikację za pomocą Log Viewer, Policy Test i Packet Capture.

Dodawanie profili SD-WAN i redundancji

Central może używać profili SD-WAN dla grup połączeń, jeśli uczestniczące firewalle i interfejsy XFRM spełniają wymagania. Profil określa, jak oceniane i używane są różne bramy. Nie zastępuje poprawnej trasy ani działającego pojedynczego połączenia VPN.

Przed włączeniem profilu każdą ścieżkę WAN i tunelu należy przetestować oddzielnie. Następnie rzeczywisty ruch pozwala sprawdzić, czy nowe połączenia korzystają z planowanej ścieżki podstawowej i przełączają się na zapasową podczas zaplanowanej awarii. Health check powinien badać cel, który sensownie reprezentuje wymagany pełny tor komunikacyjny.

Lokalną logikę routingu, wartości SLA i weryfikację przełączenia opisano w Konfiguracja trasy SD-WAN w Sophos Firewall. Central upraszcza dystrybucję, ale nie zmienia znaczenia bramy, route precedence, NAT ani zachowania sesji.

Rozwiązywanie problemów według objawu

Nie można wybrać firewalla

Sprawdzić rejestrację w Central, ważną licencję lub uprawnienie Orchestration oraz przynależność do grupy firewalli Central. Następnie sprawdzić, czy otwarte zadanie grupy lub synchronizacji nie blokuje zmiany.

Zadanie zakończyło się niepowodzeniem lub tylko częściowym sukcesem

Nie należy natychmiast odtwarzać grupy. Najpierw trzeba zachować szczegóły zadania i częściową konfigurację lokalną. Częste przyczyny to konflikty obiektów lub sieci, nieosiągalne firewalle, ograniczenia licencyjne albo polityka grupy, której nie udało się zastosować w całości. Zadanie powtarza się dopiero po usunięciu przyczyny.

Tunel jest aktywny, ale brakuje ruchu aplikacji

Porównać udostępniane zasoby, wybór usług i regułę firewalla z rzeczywistym przepływem. Następnie sprawdzić trasę, interfejs XFRM, NAT, route precedence i drogę powrotną. Ping ma znaczenie tylko wtedy, gdy ICMP jest dozwolone, a cel powinien odpowiadać.

Działa tylko jedna ścieżka WAN lub zapasowa

Sprawdzić adres publiczny lub FQDN, nadrzędny NAT, rolę bramy, łącze WAN i bramę zapasową. W przypadku profilu SD-WAN przejść do celu SLA i statusu bramy. Adres wieloznaczny ani zielony tunel nie mogą maskować braku pełnej osiągalności.

Zmiana puli nie pojawia się w grupie

Jest to oczekiwane dla istniejących grup połączeń. Nowe pule IP są używane tylko przez grupy utworzone później. Nie należy usuwać i ponownie tworzyć grupy produkcyjnej tylko w celu zmiany adresacji; najpierw trzeba zaplanować wpływ, przestój i wycofanie.

Central jest zielony, ale aplikacja nadal nie działa

Status grupy nie jest monitorowaniem aplikacji. Na obu firewallach jednocześnie sprawdza się logi, Rule IDs, Packet Capture, routing i NAT. W środowisku HA lub przy rozproszonym przetwarzaniu należy użyć węzła, który obsłużył ruch testowy.

Bezpieczne zmiany i wycofanie

Przed większą zmianą grupy należy udokumentować konfigurację grupy połączeń, firewalle członkowskie, udostępniane zasoby, przypisanie WAN, pulę XFRM, automatycznie wygenerowane reguły oraz działający przepływ testowy. Należy też zachować aktualną kopię zapasową firewalla.

Jeśli rozszerzenie się nie powiedzie, nie należy odruchowo usuwać całej grupy. Najpierw usuwa się tylko nowo dodany zasób, firewall lub zmianę profilu i sprawdza, czy Central ponownie w pełni rozprowadzi poprzednią konfigurację. Następnie powtarza się lokalne testy tuneli, tras, reguł i ruchu.

Jeśli grupa połączeń musi zostać całkowicie usunięta, robi się to w oknie serwisowym. Wcześniej muszą być gotowe alternatywne ścieżki między lokalizacjami lub ręcznie zarządzane tunele. Po usunięciu na każdym firewallu sprawdza się, czy powiązane obiekty Central_ zostały usunięte i czy nie pozostały osierocone reguły, trasy lub zależności NAT.

Lista kontrolna przed uruchomieniem

Wszystkie firewalle są zarządzane przez Central, mają licencję i są przypisane do grupy firewalli.
Zasoby, usługi, ścieżki WAN i sieci XFRM są udokumentowane i nie nakładają się.
Każdy wykryty konflikt rozwiązano świadomie.
Wszystkie zadania Central zakończyły się udokumentowanym wynikiem.
Tunele, interfejsy XFRM, trasy, reguły i obiekty Central_ sprawdzono lokalnie.
Rzeczywisty dwukierunkowy test aplikacji działa dla każdej ścieżki między lokalizacjami.
Ścieżki podstawową i zapasową przetestowano w oknie serwisowym.
Kopia zapasowa, dostęp administracyjny i droga odzyskiwania są udokumentowane.

Często zadawane pytania

Czy grupa połączeń zastępuje lokalną wiedzę o IPsec i routingu?

Nie. Central automatyzuje powtarzalne tworzenie, ale ścieżka danych pozostaje opartym na trasach IPsec z interfejsami XFRM, trasami, regułami firewalla i ewentualnie NAT. Te warstwy nadal trzeba rozumieć na potrzeby rozwiązywania problemów i weryfikacji.

Co potwierdza zielony status w Sophos Central?

Pokazuje, że uczestniczące firewalle są aktywne albo że ogólny stan grupy wygląda prawidłowo. Nie dowodzi, że każdy zasób jest osiągalny przez każdą regułę i aplikację. Nadal potrzebne są kontrole lokalne i rzeczywiste połączenia testowe.

Co się dzieje po wyrejestrowaniu firewalla?

Sophos Central usuwa powiązaną grupę połączeń i utworzone tunele. Firewalla nie należy więc wyrejestrowywać i rejestrować ponownie jako rutynowego kroku rozwiązywania problemów. Taka zmiana wymaga okna serwisowego, kopii zapasowej i przygotowanej ścieżki zastępczej.