Przejdz do tresci
Avanet
Zaloguj sie

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 brama główna/zapasowa lub który profil SD-WAN 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 bramę główną lub dodać ją do profilu SD-WAN. 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.

Dwa łącza WAN z przeciwnymi priorytetami

Dla sieci LAN 10.20.0.0/24 wybrane cele publiczne mają korzystać preferencyjnie z WAN1, a pozostałe publiczne cele IPv4 z WAN2. Każde łącze jest zapasowe dla drugiego. Ten przykład planowania uzupełnia procedurę SFOS-22; dokumentacja SFOS-23-EAP potwierdza mechanizm profili, ale nie oznacza dopuszczenia dowolnego buildu.

⚠️ Nowe trasy i ich kolejność zmieniają ścieżkę danych. Najpierw zapisać pozycje tras, stany On/Off, wartości profili, NAT i aktualną Route Precedence oraz sprawdzić niezależny dostęp administracyjny. Testy awarii wykonywać tylko w zatwierdzonym oknie serwisowym; nie usuwać ani nie zmieniać współdzielonych bram lub profili na potrzeby symulacji.

  1. W Routing > SD-WAN profiles > Add utworzyć dwa osobne profile z Routing strategy: First available gateway: Ziele_WAN1_WAN2 w kolejności WAN1, WAN2 oraz Internet_WAN2_WAN1 w kolejności WAN2, WAN1. Nazwy, LAN i bramy to przykładowe wartości do dostosowania. W obu włączyć Health check; SLA pozostawić wyłączone przy tym wyborze opartym wyłącznie na dostępności. Cele sond, protokół i liczniki dobrać według opisanej niżej procedury kontroli stanu, zamiast bezrefleksyjnie przyjmować wartości domyślne. Cele muszą umożliwiać wykrywanie awarii także za bramą operatora, nie tylko jej lokalnej osiągalności.
  2. W Routing > SD-WAN routes > IPv4 > Add utworzyć szczegółową trasę LAN_Ziele_WAN1: Incoming interface to rzeczywisty interfejs LAN, Source networks obiekt dla 10.20.0.0/24, Destination networks aktualizowana grupa wybranych celów publicznych, a Services tylko potrzebne usługi. Wybrać Ziele_WAN1_WAN2. Dla domen najpierw uwzględnić ograniczenia hostów i grup FQDN; nazwa domeny nie gwarantuje wyłącznego zakresu docelowych adresów IP.
  3. Poniżej utworzyć LAN_Internet_WAN2 z tym samym interfejsem LAN i siecią źródłową, Destination networks: Internet IPv4 group, zatwierdzonymi usługami internetowymi i Internet_WAN2_WAN1. Trasa szczegółowa musi znajdować się powyżej ogólnej trasy internetowej. Nie używać globalnej trasy Any; cele wewnętrzne i VPN nie należą do tej ścieżki internetowej.
  4. Świadomie ustawić Route only through specified gateways dla obu tras: tutaj opcja jest włączona, aby przy awarii obu przewidzianych ścieżek nie przejęła ruchu żadna inna. Osobno sprawdzić odpowiednie zezwolenia firewalla i MASQ/SNAT dla obu WAN. Jeśli druga strona wymaga stałego publicznego IP, musi dopuszczać również zapasowy adres IP.

W ramach weryfikacji zestawić nowe połączenie do jednego celu szczegółowego i jednego z pozostałych publicznych: początkowo oczekiwane są odpowiednio WAN1 i WAN2. Następnie w zatwierdzonym środowisku testowym oddzielnie sprawdzić obie awarie po stronie operatora, także przy nadal aktywnym interfejsie fizycznym: gdy zawiedzie WAN1, nowe połączenia obu klas celów muszą działać przez WAN2; gdy zawiedzie tylko WAN2, przez WAN1. Po każdym przywróceniu porównać nowe połączenia z przewidzianym priorytetem, a istniejące sesje obserwować osobno. Potwierdzić trasę, bramę i SNAT/publiczny IP w logach lub Packet Capture oraz ponownie sprawdzić DNS, HTTPS i wewnętrzny dostęp administracyjny. Nie wynika z tego stały czas przełączenia ani nieprzerwane przejęcie istniejących sesji.

Przy nieoczekiwanej ścieżce nie rozszerzać kryteriów: najpierw porównać dopasowania tras, kolejność, stan i NAT. W celu wycofania wyłączyć nowe trasy albo przywrócić wcześniej zapisane wartości tras, profili i NAT wraz z kolejnością; potem ponownie sprawdzić stan i oba przepływy testowe. Bez izolowalnej symulacji awarii ta część weryfikacji pozostaje otwarta. Szczegółowe ograniczenia sesji i SNAT opisano niżej w części o Bezpieczny test failover i failback.

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ć profil SD-WAN lub bramę główną i zapasową.
  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 profilu SD-WAN

Bramy główna i zapasowa wystarczają dla jednej preferowanej ścieżki i ścieżki awaryjnej. Profil SD-WAN 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.

Profil SD-WAN 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 bram 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. Te ustawienia pełnią różne funkcje: Interval between checks i Response time-out sterują sondowaniem; Deactivate gateway after zlicza nieudane próby, a Activate gateway after udane odpowiedzi. Sample size for SLA określa liczbę próbek dla średnich parametrów bramy. Dostosować osobno wykrywanie awarii i ponowną aktywację; pięć wartości nie tworzy jednego wspólnego zegara failover.
  7. Zapisać profil, wybrać go w trasie SD-WAN i sprawdzić ścieżkę rzeczywistym ruchem.

Dwa cele sondowania tworzą jeden test dostępności: SFOS uznaje bramę za aktywną, 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 bramą 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 pierwotna brama jest lepsza 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 profil oznacza, że dostępna jest co najmniej jedna brama. Link status podsumowuje konfigurację, Historical performance otwiera pomiary, a Object usage pokazuje trasy korzystające z tego profilu SD-WAN. 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 bramy zapasowej ustawia ją w Sophos Firewall na None; usunięcie bramy głównej lub profilu SD-WAN 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.

Round-robin rozdziela żądania kolejno między kwalifikujące się bramy. Przy trzech dostępnych bramach o jednakowych wagach i bez ograniczenia SLA przykład używa pierwszej, drugiej, trzeciej i ponownie pierwszej bramy. Session persistence type utrzymuje powiązane sesje na tej samej bramie według wybranego klucza, na przykład w bankowości lub koszykach zakupowych. Jeden przepływ testowy nie pokazuje rozkładu wielu niezależnych sesji.

Gdy żadna brama nie spełnia Custom SLA

Odrzucanie przy nieosiągalnych bramach nie dowodzi twardej blokady SLA dla ścieżek, które nadal są osiągalne. Bez dowodów dla konkretnego buildu nie gwarantować w tym przypadku ani kontynuacji Load balancing, ani wyłącznego użycia First available gateway.

  1. Zapisać build SFOS, profil, Routing strategy, kolejność bram, wagi, session persistence, progi SLA, probe targets i Route only through specified gateways.
  2. Użyć Link status, Historical performance i logów SD-WAN, aby odróżnić osiągalne ścieżki niespełniające SLA od rzeczywiście nieosiągalnych.
  3. Testować tylko z zatwierdzonym, odizolowanym przepływem w oknie serwisowym i z niezależnym dostępem administracyjnym. Nie zmieniać współdzielonych profili produkcyjnych w celu symulacji awarii ani nie usuwać bram lub profili. Utworzyć nowe połączenia i potwierdzić bramę, IP SNAT i wynik aplikacji przez Log Viewer i Packet Capture; istniejące sesje ocenić oddzielnie.
  4. Odtworzyć zmienione wartości testowe do udokumentowanego stanu początkowego i powtórzyć kontrole stanu oraz test rzeczywistego ruchu. Bez zatwierdzonego testu wybór pozostaje nierozstrzygnięty; wyjaśnienie dla konkretnego buildu wymaga konfiguracji, pomiarów, znaczników czasu i logów wraz z buildem.

Wynik dla jednego buildu i profilu nie jest ogólną gwarancją failover.

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ć bramę ze zdalnym adresem IP bramy i odpowiednim interfejsem XFRM. Jako cel monitorowania wykorzystać stabilnie osiągalny host za tą bramą.
  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 bramę główną wybrać bramę 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, wybrana brama 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 tę samą bramę i można je jednoznacznie dopasować według adresu WAN lub zewnętrznego portu TCP. Jeśli używają różnych bram, należy utworzyć oddzielne trasy SD-WAN. W razie dopasowania błędnego portu, obiektu WAN lub bramy 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ę, bramę 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ępność bramy lub profilu 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 profilu.

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ć licznik ruchu trasy SD-WAN: OUT zlicza żądania, a IN odpowiedzi tylko wtedy, gdy źródło i cel odpowiadają danemu kierunkowi.
  6. W System services > Log settings włączyć typ SD-WAN i sprawdzić moduł SD-WAN w Log Viewer pod kątem zdarzeń profili, SLA i tras.
  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 profili i tras 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 profil SD-WAN. Alternatywnie można otworzyć Routing > SD-WAN profiles, wybrać profil i w sekcji Status kliknąć Historical performance. Dla każdej bramy 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 trasa nie korzysta jeszcze z wybranego profilu albo że przez taką trasę nie przepływa ruch. Nie dowodzi więc błędu pomiaru. Najpierw należy wygenerować kontrolowany przepływ przez oczekiwaną trasę 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, bramę główną i zapasową lub używany profil, kolejność bram w używanym profilu SD-WAN, 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ć bramę główną i sprawdzić ścieżkę, sesje, publiczny adres źródłowy IP oraz drogę powrotną. Nie należy usuwać bramy głównej ani profilu SD-WAN, ponieważ usuwa to trasę i testuje wyłącznie przełączenie na trasę domyślną. Edycja trasy lub profilu 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 bramy głównej i zapasowej nowe połączenia po powrocie bramy głównej znów jej używają, a istniejące połączenia zasadniczo pozostają na bramie zapasowej.

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. 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ć licznika ruchu jako jedynego dowodu, ponieważ żądania i odpowiedzi są liczone tylko przy pasujących kryteriach źródła i celu.
  • 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 bramę główną lub profil SD-WAN, 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.

XML-API: wyjaśnienie granic obiektów przed automatyzacją

Dokumentacja XML-API dla SFOS 22.0 i 23.0 opisuje odrębne nazwane obiekty. Opisana powyżej konfiguracja w interfejsie użytkownika pozostaje praktyczną procedurą, ale nie można na jej podstawie wywnioskować jednoznacznego kontraktu XML. Poniższe uwagi wskazują sprzeczności w dokumentacji; przed zapisem trzeba wyjaśnić obsługiwaną postać żądania i schemat. Automatyzacja wymaga wyjaśnienia przez Sophos znaczenia odpowiednich pól dla konkretnej wersji; nie proponujemy tutaj domniemanego mapowania liczbowego ani gotowego do wykonania żądania XML.

Nazwany HealthCheckProfile: cykl życia i liczniki sondowania

HealthCheckProfile jest samodzielnym obiektem kontroli kondycji, a nie obiektem SDWANProfile ani wbudowaną opcją kontroli kondycji bramy. Podczas tworzenia i aktualizacji obowiązkowe skalarne pole tekstowe Name identyfikuje profil kontroli kondycji; obie tabele pól podają maksymalną długość 125 znaków. Tabela dla 22.0 dodatkowo zabrania przecinków i wyraźnie dopuszcza znaki UTF-8, natomiast tabela dla 23.0 nie zawiera tych dwóch informacji. Ich brak nie dowodzi zmiany walidacji nazw.

ProbeTargets opisano jako tablicę obiektów monitorDetails, natomiast przykład zawiera elementy ProbeTarget. Dla monitormethod podano TCP lub PING; dla monitorip wymieniono typy danych IPADDRESS, IPADDRESS6 i DOMAINNAMELOOKUP. Dla operator podano literały & i |, z wartością domyślną |. Nie wyprowadza się z tego ani innej struktury XML, ani zgodności z opisanym powyżej zachowaniem dwóch Probe Targets w interfejsie użytkownika. Również IPFamily pozostaje sprzeczne: obie tabele wymieniają IPv4 i IPv6, z wartością domyślną IPv4, a jednocześnie podają maksymalną długość 1 znaku.

Opisy obu liczników wydają się zamienione względem ich nazw: ProbesResponseFailure opisuje dosłownie kolejne odpowiedzi wymagane do aktywacji obiektu, z wartością domyślną 1; ProbeResponseSuccess opisuje kolejne próby sondowania bez odpowiedzi przed dezaktywacją obiektu, z wartością domyślną 3. Obie tabele podają dla każdego z nich zakres od 1 do 10. Nie korygujemy po cichu tego przyporządkowania w dokumentacji; nie stanowi ono też potwierdzenia zachowania podczas działania systemu. W szczególności nie przenosimy automatycznie wiarygodnych objaśnień ustawień Deactivate gateway after i Activate gateway after w interfejsie użytkownika na te znaczniki API.

Odrębna operacja usuwania również wskazuje profil kontroli kondycji przez Name, a nie trasę ani profil SD-WAN. Przed planowanym usunięciem należy sprawdzić profile SD-WAN odwołujące się do tego obiektu i udokumentować ich dotychczasowe przypisanie kontroli kondycji. Źródła nie potwierdzają bezpiecznego przebiegu usuwania kaskadowego ani zachowania przy usuwaniu obiektu kontroli kondycji, do którego nadal istnieją odwołania. Nie należy utożsamiać tego z opisanym powyżej usuwaniem profilu SD-WAN; takie usunięcie nie jest też testem awarii.

HealthCheckProfileStatus: stan administracyjny obiektu kontroli kondycji

HealthCheckProfileStatus administracyjnie włącza lub wyłącza nazwany profil kontroli kondycji. Selektorem jest obowiązkowe skalarne pole tekstowe Name; przykładowy symbol zastępczy HealthCheckProfileStatusName nie zmienia tożsamości tego pola. W obu wersjach przykład podaje dla Status wartość ON/OFF, natomiast wiersz obowiązkowego pola wskazuje INTEGER bez mapowania liczbowego. Nie potwierdza to liczbowej reprezentacji stanu włączenia lub wyłączenia. Ta operacja administracyjna nie jest pomiarem dostępności bramy, stanem aktywności profilu SD-WAN ani włączeniem lub wyłączeniem trasy. Sam udokumentowany komunikat o powodzeniu nie dowodzi rzeczywistej zmiany stanu; należałoby sprawdzić stan administracyjny dokładnie tego nazwanego obiektu, niezależnie od wskaźników dostępności.

SDWANPolicyRouteStatus: sprawdzenie właściwej trasy i właściwego stanu

SDWANPolicyRouteStatus używa obowiązkowego skalarnego selektora tekstowego SDWANPolicyRouteName, a nie pola Name profilu kontroli kondycji. Przykłady dla obu wersji ponownie pokazują ON/OFF dla Status, podczas gdy wiersz obowiązkowego pola podaje INTEGER bez mapowania liczbowego. Udokumentowany kod wyniku 200 nie stanowi niezależnego potwierdzenia, że wybrana trasa zmieniła stan administracyjny. W tym celu należałoby sprawdzić rzeczywisty stan On/Off tej trasy. Podpowiedź Active, osiągalność bramy oraz decyzja o odrzuceniu ruchu lub użyciu ścieżki zastępczej wynikająca z Route only through specified gateways odpowiadają na inne pytania i nie rozstrzygają sprzecznego kontraktu XML dotyczącego stanu.

SDWANProfile: rodzina adresów, strategia i odrębne odwołanie do kontroli kondycji

W obiekcie SDWANProfile pole Name oznacza sam profil SD-WAN i ma maksymalną długość 60 znaków. Natomiast obowiązkowe skalarne pole tekstowe HealthCheckProfileName jest odwołaniem do odrębnego profilu kontroli kondycji i ma maksymalną długość 85 znaków. Nie jest to ta sama tożsamość ani ta sama udokumentowana długość nazwy co jego pole Name, dla którego podano 125 znaków. Dlatego granice obiektu i liczników HealthCheckProfile obowiązują również przy przygotowywaniu tego odwołania; wbudowane ustawienia kontroli kondycji nie zastępują wymaganego odwołania do nazwanego obiektu.

Oba przykłady profilu i opisy pól podają dla IPFamily wartość IPv4/IPv6, ale wiersz walidacji dopuszcza tylko IPv4, a jednocześnie określa maksymalną długość 1 znaku. Trasy IPv6 w interfejsie użytkownika nie dowodzą więc obsługi IPv6 w tym kontrakcie XML profilu. Dla SLAStrategy przykład i opis podają BestQuality, natomiast lista dozwolonych wartości zawiera BestQualityv; CustomSLA występuje w obu miejscach. Dla LBMethod przykład podaje WRR/SrcSticky/DestSticky/SrcDestSticky/ConnectionSticky, a tabela wskazuje INTEGER w zakresie od 0 do 5 bez przyporządkowania do tych wartości tekstowych. Dla IsLatency podano wartość domyślną 1, podczas gdy dozwolone literały to OFF i ON. Żadnej z tych rozbieżności nie rozstrzygamy przez domniemaną korektę pisowni, reprezentację liczbową ani wywnioskowane mapowanie wartości logicznych. Opisane powyżej strategie i procedury weryfikacji w interfejsie użytkownika pozostają przydatne, ale nie dowodzą poprawności gotowego do wykonania żądania dotyczącego profilu.

Eksploatacja i dokumentacja

Dla każdej produkcyjnej trasy SD-WAN należy dokumentować cel, incoming interface, source/destination, services, bramę lub profil, 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