Bezpieczna zmiana Route Precedence w Sophos Firewall

Route Precedence określa, czy Sophos Firewall najpierw ocenia Static Routes, SD-WAN Policy Routes czy trasy VPN. Ustawienie działa globalnie i może natychmiast wpłynąć na ruch produkcyjny oraz dostęp administracyjny.

Krótka odpowiedź

Domyślna kolejność to:

1. static
2. sdwan_policyroute
3. vpn

Sprawdza się ona w wielu środowiskach, ponieważ bezpośrednio połączone sieci i trasy statyczne nie są wtedy nadpisywane przez szeroką trasę SD-WAN. Kolejność należy zmieniać tylko wtedy, gdy w konkretnym przepływie pakietów kilka typów routingu konkuruje o ten sam cel.

Przed każdą zmianą należy udokumentować bieżącą kolejność, zapewnić niezależny dostęp administracyjny, sprawdzić odpowiednie trasy i przygotować dokładny rollback. Zwykłą trasę SD-WAN opisuje artykuł Konfiguracja i testowanie trasy SD-WAN w Sophos Firewall.

Która kolejność jest właściwa?

Standard i różnice między wersjami

Domyślna kolejność jest taka sama w SFOS 21.5 i 22.0. Zmieniło się jednak przypisanie ipsec_route:

• SFOS 21.5: static obejmuje bezpośrednio połączone sieci, ipsec_route, Unicast Routes, Dynamic Routes i SSL VPN. Automatycznie tworzone trasy policy-based IPsec należą do vpn.
• SFOS 22.0: static obejmuje bezpośrednio połączone sieci, Unicast Routes, Dynamic Routes i SSL VPN. vpn obejmuje automatycznie tworzone trasy policy-based IPsec oraz ipsec_route.

Ma to znaczenie podczas aktualizacji: zalecenia dotyczącego ipsec_route w SFOS 21.5 nie można przenosić bez zmian do SFOS 22.0. W SFOS 22.0 zapora przetwarza trasy policy-based IPsec wewnętrznie. Automatycznie tworzone trasy policy-based VPN oraz trasy zdefiniowane za pomocą ipsec_route nie są widoczne w tabeli routingu. ipsec_route nie jest wymagane dla ruchu generowanego przez system. Ręczna trasa IPsec ma sens tylko w odpowiednim, zależnym od wersji przypadku szczególnym.

W przypadku zmigrowanych zapór liczy się nie udokumentowana wartość domyślna, lecz rzeczywisty wynik polecenia. Migracja może na przykład zachować sdwan_policyroute vpn static. Zmigrowane SD-WAN Routes mogą być ponadto nadal powiązane z identyfikatorem pierwotnej reguły zapory i zniknąć po jej usunięciu.

Najpierw Static

static sdwan_policyroute vpn jest zwykle właściwym punktem wyjścia dla LAN, DMZ, VLAN, SSL VPN i zwykłych ścieżek internetowych SD-WAN. Bezpośrednio połączone sieci są przy tym traktowane jak trasy statyczne.

Chroni to cele wewnętrzne przed zbyt szerokimi SD-WAN Routes. Jeśli sdwan_policyroute znajduje się przed static, a trasa SD-WAN używa na przykład celu Any, ruch wewnętrzny lub administracyjny może zostać nieoczekiwanie skierowany do bramy WAN.

Najpierw SD-WAN

sdwan_policyroute static vpn ma sens, jeśli Policy Routing ma świadomie otrzymać priorytet przed trasami statycznymi. Należy to zaplanować na podstawie konkretnych źródeł, celów i usług. SD-WAN Routes obejmują Reply Packets i ruch generowany przez system tylko wtedy, gdy odpowiednie opcje CLI są włączone.

Artykuł Sprawdzanie routingu SD-WAN dla Reply Packets i System Traffic w Sophos Firewall szczegółowo opisuje obie opcje.

Najpierw VPN

vpn static sdwan_policyroute jest celowym wyjątkiem, na przykład dla udokumentowanych scenariuszy L2TP. Priorytet vpn przed static obowiązuje przy tym tylko dla ruchu, którego konkurująca trasa prowadzi do strefy WAN. Nie jest to uniwersalne rozwiązanie dla każdego tunelu IPsec.

Połączenia SSL VPN należą do kategorii static, a nie vpn. Route-based IPsec przez interfejsy XFRM jest sterowany za pomocą skonfigurowanej dla niego trasy statycznej, dynamicznej lub SD-WAN. Decydujące są zatem interfejs XFRM, trasa, kryteria SD-WAN, NAT, reguła zapory i ścieżka powrotna.

Globalna zmiana jest niewłaściwa, jeśli nieprawidłowo routowana jest tylko jedna sieć docelowa. W takim przypadku bardziej precyzyjnym rozwiązaniem jest zwykle dokładniejsza trasa statyczna lub SD-WAN, konfiguracja VPN albo ipsec_route użyta zgodnie z wersją.

Bezpieczne przygotowanie zmiany

Polecenia wykonuje się w Device Console, a nie w Advanced Shell. Jeśli dostęp nie został jeszcze skonfigurowany, pomocny jest artykuł Łączenie z Sophos Firewall przez SSH. Dostęp SSH powinien być dozwolony tylko z zaufanych sieci.

Przygotowanie:

1. Zapewnić niezależną ścieżkę powrotną do zapory i aktywnie przetestować ją przed zmianą, na przykład lokalną konsolę, dedykowany interfejs zarządzania lub potwierdzoną, nieobjętą zmianą ścieżkę administracyjną.
2. Zanotować źródło, cel, usługę, strefę i uczestniczące interfejsy.
3. Sprawdzić trasy statyczne, SD-WAN Policy Routes, trasy VPN i interfejsy XFRM.
4. Zidentyfikować szerokie SD-WAN Routes z Any oraz zmigrowane reguły.
5. Sprawdzić NAT, regułę zapory i ścieżkę powrotną drugiej strony.
6. Ustalić okno serwisowe, test odbiorczy i rollback.

⚠️ Ważne: Route Precedence działa globalnie. Nie należy jednocześnie zmieniać reguł routingu, NAT, zapory i SD-WAN, ponieważ skutków nie da się wtedy wiarygodnie przypisać.

Wyświetlić bieżącą kolejność i dokładnie ją udokumentować:

system route_precedence show

Należy zapisać pełny wynik wraz z datą, przyczyną, odpowiednimi sieciami i oczekiwanym zachowaniem. Przed zmianą należy przygotować dokładne polecenie rollback na podstawie wszystkich trzech wartości.

Bieżąca kolejność jest dodatkowo widoczna w WebAdmin tutaj:

Routing > SD-WAN routes

Zmienia się ją przez Device Console. Jeśli uczestniczy SD-WAN, należy wcześniej zarejestrować również status ruchu generowanego przez system i Reply Packets:

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

Tych wartości nie można nieświadomie mylić z działaniem Route Precedence. Szczególnie krytyczna kombinacja występuje, gdy sdwan_policyroute znajduje się przed static, pasująca trasa SD-WAN używa celu Any, a routing SD-WAN jest aktywny zarówno dla ruchu generowanego przez system, jak i Reply Packets. Dostęp do WebAdmin i SSH z odpowiedniej podsieci wewnętrznej może wtedy zostać utracony, podczas gdy zapora może nadal być dostępna z innych podsieci.

Zmiana Route Precedence

Składnia zawsze zawiera wszystkie trzy wartości:

system route_precedence set [sdwan_policyroute] [static] [vpn]

Ustawienie kolejności domyślnej:

system route_precedence set static sdwan_policyroute vpn

Jeśli ta kolejność jest już aktywna, błąd prawdopodobnie dotyczy Route Lookup, kryteriów SD-WAN, konfiguracji VPN, NAT, reguły zapory lub ścieżki powrotnej.

⚠️ Przed SD-WAN-First: Sprawdzić, czy szerokie SD-WAN Routes obejmują sieci wewnętrzne lub dostęp administracyjny. Polecenie wykonać tylko z przygotowaną ścieżką powrotną.

Ocenianie najpierw SD-WAN Policy Routes:

system route_precedence set sdwan_policyroute static vpn

⚠️ Przed VPN-First: Używać tej kolejności tylko dla potwierdzonego przypadku szczególnego VPN. Nie rozwiązuje ona problemu brakującej trasy, nieprawidłowych Traffic Selectors, NAT ani ścieżki powrotnej.

Ocenianie najpierw tras VPN:

system route_precedence set vpn static sdwan_policyroute

Testowanie i wycofywanie zmiany

Po zmianie należy najpierw potwierdzić, że oczekiwana kolejność jest aktywna:

system route_precedence show

Następnie przetestować odpowiedni przepływ pakietów:

• Sprawdzić aplikację, połączenie TCP lub ping do celu.
• Filtrować Log Viewer według źródła, celu i reguły zapory.
• Przeprowadzić Packet Capture na interfejsie wejściowym i wyjściowym.
• Sprawdzić Route Lookup i odpowiednią trasę SD-WAN.
• Sprawdzić NAT i przetłumaczony źródłowy adres IP.
• Potwierdzić ścieżkę powrotną drugiej strony.
• Przetestować WebAdmin i SSH z odpowiednich sieci administracyjnych.

Zielony status VPN lub istniejąca trasa nie są dowodem na działający przepływ pakietów. Praktyczne kroki przedstawiają artykuły Testowanie reguły Sophos Firewall za pomocą Log Viewer i Packet Capture oraz Korzystanie z Packet Capture w WebAdmin Sophos Firewall.

Jeśli zmiana dotyczy kilku lokalizacji lub ścieżek routingu, należy przetestować co najmniej jednego klienta w każdej odpowiedniej sieci, cel serwerowy oraz wszystkie objęte zmianą ścieżki Remote Access lub VPN.

Podczas rollbacku ustawia się wyłącznie wcześniej udokumentowaną, pełną kolejność początkową. Nie można jej wywnioskować z samej pierwszej wartości, ponieważ istnieje sześć możliwych kombinacji. Należy użyć przygotowanego polecenia według następującego wzorca:

system route_precedence set <pierwsza wartość> <druga wartość> <trzecia wartość>

Symbole zastępcze należy zastąpić wszystkimi trzema wartościami z wcześniej zapisanego wyniku. Następnie ponownie sprawdzić:

system route_precedence show

Potem należy powtórzyć te same testy funkcjonalne, routingu i zarządzania. Jeśli po rollbacku pierwotny błąd powróci, prawdopodobnie uczestniczyło w nim Route Precedence. Jeśli nic się nie zmieni, przyczyna leży gdzie indziej.

Częste błędy

Trasa SD-WAN jest zbyt szeroka

Trasa SD-WAN z dużymi zakresami sieci lub celem Any może obejmować więcej ruchu, niż planowano. Jeśli SD-WAN znajduje się przed Static, cele wewnętrzne i dostęp administracyjny mogą zostać nieoczekiwanie skierowane do bramy WAN. Reply Packets i ruch generowany przez system są objęte, jeśli odpowiednie opcje SD-WAN są włączone.

Status VPN jest mylony z routingiem

Aktywny tunel potwierdza tylko negocjację. Nie dowodzi, że routing, Traffic Selectors, reguły zapory, NAT i ścieżka powrotna są prawidłowe. W przypadku route-based IPsec należy najpierw sprawdzić interfejs XFRM i trasę; w przypadku policy-based IPsec dodatkowo zależną od wersji obsługę ipsec_route. Artykuł Rozwiązywanie problemów z IPsec VPN w Sophos Firewall prowadzi systematycznie przez analizę.

Pominięto NAT

Routing określa drogę pakietu, a NAT zmienia adres źródłowy lub docelowy. Jeśli trasa jest poprawna, ale ścieżka powrotna nie działa, częstą przyczyną jest NAT lub trasa powrotna. Pomocny jest artykuł Zrozumienie NAT w Sophos Firewall.

Jednoczesne wprowadzanie wielu zmian

Jeśli Route Precedence, SD-WAN, NAT, reguły zapory i parametry VPN są zmieniane jednocześnie, nie można już precyzyjnie rozdzielić przyczyny i skutku. Lepiej postępować kolejno: jedna zmiana, pełny test, następna zmiana.

Lista kontrolna

• Udokumentowano bieżące Route Precedence.
• Uwzględniono wersję SFOS i przypisanie ipsec_route.
• Zanotowano odpowiednie źródła, cele, sieci i usługi.
• Sprawdzono Static, SD-WAN, VPN i XFRM.
• Uwzględniono bezpośrednio połączone sieci i ścieżki zarządzania.
• Zidentyfikowano szerokie SD-WAN Routes z Any.
• Zarejestrowano status System Traffic i Reply Packets.
• Sprawdzono NAT, reguły zapory i ścieżkę powrotną.
• Przygotowano niezależny dostęp administracyjny i rollback.
• Zmianę przeprowadzono oddzielnie.
• Przetestowano aplikację, Log Viewer, Packet Capture i dostęp administracyjny.

FAQ