Bezpieczna zmiana Route Precedence w Sophos Firewall

Route Precedence globalnie określa, czy Sophos Firewall najpierw ocenia Static Routes, SD-WAN Policy Routes czy trasy VPN. Kolejność ma znaczenie, gdy kilka kategorii pasuje do tego samego przepływu. Ważny wyjątek: vpn przed static ma pierwszeństwo przed trasami statycznymi lub lokalnymi tylko dla celów w strefie WAN.

Dlaczego Route Precedence jest potrzebne

Sophos Firewall nie przechowuje Static, SD-WAN i VPN na jednej wspólnej liście routingu. Są to oddzielne kategorie, a kilka kategorii może jednocześnie zawierać pasującą ścieżkę do tego samego celu. Route Precedence określa, w której kategorii zapora najpierw szuka pasującej trasy.

Typowy przykład: klient w sieci LAN ma dotrzeć do zdalnej sieci 10.20.0.0/16 przez tunel policy-based IPsec. Jednocześnie do tego ruchu pasuje również trasa SD-WAN z celem Any.

• Przy static sdwan_policyroute vpn zapora najpierw sprawdza Static. Jeśli nie znajdzie tam pasującej ścieżki, następnie zadziała szeroka trasa SD-WAN i ruch może trafić do bramy WAN zamiast do tunelu VPN.
• Przy static vpn sdwan_policyroute zapora sprawdza trasy VPN bezpośrednio po Static. Trasa do sieci zdalnej otrzymuje dzięki temu priorytet przed ogólną trasą SD-WAN.

Sieć przykładową 10.20.0.0/16 należy zastąpić rzeczywistą siecią zdalną. Nie chodzi o to, która kolejność brzmi ogólnie „lepiej”, lecz który typ routingu powinien wygrać dla konkretnego przepływu pakietów.

Route Precedence porządkuje wyłącznie kategorie. Nie zmienia kolejności poszczególnych Static Routes ani SD-WAN Routes wewnątrz ich kategorii. Przed zmianą należy odpowiedzieć na trzy pytania:

1. Jaki konkretny ruch wybiera obecnie niewłaściwą ścieżkę?
2. Które z trzech kategorii zawierają dla niego pasującą trasę?
3. Która kategoria powinna mieć priorytet dla tego ruchu?

Jeśli pasuje tylko jedna kategoria, zmiana Route Precedence nie rozwiąże problemu. Należy wtedy skorygować odpowiednią trasę, Policy SD-WAN, konfigurację VPN, regułę NAT lub ścieżkę powrotną. Route Precedence nie zezwala też na ruch między strefami; nadal potrzebna jest odpowiednia reguła zapory.

Bezpośrednie wyświetlanie i zmiana Route Precedence

Polecenia wykonuje się w Device Console, a nie w Advanced Shell. Po zalogowaniu przez SSH należy wybrać opcję menu 4. Jeśli dostęp nie został jeszcze skonfigurowany, pomocny jest artykuł Łączenie z Sophos Firewall przez SSH.

Najpierw należy zapisać pełną bieżącą kolejność i na jej podstawie przygotować rollback. Dzisiejsza wartość domyślna Sophos nie jest zamiennikiem, ponieważ zapory migrowane lub celowo zmienione mogą mieć inną kolejność początkową.

⚠️ Ważne: Zmiana jest globalna. Przed poleceniem set trzeba znać kolejność początkową i mieć niezależną ścieżkę zarządzania. Niewłaściwa kolejność może wpłynąć na ruch produkcyjny oraz dostęp WebAdmin i SSH.

Poniższy przykład ustawia Static na pierwszym miejscu, VPN na drugim, a SD-WAN na ostatnim:

system route_precedence show
system route_precedence set static vpn sdwan_policyroute
system route_precedence show

Pierwsze polecenie pokazuje kolejność, drugie ją zmienia, a trzecie kontroluje wynik. Pozycja wartości określa priorytet. Wynik końcowy musi pokazywać static, vpn, sdwan_policyroute dokładnie w tej kolejności; następnie trzeba przetestować rzeczywisty przepływ.

Aktualna kolejność domyślna Sophos to:

system route_precedence set static sdwan_policyroute vpn

To polecenie jest rollbackiem tylko wtedy, gdy system route_precedence show przed zmianą pokazywało dokładnie tę kolejność.

WebAdmin pokazuje bieżącą kolejność również w Routing > SD-WAN routes, ale można ją zmienić tylko w Device Console.

Znaczenie Static, SD-WAN i VPN

Te trzy wartości oznaczają kategorie routingu, a nie pojedyncze trasy:

• static obejmuje bezpośrednio połączone sieci, Unicast Routes, Dynamic Routes i SSL VPN.
• sdwan_policyroute obejmuje Policy Routes skonfigurowane w Routing > SD-WAN routes.
• vpn obejmuje automatycznie generowane trasy policy-based IPsec. W SFOS 22.0 należą do tej kategorii również trasy zdefiniowane za pomocą ipsec_route.

Trasy policy-based IPsec i wpisy ipsec_route nie są widoczne w tabeli routingu WebAdmin. Analizując konflikt, trzeba uwzględnić także konfigurację VPN i trasy utworzone w Device Console. Pełną klasyfikację wyjaśnia przewodnik dotyczący tras IPsec w Sophos Firewall.

SSL VPN należy do static, a nie do vpn. Route-based IPsec przez XFRM jest sterowany skonfigurowaną trasą statyczną, dynamiczną lub SD-WAN. Decydują interfejs XFRM, trasa i jej Administrative Distance, a nie tylko pozycja vpn. Gdy żadna trasa nie pasuje, WAN Link Manager zapewnia trasę domyślną.

Static, SD-WAN, VPN

system route_precedence set static sdwan_policyroute vpn

Jest to kolejność domyślna i właściwy punkt wyjścia w wielu środowiskach. Zapobiega nadpisywaniu bezpośrednio połączonych sieci, LAN, DMZ, VLAN i SSL VPN przez zbyt szerokie trasy SD-WAN.

Static, VPN, SD-WAN

system route_precedence set static vpn sdwan_policyroute

Ta kolejność pozostawia Static na pierwszym miejscu, następnie sprawdza trasy VPN, a trasy SD-WAN wykorzystuje na końcu. Jest przydatna, gdy trasy statyczne i bezpośrednio połączone mają zachować priorytet, a konkurująca trasa policy-based VPN musi zostać sprawdzona przed SD-WAN. Sophos stosuje ją też dla failoveru route-based VPN z dwoma łączami internetowymi oraz MTA z wieloma połączeniami WAN.

SD-WAN, Static, VPN

system route_precedence set sdwan_policyroute static vpn

Ten wariant należy stosować tylko wtedy, gdy Policy Routing ma świadomie otrzymać priorytet przed trasami statycznymi. Szczególnej ostrożności wymaga trasa SD-WAN z celem Any: może objąć także sieci wewnętrzne lub dostęp administracyjny i skierować ten ruch do bramy WAN. Dlatego trasa SD-WAN powinna korzystać z możliwie konkretnych celów i zostać przetestowana.

VPN, Static, SD-WAN

system route_precedence set vpn static sdwan_policyroute

VPN na pierwszym miejscu jest celowym wyjątkiem, a nie ogólnym rozwiązaniem problemów IPsec. Dla L2TP Remote Access vpn musi być pierwsze; static i sdwan_policyroute mogą wystąpić potem w dowolnej kolejności. vpn przed static nadaje jednak VPN priorytet nad Static tylko wtedy, gdy konkurująca trasa statyczna prowadzi do strefy WAN. Dla celów w innych strefach zapora nadal używa trasy statycznej lub lokalnej.

Dokładnie takiej kolejności wymaga również projekt policy-based, który kieruje ruch internetowy oddziału przez centralę. Łączy on selektory Any, regułę VPN-to-WAN, MASQ oraz osobną decyzję dotyczącą ruchu generowanego przez system.

Bezpieczna zmiana Route Precedence

Przed zmianą produkcyjną należy przygotować zarówno polecenie, jak i odpowiedni przepływ pakietów:

1. Zapisać pełną bieżącą kolejność za pomocą system route_precedence show i na jej podstawie przygotować polecenie rollback.
2. Określić źródło, cel, usługę, strefę i uczestniczące interfejsy. Sprawdzić Static Routes, SD-WAN Routes, trasy VPN i interfejsy XFRM pod kątem konkurujących celów.
3. Przetestować niezależną ścieżkę do zapory, na przykład lokalną konsolę, oddzielny interfejs zarządzania lub nieobjętą zmianą ścieżkę administracyjną.
4. Zmienić tylko Route Precedence. Nie modyfikować jednocześnie reguł NAT, zapory, VPN i SD-WAN, aby można było rozróżnić przyczynę i skutek.

Jeśli uczestniczy SD-WAN, należy również sprawdzić, czy jest włączony dla ruchu generowanego przez system lub Reply Packets:

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

Opcje te nie zmieniają kolejności. Rozszerzają zakres ruchu, do którego stosują się SD-WAN Routes: Reply-Packet-Routing nie działa, jeśli droga wychodząca użyła tylko trasy domyślnej WAN Link Manager. Dla ruchu systemowego należy używać tylko sieci docelowych i usług, ponieważ Incoming Interface i Source Network są nieznane. Co najmniej jedna brama WAN Link Manager musi być Active; same bramy ustawione wyłącznie jako Backup nie wystarczą. Systemowy ruch RED przez UDP 3410 jako Layer 2 pozostaje poza routingiem SD-WAN. Artykuł Sprawdzanie routingu SD-WAN dla Reply Packets i System Traffic w Sophos Firewall wyjaśnia szczegóły.

Po poleceniu set należy najpierw potwierdzić kolejność za pomocą system route_precedence show. Następnie testuje się konkretny przypadek:

• Sprawdzić aplikację, połączenie TCP lub ping do celu.
• Sprawdzić Route Lookup, Log Viewer i w razie potrzeby Packet Capture.
• Sprawdzić NAT i ścieżkę powrotną drugiej strony.
• Przetestować WebAdmin i SSH z odpowiednich sieci zarządzania.

Zielony status VPN lub istniejąca trasa nie dowodzą, że przepływ pakietów działa. Praktyczne kontrole opisują artykuły Testowanie reguł Sophos Firewall za pomocą Log Viewer i Packet Capture oraz Korzystanie z Packet Capture w WebAdmin Sophos Firewall.

Rollback

Podczas rollbacku ustawia się dokładnie kolejność początkową zapisaną przed zmianą:

system route_precedence set <erster Wert> <zweiter Wert> <dritter Wert>

Należy zastąpić wszystkie trzy symbole zastępcze. Poprzedniego stanu nie można wywnioskować z samej pierwszej wartości, ponieważ możliwych jest sześć kolejności. Następnie powtarza się system route_precedence show oraz te same testy funkcjonalne i administracyjne.

Jeśli zmiana nie rozwiązuje problemu

• Problem dotyczy tylko jednej sieci docelowej: Bardziej szczegółowa trasa statyczna, węższa trasa SD-WAN lub poprawiona konfiguracja VPN są zwykle bardziej precyzyjne niż zmiana globalna.
• Tunel VPN jest zielony, ale ruch wybiera niewłaściwą ścieżkę: W przypadku route-based IPsec należy najpierw sprawdzić interfejs XFRM i trasę. W przypadku policy-based IPsec również Traffic Selectors oraz zależną od wersji obsługę ipsec_route. Pomocny jest przewodnik Rozwiązywanie problemów z IPsec VPN.
• Ścieżka wychodząca jest poprawna, ale powrotna nie: Routing określa drogę, a NAT zmienia adres źródłowy lub docelowy. Należy sprawdzić trasę powrotną i konfigurację NAT.
• Zmigrowana zapora pokazuje nieoczekiwaną kolejność: Decydujący jest wynik system route_precedence show, a nie bieżąca wartość domyślna. Zmigrowane trasy SD-WAN mogą także pozostać powiązane z pierwotną regułą zapory i zniknąć po jej usunięciu.
• WebAdmin lub SSH nie są dostępne po zmianie SD-WAN: Często występują jednocześnie trzy warunki: SD-WAN znajduje się przed Static, pasująca trasa SD-WAN używa Any, a System Traffic lub Reply Packets są włączone dla SD-WAN. Należy przywrócić kolejność początkową przez przygotowaną ścieżkę zarządzania i zawęzić trasę SD-WAN.
• Żądanie SSL VPN dociera do celu wewnętrznego, ale odpowiedź nie wraca do klienta: SSL VPN należy do static. Jeżeli SD-WAN znajduje się wcześniej, szeroka trasa SD-WAN może skierować odpowiedź do puli adresów poza tunel. Należy precyzyjnie zawęzić trasę; pełną procedurę opisuje artykuł Konfiguracja i testowanie dostępu zdalnego SSL VPN.

FAQ