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, GRE i adresowanych XFRM, ponieważ może mieć własny Health Check oraz strefę, a następnie być używany w trasie SD-WAN.

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.

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. Dlatego przy samej trasie statycznej działanie strefy trzeba sprawdzić osobno. 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.

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

Health check jest domyślnie wyłączony. Dla monitorowanej ścieżki MPLS, RED lub XFRM należy go włączyć i rozpocząć od udokumentowanych wartości domyślnych:

• Interval: 60 sekund
• Time-out: 2 sekundy
• Retries: 3
• Protocol: PING
• IP address: 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. Dla Custom Gateway na route-based VPN, RED i MPLS Sophos wyraźnie wskazuje jako cel testu host znajdujący się za bramą.

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.

Przy kilku Monitoring Conditions obowiązuje:

• 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 Services 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.

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 zone: LAN
• Source network: 10.10.0.0/24
• Destination zone: MPLS
• Destination network: 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, GRE 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.

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

Ścieżka GRE również nie zaczyna się od obiektu gateway. Najpierw weryfikuje się zewnętrzne punkty końcowe, adresy tunelu i działanie GRE zgodnie z procedurą Konfiguracja i testowanie tunelu GRE na Sophos Firewall. Jeśli projekt operatora wymaga następnie wyboru SD-WAN, Custom Gateway używa adresu tunelu peera jako Gateway IP. Strefa, Health Check i dopasowanie reguły muszą odpowiadać konkretnemu projektowi; strefy VPN nadal nie można wybrać dla Custom Gateway.

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 Log viewer sprawdzić moduł SD-WAN pod kątem zdarzeń 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.

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. Nie zakłada się przełączenia 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.

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.

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