Przejdz do tresci
Avanet

Konfiguracja i test trasy SD-WAN Sophos Firewall

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.

Jeżeli Sophos Fusion (dawniej Sophos Central) ma generować tunele oparte na trasach i ścieżki między lokalizacjami dla wielu zarządzanych firewalli, właściwy jest artykuł Konfiguracja i weryfikacja grupy połączeń SD-WAN w Sophos Fusion. Ten artykuł opisuje lokalną trasę SD-WAN, która pozostaje istotna także podczas weryfikacji centralnie wdrożonych ścieżek.

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.

Ogólne zachowanie Active/Backup dla domyślnej ścieżki WAN opisano w artykule Konfiguracja failover WAN w Sophos Firewall, a podstawy interfejsów i bram w artykule 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.

W bardziej precyzyjnym przykładzie dla Teams dodać fikcyjną grupę Sales_Team w Users or groups oraz Teams_VoIP w Application objects. Obie nazwy zastąpić własną grupą użytkowników i faktycznie potrzebnymi aplikacjami. Wraz z interfejsem LAN, Client_Net_10.20.0.0_24, planowanymi celami i usługami kryteria kierują tylko pasujący przepływ przez WAN2/WAN1. Osobno sprawdzić wąską regułę zezwalającą z LAN do WAN dla tego źródła, celów i usług, planowane uprawnienia użytkowników oraz NAT na obu ścieżkach. Trasa SD-WAN nie przyznaje dostępu; test musi potwierdzić planowanego użytkownika, aplikację, Firewall Rule ID i NAT ID.

MPLS między oddziałem a centralą

Ograniczony przykład łączy 10.20.0.0/24 w oddziale z serwerami WWW w sieci centrali 10.30.0.0/24: interfejsem wejściowym jest LAN oddziału, primary gateway to MPLS-1, backup to MPLS-2, a usługi ogranicza się do potrzebnych TCP 80/TCP 443. Firewall centrali wymaga odpowiedniej trasy powrotnej z 10.30.0.0/24 do 10.20.0.0/24 przez własne bramy MPLS. Sieci, interfejsy, bramy i usługi to wartości przykładowe, które trzeba dostosować do rzeczywistej topologii. Osobna reguła firewalla w oddziale zezwala z LAN do rzeczywistej strefy MPLS, tutaj MPLS_DMZ, tylko dla tych sieci i usług; reguły centrali również muszą zezwalać na planowany przepływ. Ten projekt routingu zachowuje oryginalne adresy prywatne bez SNAT. Nie jest to uniwersalna reguła NAT dla każdej instalacji MPLS. Sprawdzić oba kierunki i niezmieniony adres źródłowy z rzeczywistym ruchem na obu firewallach.

Konfiguracja trasy SD-WAN

Określenie kryteriów dopasowania

Dla IPv6 wybrać konkretne hosty IP celu zamiast ogólnego destination Any. Jeśli ogólna trasa Any musi pozostać, utworzyć nad nią trasę dla konkretnych hostów IP celu i planowanej bramy; ograniczyć również incoming interface, source i services. Przed zmianą zapisać zainstalowaną kolejność za pomocą system route_precedence show, pozycję i ustawienia trasy, sprawdzić niezależny dostęp administracyjny i zaplanować odtworzenie tych wartości. Bardziej szczegółowa trasa nie uzasadnia resetowania globalnej kolejności w ciemno.

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

W klastrze HA system SFOS synchronizuje tę pamięć podręczną Application Routing przez dedykowane łącze HA, używając multicast 226.1.1.1 na porcie 4455. Restart zapory usuwa dane klasyfikacji. Po restarcie lub problemie HA należy więc nie tylko sprawdzić stan tunelu lub bramy, ale także ponownie wygenerować pierwsze i kolejne połączenie aplikacji.

Tworzenie Application Object

Silnik DPI może ponownie sklasyfikować aplikację w tym samym połączeniu, na przykład po przejściu ze strony WWW do jej czatu. Nowa decyzja dotyczy kolejnych połączeń; nie gwarantuje przekierowania bieżącego połączenia. Jeśli w okresie TTL wynoszącym 3600 sekund od rozpoczęcia sesji nie zacznie się kolejna sesja, zapisane szczegóły sesji zostaną usunięte.

Application Objects mogą obejmować aplikacje WWW, micro apps, Synchronized Security Applications wykryte na urządzeniach końcowych, aplikacje niestandardowe i kategorie aplikacji. Wybrać typ zgodnie z wymaganym rozpoznawaniem i przestrzegać opisanych wyżej ograniczeń licencji oraz DPI/proxy; cała kategoria jest szersza niż pojedyncza potrzebna aplikacja.

Application Object grupuje tylko aplikacje, które mają korzystać z tej samej ścieżki SD-WAN. Otwórz Applications > Application object, wybierz Add, nadaj nazwę i zawęź wyniki za pomocą Category, Risk, Characteristics, Technology, Classification lub wyszukiwania według nazwy. Następnie zaznacz faktycznie potrzebne aplikacje i zapisz obiekt. Sophos dynamicznie aktualizuje dostępną listę aplikacji przez aktualizacje IPS i Synchronized Application Control, dlatego po zmianach patternów lub aplikacji należy ponownie sprawdzić wybór.

Filtr Technology rozróżnia browser-based, client-server, network protocol, P2P i synchronized application control. W polu Classification dostępne są wartości new, sanctioned, unsanctioned i tolerated. Kryteria te ułatwiają wybór, lecz nie dowodzą, że późniejsza trasa działa. W tym celu potrzebne jest najpierw połączenie klasyfikacyjne, a następnie nowe połączenie testowe.

Dla Microsoft 365 jeden zbiorczy obiekt jest często zbyt szeroki. Obiekt taki jak Teams_VoIP może zawierać tylko aplikacje Teams przeznaczone do komunikacji w czasie rzeczywistym, podczas gdy OneDrive lub SharePoint korzysta z innej ścieżki. Zapisany obiekt wybiera się następnie w polu Application objects trasy SD-WAN.

Wybór bramy lub SD-WAN profile

Primary/backup gateways wystarczają dla jednej preferowanej ścieżki i fallback. SD-WAN profile rozdziela dwie decyzje: Routing strategy wybiera ścieżkę przez First available gateway lub Load balancing, a opcjonalny Service Level Agreement (SLA) dodaje do tej strategii pomiary jakości. Best quality i Custom SLA nie są więc dwiema dodatkowymi strategiami routingu.

SD-WAN profile konfiguruje się w Routing > SD-WAN profiles > Add następująco:

  1. Wpisać nazwę i opis, a następnie w Routing strategy wybrać First available gateway lub Load balancing.
  2. Przypisać od dwóch do ośmiu gateways i przeciągnąć je do wymaganej kolejności. Gateway weights pojawia się tylko przy load balancing; różne wagi mogą odzwierciedlać różną przepustowość łączy.
  3. Dla load balancing wybrać Round-robin lub odpowiedni Session persistence type. Przypisanie może opierać się na source IP, destination IP, source i destination albo pojedynczym połączeniu.
  4. Włączyć SLA tylko wtedy, gdy latency, jitter lub utrata pakietów mają wpływać na wybór. Best quality porównuje jedno kryterium. Custom SLA sprawdza latency, jitter i utratę pakietów względem ustawionych progów.
  5. Włączyć Health check, w Protocol wybrać Ping lub TCP i podać do dwóch Probe targets. Dla TCP należy też wskazać port, na którym cel niezawodnie odpowiada. Po włączeniu SLA system SFOS wymusza Health Check.
  6. Dostosować Interval between checks, Response time-out, Deactivate gateway after, Activate gateway after i Sample size for SLA do usługi. Krótkie wartości reagują szybciej, ale mogą niepotrzebnie przełączać przy chwilowej utracie pakietów; większe są stabilniejsze, lecz później wykrywają rzeczywistą awarię.
  7. Zapisać profile, wybrać go w trasie SD-WAN i sprawdzić ścieżkę rzeczywistym ruchem.

Dwa Probe Targets tworzą jeden test dostępności: SFOS uznaje gateway za aktywny, jeśli odpowiada co najmniej jeden cel. Po awarii pierwszego przechodzi na drugi i korzysta z niego, dopóki ten odpowiada. Sam powrót pierwszego celu nie powoduje natychmiastowego przełączenia. Cele powinny znajdować się za gateway i reprezentować właściwą ścieżkę; udany ping nie dowodzi działania DNS, TLS ani całej aplikacji.

Przy Best quality failback następuje dopiero wtedy, gdy pierwotny gateway jest lepszy o 10 ms pod względem latency lub o 5 ms pod względem jittera; dla utraty pakietów nie ma takiego marginesu. W Routing > SD-WAN profiles aktywny profile oznacza, że dostępny jest co najmniej jeden gateway. Link status podsumowuje konfigurację, Historical performance otwiera pomiary, a Object usage pokazuje trasy korzystające z tego obiektu SD-WAN profile. Przed edycją lub usunięciem należy sprawdzić te zależności.

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.

Przy Load balancing z Best quality ruch jest rozdzielany tylko wtedy, gdy co najmniej dwie bramy wspólnie osiągają najlepsze wyniki dla wybranego kryterium; nie każda osiągalna brama się kwalifikuje. Przy Custom SLA ruch jest rozdzielany między bramy spełniające ustawione progi SLA. Osiągalna ścieżka niespełniająca SLA nie jest tym samym co nieosiągalna brama; nie wynika z tego uniwersalna reguła fallback, gdy żadna brama nie spełnia SLA.

Gateway weights określa proporcję żądań: w udokumentowanym przykładzie 3:1 oznacza trzy z czterech żądań przez pierwszą bramę i jedno przez drugą. Wagi dobiera się do przepustowości i zasobów łączy; nie gwarantują takiej samej proporcji bajtów, określonej przepustowości ani agregacji łączy.

W Custom SLA wartości Maximum latency i Maximum jitter są podawane w milisekundach, a Maximum packet loss w punktach procentowych. Interval between checks określa odstęp między próbami, a Response time-out dopuszczalny czas odpowiedzi. Deactivate gateway after zlicza kolejne nieudane próby sondowania; Activate gateway after zlicza kolejne udane odpowiedzi. Sample size for SLA określa liczbę próbek sondowania używanych do wyznaczenia średnich parametrów bramy. Dobrać wartości do własnej usługi, zamiast traktować pojedynczy przykład czasowy jako uniwersalne ustawienie domyślne.

Uzgodnienie route precedence i NAT

Udokumentowana kolejność domyślna to Static → SD-WAN → VPN. Nie musi to być stan istniejącej instalacji: przed podjęciem decyzji nadal sprawdzać system route_precedence show i nie stosować kolejności domyślnej automatycznie.

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.

DNAT do serwera za tunelem route-based IPsec

Publiczna publikacja DNAT może wskazywać serwer wewnętrzny, który nie jest podłączony lokalnie, lecz znajduje się za zdalną zaporą i jest osiągalny przez route-based IPsec. W tym przypadku reguła DNAT i trasa SD-WAN muszą rozpoznać ten sam ruch przychodzący przed translacją, a ścieżka zwrotna musi ponownie prowadzić przez zaporę publikującą usługę.

Niezawodny proces w SFOS 22 składa się z pięciu powiązanych elementów:

  1. W Hosts and services > IP host utworzyć dokładny obiekt IP zdalnego serwera.
  2. W Routing > Gateways utworzyć gateway ze zdalnym adresem gateway i odpowiednim interfejsem XFRM. Jako cel monitorowania wykorzystać stabilnie osiągalny host za tym gateway.
  3. Ustawić regułę DNAT tak, aby odpowiadała publicznemu interfejsowi WAN i usłudze oferowanej z zewnątrz, a jako Translated destination wybrać zdalny serwer. Przykład Sophos używa MASQ, aby odpowiedzi wracały do zapory publikującej usługę; serwer nie widzi jednak wtedy pierwotnego adresu IP klienta.
  4. W trasie SD-WAN wpisać ten sam publiczny interfejs WAN w Destination networks oraz port zewnętrzny w Services. Przy PAT jest to wyraźnie port zewnętrzny, a nie przetłumaczony wewnętrzny port docelowy. Jako primary gateway wybrać gateway interfejsu XFRM.
  5. Sprawdzić wąską regułę zapory dla publikacji i przetestować ruch z sieci zewnętrznej. NAT Rule ID, Firewall Rule ID, trasa SD-WAN, wybrany gateway XFRM, ścieżki w obu kierunkach oraz adres źródłowy widoczny na serwerze muszą odpowiadać projektowi.

MASQ nie jest tu opcją kosmetyczną. W udokumentowanym przykładzie rozwiązuje ścieżkę zwrotną, ale ukrywa przed serwerem docelowym prawdziwy adres IP klienta. Jeśli zdalna lokalizacja ma sprawdzoną trasę zwrotną do pierwotnych sieci klientów i adres źródłowy ma zostać zachowany, potrzebny jest świadomie zaplanowany i osobno przetestowany projekt routingu. Ogólną publikację i zabezpieczenie opisuje Publikowanie serwera przez DNAT na Sophos Firewall.

Wiele zdalnych serwerów może korzystać z tej samej trasy SD-WAN, jeśli są osiągalne przez ten sam gateway i można je jednoznacznie dopasować według adresu WAN lub zewnętrznego portu TCP. Jeśli używają różnych gateway, należy utworzyć oddzielne trasy SD-WAN. W razie dopasowania błędnego portu, obiektu WAN lub gateway nie należy rozszerzać trasy do Any; najpierw trzeba potwierdzić przepływ przed DNAT za pomocą Log Viewer i Packet Capture.

Test i odbiór trasy

Sprawdzenie listy tras i stanu bram

W Routing > SD-WAN routes można wyszukiwać według nazwy trasy, obiektu lub wartości obiektu; na przykład 443 znajduje trasy używające usługi HTTPS. Przeciąganie zmienia kolejność. Jest to zmiana przepływu ruchu, ponieważ SFOS ocenia trasy od góry i zatrzymuje się na pierwszym dopasowaniu.

W More options można włączyć lub wyłączyć trasę, edytować ją lub sklonować, wyzerować licznik danych albo ją usunąć. Przed resetem należy zanotować wartość i czas. Sklonowana trasa jest osobną trasą: przed zapisaniem lub włączeniem trzeba sprawdzić nazwę, kryteria, pozycję, gateway i NAT, a następnie potwierdzić faktyczny stan On/Off.

Podpowiedź ikony w kolumnie Active pokazuje stany takie jak In use, Available, Unavailable, In use, but SLA isn't met lub Available and SLA isn't met. Dostępny gateway lub profile nie dowodzi ani dopasowania tej trasy, ani działania ścieżki powrotnej.

Przy bezpośrednim wyborze primary/backup ikona Active rozróżnia trzy stany: co najmniej jedna brama jest osiągalna i trasa jest aktywna; trasa nie jest aktywna, a Route only through specified gateways jest wyłączone; albo trasa nie jest aktywna i opcja jest włączona. W ostatnim przypadku ruch nadal jest odrzucany przy nieosiągalnych wskazanych ścieżkach, zamiast korzystać z innych bram. Czytać podpowiedź razem z polem wyboru i nie utożsamiać ich ze statusem SLA używanego profile.

Standardowy test z rzeczywistym ruchem

  1. Wybrać klienta testowego o znanym adresie IP i jednoznaczny cel.
  2. Włączyć logowanie w odpowiedniej regule firewall.
  3. Uruchomić rzeczywiste połączenie.
  4. W Log viewer sprawdzić source, destination, service, rule ID, NAT ID i gateway.
  5. Sprawdzić traffic count trasy SD-WAN: OUT liczy requests, a IN replies tylko wtedy, gdy source i destination pasują w danym kierunku.
  6. 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.
  7. 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.

Aby zobaczyć logi profile i trasy w widoku firewalla, wybrać moduł Firewall w Log viewer, otworzyć rozszerzony wybór przyciskiem rozwijania obok listy modułów, zaznaczyć potrzebne logi SD-WAN i kliknąć Apply. Uzupełnia to osobny widok modułu SD-WAN.

Ocena SD-WAN performance

Oś x wykresów jakości pokazuje czas; oś y pokazuje latency i jitter w milisekundach oraz utratę pakietów w punktach procentowych. Assigned weights for load balancing otwiera przypisane wagi bram. Pomiary i wagi nie stanowią odbioru aplikacji.

W Diagnostics > SD-WAN performance wybiera się używany SD-WAN profile. Alternatywnie można otworzyć Routing > SD-WAN profiles, wybrać profile i w sekcji Status kliknąć Historical performance. Dla każdego gateway widok pokazuje łączną liczbę połączeń, ilość przesłanych danych, przypisane wagi load balancing oraz latency, jitter i utratę pakietów dla okresów Live, 24h, 48h, Week lub Month.

Według Sophos komunikat No data to display oznacza, że żadna route nie korzysta jeszcze z wybranego profile albo że przez taką route nie przechodzi ruch. Nie dowodzi więc błędu pomiaru. Najpierw należy wygenerować kontrolowany przepływ przez oczekiwaną route i potwierdzić go w Log Viewer lub Packet Capture.

Reset data transfer and connection count zmienia liczniki. Przed resetem należy udokumentować wartości i czas. Nawet wykres bez widocznych anomalii nie dowodzi jeszcze, że reguła firewall, NAT, aplikacja i ścieżka powrotna działają; te warstwy nadal należą do rzeczywistego testu.

Bezpieczny test failover i failback

Przed zmianą należy zanotować bieżącą pozycję i stan On/Off trasy, primary/backup gateways lub używany profile, kolejność bram w używanym obiekcie SD-WAN profile, wartości SLA i Health Check oraz oczekiwaną translację NAT. Rollback polega na odtworzeniu dokładnie tych wartości, a następnie ponownym sprawdzeniu stanu, logów i rzeczywistego ruchu.

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. Edycja route lub profile oraz zmiana Route Precedence również mogą ponownie skierować istniejące połączenia i nie powinny należeć do tego samego testu bazowego. 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.

Świadoma zmiana reroutingu

Te ustawienia zmieniają obsługę ruchu; nie są wymagane do testu bazowego. Zmieniać je wyłącznie w oknie serwisowym, ze sprawdzonym niezależnym dostępem administracyjnym i udokumentowanym rollback: najpierw zapisać oba pokazane wyżej stany reroutingu i sprawdzić, czy obie ścieżki używają tego samego przetłumaczonego adresu źródłowego dla SNAT. W Device Console dostępne są poniższe alternatywy; wykonać tylko polecenie potrzebne do planowanej zmiany, a nie wszystkie po kolei:

  • Włączyć bez SNAT: set routing reroute-connection enable; wyłączyć: set routing reroute-connection disable.
  • Włączyć dla SNAT: set routing reroute-snat-connection enable; wyłączyć: set routing reroute-snat-connection disable.

Następnie sprawdzić show routing reroute-connection i show routing reroute-snat-connection oraz osobno przetestować sesje, adres źródłowy i oba kierunki ruchu. Aby wycofać zmianę, odtworzyć zapisany stan enable/disable każdego zmienionego ustawienia i powtórzyć kontrolę stanu oraz test rzeczywistego ruchu. Te udokumentowane polecenia i rollback nie zostały tutaj przetestowane na firewallu; włączenie reroutingu SNAT nie znosi ograniczeń MASQ/IP.

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.
  • W przypadku trasy SD-WAN zmigrowanej z SFOS 17.5 lub starszej wersji sprawdzić, czy usunięto jej pierwotną regułę zapory. Takie zmigrowane trasy pozostają powiązane ze starą regułą i są usuwane razem z nią.
  • W IPv6 funkcja Dead Gateway Detection w trasach SD-WAN nie monitoruje ruchu sieciowego innych systemów, na przykład SNMP. Brak zewnętrznego pomiaru nie jest więc wiarygodnym potwierdzeniem stanu DGD.

Artykuł Konfiguracja Direct Web Proxy z plikiem PAC opisuje listener, dystrybucję do klientów, regułę ochrony i test rzeczywistego ruchu.

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.

Web Admin i SSH są nieosiągalne po utworzeniu nowej trasy

Jeden udokumentowany scenariusz łączy cztery ustawienia: SD-WAN znajduje się przed Static, nowa trasa dla konkretnej wewnętrznej sieci źródłowej ma destination Any, routing SD-WAN dla ruchu generowanego przez system jest włączony i routing SD-WAN dla reply packets również. Dostęp administracyjny z objętej sieci wewnętrznej może wtedy zaniknąć, pozostając możliwy z innych podsieci. Nie są to warunki konieczne dla każdej awarii dostępu administracyjnego.

Korzystając ze wcześniej sprawdzonego dostępu alternatywnego, sprawdzić źródło, cel i kolejność trasy oraz poniższe wartości tylko do odczytu w Device Console:

show routing sd-wan-policy-route system-generate-traffic
show routing sd-wan-policy-route reply-packet

Najpierw sprawdzić, czy dostęp administracyjny z nieobjętej podsieci jest rzeczywiście dozwolony i osiągalny. Następnie celowo zawęzić cel lub odtworzyć jedną z wcześniej zmienionych wartości do udokumentowanego stanu początkowego. Nie wykonywać globalnego resetu w ciemno: wcześniej zapisać pozycję, ustawienia i kolejność trasy, zaplanować rollback i ponownie sprawdzić Web Admin, SSH oraz objęty ruch. Bez bezpiecznego dostępu alternatywnego nie kontynuować zmiany zdalnie.

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ę bezpośrednio po aktualizacji do SFOS 22.0 GA, należy najpierw sprawdzić zainstalowany build. SFOS 22.0 MR1 Build 490 naprawia NC-173667, który powodował losowe rozłączanie trasy SD-WAN, oraz NC-177603, przez który po aktualizacji do 22.0 GA dźwięk VoIP przez VPN route-based działał tylko w jednym kierunku. Jeśli zainstalowano już MR1 lub nowszy build, nie należy przypisywać usterki wyłącznie wersji firmware; trzeba ponownie wykonać opisany wyżej test z rzeczywistym ruchem i sprawdzić trasę, sesje, NAT oraz oba kierunki ruchu.

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