Konfiguracja i test trasy SD-WAN Sophos Firewall

16. LIPCA 2026 Sophos Firewall

Trasa SD-WAN określa, przez którą bramę Sophos Firewall kieruje zdefiniowany przepływ ruchu. Jest przydatna przy wielu łączach internetowych, MPLS, VPN IPsec route-based, VoIP lub usługach chmurowych. Trasa musi mieć precyzyjne kryteria i zostać przetestowana z rzeczywistym ruchem, w przeciwnym razie może objąć sieci wewnętrzne lub podczas failover użyć niewłaściwego publicznego adresu IP.

Krótka odpowiedź

Trasę SD-WAN tworzy się tutaj:

Routing > SD-WAN routes > IPv4 / IPv6 > Add

Wcześniej trzeba określić cztery elementy:

jaki ruch ma pasować na podstawie incoming interface, source, destination i service
która primary/backup gateway lub który SD-WAN profile ma być używany
czy dozwolone są wyłącznie te bramy i jaki NAT jest z nimi zgodny
jak sprawdzić trasę, bramę i drogę powrotną za pomocą Log Viewer i Packet Capture

Dla publicznych celów IPv4 nie należy ogólnie używać Any; w miarę możliwości lepiej wybrać Internet IPv4 group lub konkretne cele. Jeśli SD-WAN znajduje się przed Static w route precedence, szeroka trasa Any może również skierować ruch wewnętrzny do bramy WAN.

Wideo uzupełnia instrukcję planowania, konfiguracji i weryfikacji tras SD-WAN na Sophos Firewall.

Zastosowanie i planowanie

Kiedy wybrać SD-WAN zamiast trasy statycznej

Trasa statyczna wystarcza, gdy sieć docelowa jest zawsze osiągalna przez stały next hop. Trasy SD-WAN dodają kryteria, takie jak source, service, użytkownik lub aplikacja, i mogą wybierać bramy według dostępności lub jakości.

Typowe zastosowania:

kierowanie wybranych klientów lub usług przez WAN2 i przełączanie na WAN1 w razie awarii
wysyłanie VoIP lub aplikacji chmurowych ścieżką o niskim opóźnieniu i małej utracie pakietów
używanie MPLS, LTE/5G lub tunelu IPsec route-based jako ścieżki głównej lub zapasowej
przypisanie ruchu do operatora, którego publiczny adres IP jest dozwolony po stronie zdalnej

Przykład planowania i wymagania

Przed utworzeniem trasy należy opisać konkretny przepływ. Dla ruchu Microsoft 365 plan może wyglądać następująco:

Incoming interface: wewnętrzny interfejs LAN
Source network: Client_Net_10.20.0.0_24
Destination: samodzielnie utrzymywana grupa celów Microsoft 365 lub Internet IPv4 group
Services: HTTPS oraz w razie potrzeby grupa usług dla UDP 3478-3481
Primary gateway: WAN2
Backup gateway: WAN1
Fallback: zezwolenie na default route lub włączenie Route only through specified gateways
NAT: MASQ lub stały adres SNAT odpowiedni dla wybranej bramy
Test: określony adres IP klienta, cel, oczekiwana brama i oczekiwany wpis logu

Potrzebne są również odpowiednie reguły firewall, reguły NAT dla ruchu wymagającego translacji, włączone logowanie oraz dostęp do Log viewer i Diagnostics > Packet capture. Bramy WAN znajdują się w Network > WAN link manager; custom gateways dla MPLS, RED lub XFRM tworzy się w Routing > Gateways. Podstawy opisano w Konfiguracja stref i interfejsów Sophos Firewall.

W IPsec route-based kierunek ma znaczenie: Interfejs XFRM wybrany jako Incoming interface dopasowuje ruch przychodzący z tunelu. Dla ruchu LAN do VPN należy natomiast wybrać bramę interfejsu XFRM jako primary gateway lub dodać ją do SD-WAN profile. Podstawy opisano w Tworzenie trasy IPsec na Sophos Firewall.

Konfiguracja trasy SD-WAN

Określenie kryteriów dopasowania

Otworzyć Routing > SD-WAN routes.
Wybrać IPv4 lub IPv6 i kliknąć Add.
Wprowadzić jednoznaczną nazwę, na przykład Clients_M365_WAN2.
Wybrać Incoming interface, przez który wchodzi sterowany ruch.
Opcjonalnie wybrać wartość DSCP, jeśli pakiety przychodzące są wiarygodnie oznaczone.
Określić Source networks i w razie potrzeby dodać Users or groups.
Ograniczyć Destination networks tak precyzyjnie, jak to możliwe.
Ograniczyć Services do wymaganych protokołów i portów.
Opcjonalnie wybrać Application objects.
W Link selection settings wybrać SD-WAN profile lub primary/backup gateways.
Świadomie włączyć lub wyłączyć Route only through specified gateways.
Zapisać trasę i ustawić ją we właściwej kolejności; wygrywa pierwsza pasująca trasa SD-WAN.
Przetestować z określonym klientem i celem.

Application Objects wymagają aktywnej Web Protection License. Pierwsze połączenie jest kierowane na podstawie destination IP, portu, protokołu i incoming interface przez inną pasującą trasę SD-WAN lub, jeśli jej nie ma, przez default route. Application Object zaczyna działać dla kolejnych połączeń dopiero po rozpoznaniu aplikacji. Dane klasyfikacji mają TTL wynoszący 3600 sekund od rozpoczęcia sesji. W przypadku Micro Apps tylko DPI Engine Mode obsługuje wszystkie aplikacje; Web Proxy Mode obsługuje wyłącznie Pattern Applications i Synchronized Security Applications.

Wybór bramy lub SD-WAN profile

Primary/backup gateways wystarczają dla jednej preferowanej ścieżki i fallback. Aby użyć SD-WAN profile, należy utworzyć co najmniej dwie bramy, następnie profile w Routing > SD-WAN profiles i wybrać go w trasie. Profile jest przydatny przy wielu ścieżkach, load balancing lub kryteriach SLA:

First available gateway używa pierwszej dostępnej bramy w określonej kolejności.
Load balancing rozdziela połączenia; Session Persistence i Gateway Weights sterują przypisaniem i rozkładem.
Best quality porównuje dokładnie jedno kryterium: opóźnienie, jitter lub utratę pakietów.
Custom SLA wymaga progów dla wszystkich trzech kryteriów i przy ich niespełnieniu używa wybranej strategii routingu.

Health Checks testują za pomocą ping lub TCP do dwóch Probe Targets. Cele powinny reprezentować właściwą ścieżkę, ale nie dowodzą, że działa cała aplikacja. Przy Best Quality failback następuje dopiero wtedy, gdy pierwotna brama jest lepsza o 10 ms pod względem opóźnienia lub o 5 ms pod względem jittera; dla utraty pakietów nie ma takiego marginesu.

Gdy Route only through specified gateways jest aktywne, firewall odrzuca ruch, jeśli wskazane ścieżki są niedostępne. Bez tej opcji sprawdza kolejne trasy SD-WAN, a następnie default route. Usunięcie backup gateway ustawia ją w Sophos Firewall na None; usunięcie primary gateway lub SD-WAN profile usuwa trasę, więc ruch może przejąć default route.

Uzgodnienie route precedence i NAT

Route precedence określa kolejność między Static, SD-WAN i VPN. Sieci bezpośrednio połączone oraz SSL VPN należą do kategorii Static. Aktualna kolejność jest widoczna w Routing > SD-WAN routes lub Device Console; zmiany i rollback wyjaśnia Bezpieczna zmiana route precedence w Sophos Firewall.

Routing wybiera ścieżkę, a NAT zmienia adresy. Ruch internetowy przez WAN2 może więc wymagać MASQ lub stałego adresu SNAT na tej ścieżce. W sieciach wewnętrznych i VPN NAT jest natomiast często niepożądany. Zależności opisano w NAT w Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Test i odbiór trasy

Standardowy test z rzeczywistym ruchem

Wybrać klienta testowego o znanym adresie IP i jednoznaczny cel.
Włączyć logowanie w odpowiedniej regule firewall.
Uruchomić rzeczywiste połączenie.
W Log viewer sprawdzić source, destination, service, rule ID, NAT ID i gateway.
Sprawdzić traffic count trasy SD-WAN: OUT liczy requests, a IN replies tylko wtedy, gdy source i destination pasują w danym kierunku.
W System services > Log settings włączyć typ SD-WAN i sprawdzić moduł SD-WAN w Log Viewer pod kątem zdarzeń profile, SLA i route.
W razie niejasności ustawić w Diagnostics > Packet capture precyzyjny filtr na klienta, cel i port.

Policy tester nie uwzględnia tras SD-WAN. Może sprawdzać dopasowania policy, ale nie potwierdza wybranej trasy SD-WAN ani faktycznej bramy. Pełną analizę opisano w Testowanie reguł Sophos Firewall z Log Viewer, Policy Test i Packet Capture.

Bezpieczny test failover i failback

Kontrolowany test awarii należy wykonać w oknie serwisowym, z udokumentowanym rollback i niezależną ścieżką zarządzania do firewalla. Najpierw w Device Console należy sprawdzić aktualne wartości statusu tylko do odczytu:

system route_precedence show
show routing reroute-connection
show routing reroute-snat-connection

Następnie uruchomić rzeczywisty ruch aplikacji, kontrolowanie wyłączyć primary gateway i sprawdzić ścieżkę, sesje, public source IP oraz drogę powrotną. Nie należy usuwać primary gateway ani SD-WAN profile, ponieważ usuwa to trasę i testuje wyłącznie fallback do default route. Przy bezpośrednim wyborze primary/backup nowe połączenia po powrocie znów używają primary, a istniejące połączenia zasadniczo pozostają na backup gateway.

reroute-connection jest domyślnie aktywne i dotyczy połączeń bez SNAT. Połączenia SNAT nie są domyślnie przekierowywane; nawet przy osobno aktywowanym reroute-snat-connection działa to tylko wtedy, gdy obie ścieżki używają tego samego przetłumaczonego source IP. Przy MASQ lub różnych adresach Override Source Translation połączenie SNAT nie jest przekierowywane, a istniejąca sesja zostaje przerwana po awarii ścieżki.

Systematyczne rozwiązywanie problemów

Trasa nie pasuje

Porównać incoming interface, source network, destination i service z rzeczywistym przepływem.
Sprawdzić kolejność; wygrywa pierwsza pasująca trasa SD-WAN.
Dla Application Objects sprawdzić licencję, rozpoznawanie DPI i drugie połączenie po klasyfikacji.
Nie traktować traffic count jako jedynego dowodu, ponieważ requests i replies są liczone tylko przy pasujących kryteriach source i destination.
Przy Direct Web Proxy dopasowanie service HTTP/HTTPS nie wystarcza: użyć Any lub service dla portu skonfigurowanego w Web > General settings > Web proxy listening port. W tym przypadku source network i incoming interface nie pasują dla reply packets; droga powrotna proxy wymaga też WAN default gateway lub odpowiedniej trasy statycznej.

Dla reply packets i system-generated traffic obowiązują osobne przełączniki i zasady dopasowania. Wyjaśnia je Sprawdzanie SD-WAN routing dla reply packets i system traffic w Sophos Firewall.

Ruch wybiera niewłaściwą ścieżkę

Dla publicznych celów IPv4 zastąpić Any przez Internet IPv4 group lub konkretne cele.
Sprawdzić route precedence, zwłaszcza gdy dotyczą tego sieci wewnętrzne, SSL VPN lub IPsec policy-based.
Sprawdzić status gateway i SLA oraz Health Check Targets.
Porównać regułę NAT i przetłumaczony source IP z faktycznie używaną bramą.
Sprawdzić, czy usunięto primary gateway lub SD-WAN profile, a wraz z nim trasę.

Aplikacja lub odpowiedź przestaje działać po failover

Najpierw za pomocą Packet Capture należy sprawdzić, czy pakiet wychodzi przez oczekiwaną bramę i czy odpowiedź wraca. Następnie sprawdzić NAT, allowlisty publicznych adresów IP, Session Persistence, MTU/MSS oraz stan ścieżki VPN lub MPLS. Szczególnie SIP/RTP, portale bankowe i API ze stałym source IP trzeba testować z rzeczywistym ruchem aplikacji.

Jeśli problem rozpoczął się po aktualizacji firmware, przed większymi zmianami reguł należy sprawdzić aktualne informacje o wydaniu SFOS 22.0. SFOS 22.0 MR1 naprawia między innymi losowe przerwy SD-WAN oraz jednostronny dźwięk przez VPN route-based z SD-WAN routing.

Eksploatacja i dokumentacja

Dla każdej produkcyjnej trasy SD-WAN należy dokumentować cel, incoming interface, source/destination, services, gateway lub profile, fallback, oczekiwany NAT, klienta i cel testowy, ownera oraz datę przeglądu. Po zmianach operatora, VPN, interfejsu lub usługi chmurowej trzeba ponownie sprawdzić dopasowanie, logi i failover.

Trasa jest odebrana dopiero wtedy, gdy:

kryteria dopasowania obejmują wyłącznie planowany ruch
reguła firewall, NAT i route precedence są zgodne z projektem
Log Viewer i Packet Capture potwierdzają oczekiwaną ścieżkę
failover, failback i public source IP działają zgodnie z dokumentacją
określono osobę odpowiedzialną i termin kolejnego przeglądu