Tworzenie i testowanie Custom Gateway na Sophos Firewall

Custom Gateway opisuje na Sophos Firewall next hop dostępny przez istniejący interfejs. Obiekt jest szczególnie przydatny dla ścieżek MPLS, RED i adresowanych XFRM, ponieważ może mieć własny Health Check oraz strefę, a następnie być używany w trasie SD-WAN. SFOS obsługuje Custom Gateways dla IPv4 i IPv6; przykład w tym artykule używa IPv4.

Krótka odpowiedź

Custom Gateway tworzy się tutaj:

Routing > Gateways > Add

Dla ścieżki MPLS przez Port4 można na przykład wprowadzić:

• Name: MPLS_Zurich_GW
• Gateway IP: 192.0.2.2
• Interface: Port4-192.0.2.1
• Zone: MPLS
• Health check: On
• Monitoring condition: PING do 10.20.0.10

Następnie bramę trzeba wybrać w odpowiedniej trasie SD-WAN i sprawdzić razem z regułą zapory, drogą powrotną, Log viewer oraz rzeczywistym ruchem. Zielona ikona stanu potwierdza wyłącznie Health Check, a nie działanie całego połączenia.

⚠️ Custom Gateway nie jest dodatkową fizyczną bramą WAN. Nie pojawia się w Network > WAN link manager i nie uczestniczy w równoważeniu obciążenia WAN nawet po przypisaniu strefy WAN.

Rozróżnienie Custom Gateway, trasy i interfejsu

W działającej ścieżce poszczególne obiekty pełnią różne funkcje:

• Interfejs łączy zaporę z siecią tranzytową, na przykład Port4, RED lub XFRM.
• Gateway IP to bezpośrednio osiągalny następny router na tej ścieżce.
• Custom Gateway łączy Gateway IP, interfejs, strefę i opcjonalny Health Check w obiekt wielokrotnego użytku.
• Trasa SD-WAN decyduje, który ruch używa tej bramy.
• Reguła zapory zezwala na zaplanowane strefy, sieci i usługi.
• Strona zdalna wymaga odpowiedniej drogi powrotnej.

Zwykła trasa statyczna może zawierać Gateway IP bezpośrednio i nie potrzebuje osobnego obiektu bramy. Custom Gateway staje się przydatny, gdy SFOS ma monitorować ścieżkę, wybierać ją w trasie SD-WAN albo klasyfikować za pomocą strefy bramy.

Fizyczne bramy WAN są natomiast tworzone automatycznie podczas konfiguracji interfejsu WAN i zarządzane jako Active lub Backup w WAN link manager. Takie rozdzielenie zapobiega przypadkowemu traktowaniu wewnętrznej ścieżki MPLS lub tunelu jak połączenia internetowego.

W przypadku tych automatycznie utworzonych bram nie można zmienić strefy w Routing > Gateways. Brama domyślna jest na stałe przypisana do strefy WAN. Strefa bramy wybierana w poniższej procedurze dotyczy Custom Gateways, a nie bramy domyślnej.

Reguły failover bramy Cellular WAN konfiguruje się w Network > WAN link manager. Cellular WAN i failover 4G/5G opisuje konfigurację, cele kontroli łącza komórkowego i test przełączenia.

Planowanie przykładowej topologii

Spójny przykład łączy sieć klientów ze zdalną siecią serwerów przez router MPLS:

• Lokalna sieć klientów: 10.10.0.0/24
• Klient testowy: 10.10.0.10
• Interfejs zapory: Port4 z 192.0.2.1/30
• Router MPLS: 192.0.2.2
• Sieć zdalna: 10.20.0.0/24
• Stabilny host monitorujący i testowy: 10.20.0.10
• Usługa testowa: TCP 443
• Własna strefa: MPLS typu LAN

192.0.2.0/24 jest siecią dokumentacyjną i nie jest używana produkcyjnie. W rzeczywistym środowisku należy wspólnie zastąpić adres IP interfejsu i Gateway IP prawdziwą siecią tranzytową. Sieć zdalna i host monitorujący muszą faktycznie znajdować się za tą bramą. Strefę MPLS tworzy się wcześniej w Network > Zones i zabezpiecza zgodnie z poziomem zaufania ścieżki; podstawy opisuje artykuł o strefach i interfejsach na Sophos Firewall.

Przed zmianą dokumentuje się istniejącą trasę, reguły zapory, oczekiwane działanie NAT i drogę powrotną. Zdalna zmiana wymaga również kopii zapasowej konfiguracji, okna serwisowego i niezależnego dostępu administracyjnego.

Tworzenie Custom Gateway

Wprowadzanie podstawowych wartości bramy

1. Otworzyć Routing > Gateways.
2. W sekcji IPv4 kliknąć Add.
3. Jako Name wprowadzić MPLS_Zurich_GW. Nazwa jest dowolna, ale powinna identyfikować lokalizację i ścieżkę.
4. Jako Gateway IP wprowadzić 192.0.2.2. Jest to bezpośrednio osiągalny router MPLS, a nie zdalna sieć docelowa.
5. Jako Interface wybrać Port4-192.0.2.1. Gateway IP i interfejs muszą należeć do tej samej osiągalnej ścieżki tranzytowej.
6. Jako Zone wybrać MPLS.

Sophos Firewall nadaje strefie bramy priorytet przed strefą interfejsu. Stosuje ją jednak do ruchu tylko wtedy, gdy brama jest wybrana w pasującej SD-WAN policy route. Przy samej trasie statycznej strefa bramy nie jest stosowana; dopasowanie stref określają rzeczywiste strefy interfejsów i pasująca reguła zapory. Strefy VPN nie można przypisać do Custom Gateway.

Strefa bramy nie ma zastosowania do SD-WAN policy routes zmigrowanych z SFOS 18.0 MR1 lub starszych wersji. W takim przypadku samo widoczne pole strefy nie dowodzi poprawności istniejącej reguły. Trasę, dopasowanie strefy i rzeczywisty ruch należy najpierw sprawdzić w oknie serwisowym.

Istniejące Custom Gateways można również edytować, klonować i usuwać w Routing > Gateways. Przed usunięciem sprawdzić zależności zgodnie z procedurą rollback opisaną dalej.

Wybór Health Check reprezentującego ścieżkę

Health check jest domyślnie wyłączony. SFOS dokumentuje następujące domyślne wartości czasowe:

• Interval: Odstęp między sondami Health Check; wartość domyślna: 60 sekund.
• Time-out: Czas na odpowiedź na sondę, aby brama została uznana za aktywną; wartość domyślna: 2 sekundy.
• Retries: 3

Retries określa liczbę kolejnych prób kontroli. Jeśli żadna z nich nie otrzyma odpowiedzi, SFOS uznaje bramę za nieosiągalną. Sophos nie podaje pełnego wzoru na dokładny czas wykrycia awarii, dlatego Interval, Time-out i Retries należy rozpatrywać łącznie. Protocol i IP address są natomiast decyzjami projektowymi. W tym przykładzie używany jest PING do 10.20.0.10.

Host monitorujący celowo znajduje się za bramą. Gdyby sprawdzać wyłącznie bezpośrednio sąsiadujący Gateway IP, router mógłby odpowiadać mimo przerwania dalszej ścieżki MPLS lub tunelu. Sophos wymaga ogólnie, aby celem testu był stale dostępny host za bramą. Oficjalny przykład XFRM Any-to-Any również opiera się na tej zasadzie.

Alternatywnie można użyć TCP z konkretnym portem. Jest to przydatne, gdy kontrola ma obejmować nie tylko osiągalność IP, lecz także stabilnie odpowiadającą usługę. Kontrola TCP na porcie 443 uzna jednak bramę za niedostępną po awarii usługi WWW, nawet jeśli routing nadal działa. Cel i protokół kontroli muszą zatem odzwierciedlać zamierzony sygnał failover.

Aby dodać kolejną Monitoring Condition, wybrać AND lub OR w Operator i kliknąć ikonę dodawania. Następnie ustawić protokół, docelowy adres IP i, dla TCP, port dodatkowego warunku. Operatory działają następująco:

• AND: Wszystkie warunki muszą być spełnione. To rygorystyczne ustawienie, ale niedostępność jednego celu może wywołać zbędne przełączenie.
• OR: SFOS sprawdza warunki od góry do dołu, aż jeden zostanie spełniony. Ogranicza to fałszywe alarmy, ale może ukryć częściową awarię.

Nie należy skracać Interval, Time-out ani Retries bez danych pomiarowych. Najpierw mierzy się normalne opóźnienie i krótkotrwałe straty pakietów na rzeczywistej ścieżce. Zbyt agresywne wartości mogą powodować przełączanie stanu między aktywnym a nieaktywnym.

Po zapisaniu Routing > Gateways pokazuje ikoną stanu, czy Health Check uznaje bramę za aktywną czy nieaktywną.

Używanie bramy w projekcie routingu

Tworzenie trasy SD-WAN dla przykładowego ruchu

Sam obiekt bramy nie przekazuje jeszcze ruchu. Dla przykładu tworzy się trasę SD-WAN:

1. Otworzyć Routing > SD-WAN routes > IPv4 > Add.
2. Jako Name wprowadzić Clients_to_Branch_MPLS.
3. Jako Incoming interface wybrać interfejs wewnętrzny.
4. Ustawić Source networks na 10.10.0.0/24.
5. Ustawić Destination networks na 10.20.0.0/24.
6. W Service wybrać początkowo tylko HTTPS, czyli TCP 443.
7. W Link selection settings użyć Primary and backup gateways.
8. Wybrać MPLS_Zurich_GW jako Primary gateway.
9. Prawdziwą ścieżkę zapasową dodać tylko wtedy, gdy jest w pełni skonfigurowana i przetestowana.
10. Świadomie ustawić Route only through specified gateways: po włączeniu SFOS odrzuca ruch, gdy żadna z podanych ścieżek nie jest dostępna; po wyłączeniu ruch może przejąć inna trasa SD-WAN lub trasa domyślna.
11. Zapisać trasę i sprawdzić jej pozycję. Pierwsza pasująca trasa SD-WAN wygrywa.

Sieci i usługa są wartościami zależnymi od środowiska. Szeroka trasa z Any jako źródłem, celem i usługą może objąć znacznie więcej ruchu niż planowano. Dlatego na potrzeby pierwszego testu dopasowanie pozostaje wąskie i jest świadomie rozszerzane dopiero po pomyślnej weryfikacji.

Domyślna wartość Route Precedence w SFOS 22 to static, SD-WAN, VPN. Jeśli SD-WAN znajduje się przed Static, a trasa SD-WAN używa Any jako celu, może przechwycić także ruch wewnętrzny lub bezpośrednio połączony i przerwać dostęp administracyjny. Wąsko określony cel w przykładzie chroni przed tym problemem. Jeśli projekt wymaga więcej niż bramy Primary i Backup, można użyć SD-WAN Profile z maksymalnie ośmioma bramami.

Dodawanie reguły zapory i drogi powrotnej

Dla przekazywanego strumienia tworzy się logowaną regułę ze strefy źródłowej sieci klientów do strefy bramy MPLS. Źródło, cel i usługa odpowiadają trasie SD-WAN:

• Source zones: LAN
• Source networks and devices: 10.10.0.0/24
• Destination zones: MPLS
• Destination networks: 10.20.0.0/24
• Services: HTTPS
• Log firewall traffic: włączone

Strefa bramy nie zastępuje reguły zapory. Z drugiej strony sama reguła nie wymusza ścieżki MPLS. Obie muszą być zgodne z trasą SD-WAN. Ogólną konstrukcję reguł opisuje artykuł Tworzenie i bezpieczne testowanie reguł Sophos Firewall.

Router za siecią zdalną potrzebuje drogi powrotnej do 10.10.0.0/24. W normalnym routingu między lokalizacjami zazwyczaj zachowuje się oryginalny adres IP klienta. Szeroka reguła MASQ ukryłaby go i mogłaby pozornie naprawić powrót, pogarszając przy tym projekt routingu.

Rozróżnienie XFRM i innych ścieżek tunelowych

W route-based IPsec z Any-to-Any interfejs XFRM otrzymuje adres transferowy. Custom Gateway wykorzystuje wtedy adres XFRM peera jako Gateway IP, lokalny XFRM jako Interface oraz stabilny host w sieci zdalnej jako Monitoring Target. Pełna konfiguracja tunelu pozostaje w artykule Konfiguracja site-to-site VPN IPsec.

Przekazywanie wirtualnego IP przez IPsec do wielu serwerów pokazuje, jak lokalizacja zdalna dociera do wirtualnego IP przez taki gateway XFRM i lustrzane trasy SD-WAN, podczas gdy DNAT rozdziela połączenia między wiele serwerów wewnętrznych.

Route-based IPsec z konkretnymi traffic selectors działa inaczej: dla tych traffic selectors nie tworzy się dodatkowej ręcznej trasy, a XFRM nie otrzymuje własnego adresu IP. Nie należy stosować do tego wariantu recepty na bramę Any-to-Any.

Weryfikacja bramy i ruchu

Sprawdzanie stanu i użycia

1. W Routing > Gateways brama MPLS_Zurich_GW musi być aktywna.
2. Odświeżyć Object usage i sprawdzić, czy oczekiwana trasa SD-WAN używa bramy.
3. Ponownie sprawdzić kryteria dopasowania, pozycję i bramę w trasie SD-WAN.
4. W System services > Log settings sprawdzić, czy moduł SD-WAN jest logowany. Następnie w Log viewer sprawdzić zdarzenia bramy, Health Check i trasy.
5. Do głębszej diagnostyki użyć dgd.log jako dziennika Dead Gateway Detection; kontekst wyjaśnia artykuł Usługi i pliki logów Sophos Firewall.

Aktywny stan bramy dowodzi jedynie, że host monitorujący odpowiada zgodnie z wybranym warunkiem. Object Usage dowodzi tylko istnienia odwołania w konfiguracji. Dopiero kolejny test rzeczywisty potwierdza ścieżkę danych.

Testowanie rzeczywistego przepływu ruchu

1. Z klienta testowego 10.10.0.10 uruchomić nowe połączenie HTTPS do 10.20.0.10.

2. W Log viewer sprawdzić źródło, cel, usługę, Firewall Rule ID, ewentualny NAT Rule ID oraz używaną bramę.

3. Sprawdzić Traffic Count trasy SD-WAN. OUT zlicza żądania, a IN odpowiedzi, o ile dany kierunek odpowiada polom Source i Destination trasy; jednostronny licznik sam w sobie nie świadczy więc o awarii ścieżki.

4. W Diagnostics > Packet capture zastosować wąski filtr BPF:

   host 10.20.0.10 and tcp port 443
   

5. Sprawdzić, czy żądania wychodzą przez Port4, a odpowiedzi wracają tą samą zaplanowaną ścieżką.

6. Na systemie docelowym sprawdzić rzeczywisty adres źródłowy i drogę powrotną.

Policy tester nie uwzględnia tras SD-WAN. Może sprawdzić dopasowanie reguły zapory, ale nie faktycznie używaną bramę. Łączną weryfikację opisuje artykuł Testowanie reguły Sophos Firewall za pomocą Log Viewer i Packet Capture.

Test failover wykonuje się tylko z osobno zweryfikowaną ścieżką zapasową, w oknie serwisowym i z niezależnym dostępem administracyjnym. Nie należy usuwać używanej bramy produkcyjnej jako metody testowej. Po kontrolowanej awarii ścieżki ponownie sprawdza się nowe połączenie, stan bramy, publiczny lub prywatny adres źródłowy, drogę powrotną i failback. Po powrocie bramy Primary nowe połączenia ponownie jej używają, a istniejące początkowo pozostają na Backup.

SFOS 22 domyślnie przekierowuje połączenia bez SNAT po zmianie bramy lub SLA. W przypadku połączeń SNAT nie odbywa się to automatycznie. Przekierowanie z SNAT wymaga tego samego przetłumaczonego adresu źródłowego na obu ścieżkach oraz osobnej opcji reroute-snat-connection; MASQ lub różne adresy źródłowe często uniemożliwiają więc płynne przełączenie. Test odbiorczy nie zakłada przejścia bez przerwy.

Systematyczne zawężanie problemów

Brama pozostaje nieaktywna

• Gateway IP i interfejs muszą opisywać tę samą bezpośrednio osiągalną ścieżkę tranzytową.
• Host monitorujący musi faktycznie znajdować się za bramą i odpowiadać niezawodnie.
• Przy PING sprawdzić, czy ICMP jest dozwolony na całej ścieżce.
• Przy TCP sprawdzić właściwy port i rzeczywiście działającą usługę.
• Za pomocą Packet Capture sprawdzić, czy sonda i odpowiedź korzystają z oczekiwanego interfejsu.
• Interval, Time-out i Retries zmieniać dopiero po sprawdzeniu ścieżki.

XML API w SFOS 23: Dla Add Gateway Object i Update Gateway Object udokumentowano status API 505 z identyfikatorem komunikatu Message.GatewayIpNotInInterfaceIpRange. Jest to status w odpowiedzi API, a nie kod statusu HTTP; identyfikator nie gwarantuje dokładnej treści wyświetlanego komunikatu. W przypadku takiego wyniku przed ponowną próbą sprawdzić sieć wybranego interfejsu i zamierzony adres następnego skoku (Gateway IP). Udokumentowanie tego statusu w SFOS 23 nie dowodzi, że walidację adresów wprowadzono dopiero w tej wersji.

Brama jest aktywna, ale ruch aplikacji nie działa

• Trasy SD-WAN może brakować, może znajdować się zbyt nisko albo pasować do innych wartości źródła, celu lub usługi.
• Source zone i strefa bramy w regule zapory muszą odpowiadać rzeczywistemu przepływowi.
• Osobno sprawdzić Route Precedence, NAT i drogę powrotną.
• Host monitorujący może być dostępny, mimo że inny host docelowy lub usługa nie działa.
• Aktywna brama XFRM nie dowodzi automatycznie poprawności SA IPsec, reguły zapory i trasy zdalnej.

Strefa bramy wydaje się ignorowana

• Sprawdzić, czy brama jest rzeczywiście wybrana w pasującej SD-WAN policy route.
• Przy samej trasie statycznej sprawdzić strefę interfejsu i regułę zapory, która faktycznie pasuje.
• Strefa bramy nie ma zastosowania do trasy SD-WAN zmigrowanej z SFOS 18.0 MR1 lub starszego. Nie należy maskować ścieżki szeroką regułą, lecz w kontrolowany sposób zmodernizować trasę i model stref.
• Strefy VPN nie można wybrać dla Custom Gateway. Interfejs XFRM nadal pozostaje interfejsem VPN i wymaga świadomego projektu reguł oraz routingu.

Stan niepotrzebnie przełącza się między aktywnym i nieaktywnym

• Sprawdzić rzeczywistą dostępność i limity zapytań Probe Target.
• Przed zmianą wartości zmierzyć normalne opóźnienie i utratę pakietów.
• Przy AND jeden cel może zdezaktywować całą bramę.
• Przy OR dostępny cel zastępczy może ukryć częściową awarię.
• Nie używać krótszych interwałów ani Time-out jako ogólnego rozwiązania problemów ze stabilnością.

Bezpieczny rollback i eksploatacja bramy

Przed rollbackiem dokumentuje się Object Usage, pierwotną trasę i pierwotne reguły zapory. Następnie:

1. Wyłączyć nową trasę SD-WAN lub przywrócić poprzednią ścieżkę.
2. Nowym połączeniem klienta sprawdzić, czy pierwotna ścieżka znów działa.
3. Usunąć reguły zapory lub NAT utworzone wyłącznie na potrzeby testu, gdy nie pozostają już zależności.
4. Odświeżyć Object Usage.
5. Usunąć Custom Gateway dopiero wtedy, gdy nie korzysta z niego żadna trasa ani profil. Po usunięciu bramy Backup SFOS ustawia Backup trasy na None. Po usunięciu bramy Primary lub wybranego SD-WAN Profile SFOS usuwa trasę SD-WAN, a następnie używa trasy domyślnej WAN link load balance.

W eksploatacji dokumentuje się właściciela, Gateway IP, interfejs, strefę, Probe Targets, protokół, Interval, Time-out, Retries, trasy używające bramy i ostatni test failover. Po zmianach w MPLS, RED, XFRM, strefach, SD-WAN lub hoście monitorującym ponownie sprawdza się zarówno stan, jak i rzeczywisty ruch.

FAQ