Zmień bezpiecznie Sophos Firewall Route Precedence

Route Precedence w Sophos Firewall określa kolejność, w jakiej różne typy tras są brane pod uwagę przy wyborze trasy. Brzmi to jak niewielka korekta, ale może natychmiast wpłynąć na ruch produktywny. Jest to szczególnie istotne, gdy Trasy statyczne, Trasy zasad SD-WAN i Trasy VPN pokrywają się.

Artykuł wyjaśnia, kiedy zmiana ma sens, kiedy najpierw trzeba sprawdzić inne przyczyny oraz jak poprawnie udokumentować zmianę za pomocą Device Console, przetestować ją i w razie potrzeby wycofać. Jeśli najpierw trzeba zaplanować lub przetestować zwykłą trasę SD-WAN, pasuje Konfiguracja i test trasy SD-WAN na Sophos Firewall.

Kiedy Route Precedence jest ważny

Route Precedence nabiera znaczenia, gdy teoretycznie wiele mechanizmów routingu pasuje do tego samego miejsca docelowego. Zapora sieciowa musi następnie zdecydować, który typ routingu będzie oceniany jako pierwszy.

Typowe sytuacje:

• Do wewnętrznej sieci docelowej można dotrzeć trasą statyczną i dodatkowo trasą zasad SD-WAN.
• Oparta na trasach IPsec VPN wykorzystuje interfejsy XFRM i jednocześnie podlega wpływom reguł SD-WAN.
• Specjalny przypadek IPsec oparty na zasadach współpracuje z ręcznymi trasami IPsec.
• Starsza migracja zachowała trasy SD-WAN albo wcześniejszą Route Precedence.
• Ruch generowany przez system lub pakiety odpowiedzi przyjmują nieoczekiwaną trasę po zmianie SD-WAN.
• Po aktualizacji oprogramowania sprzętowego lub migracji istniejące trasy zachowują się inaczej niż oczekiwano.

W przypadku specjalnych przypadków IPsec Route Precedence nie jest automatycznie najlepszym rozwiązaniem. Często trzeba najpierw zrozumieć, czy w grę wchodzi klasyczny problem z routingiem, Trasa IPsec, reguła SD-WAN, NAT lub reguła zapory sieciowej.

Wymagania

• Sophos Firewall w trybie Gateway.
• Dostęp do Device Console, na przykład poprzez SSH.
• Aktualna dokumentacja tras statycznych, których dotyczy problem, tras zasad SD-WAN i połączeń VPN.
• Okno konserwacji lub przynajmniej ścieżka awaryjna, gdy może to mieć wpływ na ruch produktywny.
• Dostęp do Log Viewer i w razie potrzeby Packet Capture.

Jeśli dostęp do konsoli nie został jeszcze skonfigurowany, Podłącz Sophos Firewall przez SSH wyjaśnia, jak uzyskać dostęp do Device Console. SSH powinien być dozwolony tylko z zaufanych sieci.

⚠️ Ważne: zmiana w Route Precedence ma skutek globalny. Nie dotyczy to tylko pojedynczego tunelu lub trasy, ale kolejności typów routingu w zaporze. Dlatego nigdy nie należy dokonywać jednocześnie wielu zmian w routingu, NAT i SD-WAN.

Domyślna kolejność

Aktualna dokumentacja opisuje następujące standardowe zamówienie:

1. Statyczny
2. SD-WAN
3. VPN

Wartości w Device Console to:

• static
• sdwan_policyroute
• vpn

Ważne: kategoria static jest szersza, niż sugeruje jej nazwa. Sophos zalicza do niej bezpośrednio połączone sieci, trasy z ipsec_route, trasy unicast, trasy dynamiczne oraz połączenia SSL VPN. Jest to szczególnie istotne, gdy ruch dostępu zdalnego, trasy statyczne, routing dynamiczny i reguły SD-WAN są analizowane razem.

Równie ważne: bezpośrednio połączone sieci są w tym kontekście traktowane jak trasy statyczne. Jeśli sdwan_policyroute znajduje się przed static i działa trasa SD-WAN z bardzo szerokim miejscem docelowym, takim jak Any, ruch wewnętrzny może nagle skierować się w stronę bramy WAN. Właśnie dlatego static przed sdwan_policyroute jest w wielu środowiskach bezpiecznym punktem wyjścia.

Na zmigrowanych firewallach trzeba szczególnie świadomie sprawdzić aktualny wynik. Sophos może zachować Route Precedence z wcześniejszej wersji, a zmigrowane trasy SD-WAN mogą nadal być powiązane ze starymi regułami firewalla. W takim przypadku decydujące nie jest ustawienie domyślne z dzisiejszej dokumentacji, lecz to, co system route_precedence show pokazuje na konkretnej firewalli.

Która kolejność jest poprawna?

Nie ma jednej właściwej kolejności dla każdego projektu. Route Precedence musi pasować do modelu routingu.

• Normalne LAN, DMZ, VLAN, dostęp zdalny i ścieżki internetowe SD-WAN: static sdwan_policyroute vpn Bezpośrednio połączone sieci i trasy statyczne nie powinny być zastępowane przez szerokie trasy SD-WAN.
• Policy-based IPsec nakłada się na trasy statyczne lub SD-WAN: vpn static sdwan_policyroute może pomóc w odpowiednich przypadkach routingu VPN. Jeśli trasa statyczna lub lokalna wysyła ruch do strefy innej niż WAN, ukierunkowana ipsec_route jest często czystsza niż globalna zmiana precedence. Następnie należy sprawdzić NAT, reguły zapory i ścieżkę zwrotną.
• L2TP Remote Access lub inne udokumentowane przypadki szczególne VPN: Sophos wymaga w niektórych scenariuszach vpn na pierwszym miejscu. Nie jest to ogólny standard, lecz celowe odstępstwo dla sprawdzonego przypadku użycia.
• IPsec oparty na trasach albo failover WAN jest świadomie sterowany przez SD-WAN: Kolejność zależy od projektu, często z SD-WAN przed innym typem routingu. Przetestuj razem interfejs XFRM, kryteria SD-WAN, status bramy, NAT i Route Precedence.
• MTA, specjalny routing lub pojedyncze scenariusze Sophos how-to: Kolejność musi pasować do testowanego scenariusza. Nie kopiuj ślepo przykładu; zawsze sprawdzaj sieci lokalne i trasy powrotne.

Jeśli przykład Sophos pokazuje inną kolejność, nie jest to automatycznie nowy standard. Wiele przykładów rozwiązuje konkretny, specjalny problem. Dla wydajnej zapory ogniowej liczy się to, która sieć źródłowa i docelowa faktycznie konkurują.

Limit przed zmianą

Route Precedence nie powinien być pierwszą reakcją, gdy nie można osiągnąć sieci docelowej. Najpierw należy zawęzić przepływ pakietów, którego dotyczy problem.

Sprawdź:

1. Które źródło i miejsce docelowe są dotknięte?
2. Która strefa i który interfejs są zaangażowane?
3. Czy istnieje odpowiednia trasa statyczna?
4. Czy istnieje trasa polisy SD-WAN, która jest zgodna z szerszym zakresem niż planowano?
5. Czy istnieją zmigrowane trasy SD-WAN ze starszej wersji SFOS?
6. Czy w grę wchodzi trasa VPN lub interfejs XFRM?
7. Czy obowiązuje NAT lub MASQ?
8. Czy w Log Viewer spełniona jest oczekiwana reguła zapory sieciowej?
9. Czy Packet Capture pokazuje oczekiwaną ścieżkę wejścia i wyjścia?

Reguła testowa Sophos Firewall z Log Viewer i Packet Capture i Sophos Firewall użyj Packet Capture w WebAdmin pomoc do egzaminu praktycznego. W przypadku pytań dotyczących NAT pasuje Zrozum NAT na Sophos Firewall.

Wyświetlanie aktualnej Route Precedence

Polecenia są wykonywane w Device Console, a nie w Advanced Shell.

Show current order:

system route_precedence show

Wyniki należy udokumentować przed wprowadzeniem jakichkolwiek zmian. Najlepiej jest również zanotować datę, przyczynę, sieci, których to dotyczy i oczekiwane zachowanie. Jeśli konieczne jest wycofanie zmian, należy ponownie ustawić dokładnie tę kolejność.

W WebAdmin możesz również zobaczyć aktualny Route Precedence pod:

Routing > SD-WAN routes

Tam zostanie wyświetlony w obszarze porad dotyczących trasy. Kolejność zmienia się za pomocą Device Console.

Zmiana Route Precedence

Składnia jest następująca:

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

Kolejność trzech wartości określa priorytet. Typowy przykład umieszcza trasy statyczne przed trasami zasad SD-WAN i trasami VPN:

system route_precedence set static sdwan_policyroute vpn

Jeśli to zamówienie jest już aktywne, problem prawdopodobnie nie dotyczy Route Precedence. Następnie powinieneś szczególnie sprawdzić wyszukiwanie tras, trasy zasad SD-WAN, konfigurację IPsec, NAT, reguły zapory ogniowej i trasy powrotne.

Inny przykład umieszcza trasy zasad SD-WAN przed trasami statycznymi:

system route_precedence set sdwan_policyroute static vpn

Może to być zamierzone w niektórych projektach SD-WAN, ale jest ryzykowne, gdy szerokie reguły SD-WAN używają Any lub dużych zakresów sieci. W takich przypadkach dostęp administracyjny, sieci wewnętrzne lub pakiety zwrotne mogą zostać nieoczekiwanie przekierowane przez SD-WAN. Artykuł Sophos Firewall SD-WAN routing dla reply packets i system traffic wyjaśnia te interakcje bardziej szczegółowo.

W przypadku specjalnych przypadków IPsec opartych na zasadach, konieczne może być także vpn:

system route_precedence set vpn static sdwan_policyroute

Należy to zrobić tylko wtedy, gdy trasy VPN rzeczywiście muszą mieć pierwszeństwo w konkretnym przepływie pakietów. Sophos wskazuje, że route_precedence nie sprawia, że trasy VPN wygrywają z trasami statycznymi dla każdej ścieżki docelowej. Jeśli trasa statyczna lub lokalna wskazuje strefę inną niż WAN, przy policy-based VPN z traffic selectors należy raczej sprawdzić ipsec_route. Przy route-based IPsec z interfejsami XFRM zwykle lepsza jest czysta trasa SD-WAN lub statyczna niż globalne ustawienie vpn na pierwszym miejscu.

Zmiana testu

Po dostosowaniu sprawdź najpierw nową kolejność:

system route_precedence show

Następnie przetestuj konkretnie ruch, którego to dotyczy. Zielony status VPN lub istniejąca trasa nie są wystarczającym dowodem.

Sprawdź:

• Połączenie z siecią docelową za pomocą polecenia ping, testu TCP lub testu aplikacji.
• Filter Log Viewer on source, destination and firewall rule.
• Uruchom Packet Capture na interfejsie wejścia i wyjścia.
• Sprawdź wyszukiwanie trasy lub regułę SD-WAN, której dotyczy problem.
• Sprawdź regułę NAT i przetłumaczony źródłowy adres IP.
• Sprawdź ścieżkę powrotną stacji zdalnej.
• Dostęp do zarządzania testami do WebAdmin i SSH z odpowiednich sieci administracyjnych.

Wenn mehrere Standorte betroffen sind, sollte man nicht nur einen Testclient prüfen. Lepiej jest mieć co najmniej jednego klienta na odpowiednią sieć, cel serwera i zdalny dostęp lub test VPN, jeśli zmiana dotyczy tych ścieżek.

Wycofanie

Wycofanie nie polega na zalecanej wartości domyślnej, ale na wcześniej udokumentowanej kolejności.

Przykład:

system route_precedence set static sdwan_policyroute vpn

lub:

system route_precedence set sdwan_policyroute static vpn

Sprawdź ponownie po wycofaniu:

system route_precedence show

Następnie powtórz te same badania, co po zmianie. Jeśli spowoduje to powrót pierwotnego błędu, jest to wyraźna wskazówka, że ​​rzeczywiście dotyczy to Route Precedence. Jeśli nic się nie zmieni, przyczyna prawdopodobnie leży gdzie indziej.

Typowe błędy

Reguła SD-WAN jest zbyt ogólna

Jeśli trasa zasad SD-WAN odpowiada bardzo szerokim źródłom lub celom, może przechwycić większy ruch niż planowano. Jest to szczególnie niebezpieczne, jeśli SD-WAN ma priorytet nad static. Dostęp do zarządzania lub wewnętrzne sieci docelowe mogą wówczas nieoczekiwanie działać poprzez trasę WAN.

Typowy wzór:

• Route Precedence is on sdwan_policyroute static vpn.
• Trasa SD-WAN wykorzystuje Any jako miejsce docelowe.
• Ruch generowany przez system lub pakiety odpowiedzi są również oceniane przez SD-WAN.

Dostęp do WebAdmin lub SSH z wewnętrznej podsieci może zostać wówczas utracony, chociaż zapora sieciowa będzie nadal dostępna z innych sieci.

Status VPN jest mylony z routingiem

Aktywny tunel IPsec potwierdza jedynie, że tunel został wynegocjowany. Nie dowodzi, że zapora kieruje ruch do tunelu, że NAT jest prawidłowy ani że druga strona zna drogę powrotną.

W przypadku policy-based IPsec szczególnie ważne jest, czy trasy statyczne, lokalne lub SD-WAN pasują również do zdalnych podsieci. vpn static sdwan_policyroute może pomóc w niektórych przypadkach, ale nie zastępuje sprawdzenia strefy, traffic selectors i możliwej ipsec_route. W przypadku route-based IPsec należy najpierw sprawdzić interfejs XFRM, trasę, trasę SD-WAN i reguły zapory.

NAT jest pomijany

Routing decyduje o tym, gdzie pakiet zostanie wysłany. NAT decyduje o zmianie adresu źródłowego lub docelowego. Jeśli trasa jest prawidłowa, ale trasa powrotna nie działa, często w grę wchodzi NAT lub trasa powrotna.

Wiele zmian na raz

Jeśli reguły Route Precedence, SD-WAN, NAT, reguły zapory sieciowej i parametry VPN zostaną zmienione w tym samym czasie, trudno będzie jednoznacznie przypisać efekt. Lepiej najpierw dokonać zmiany, potem przetestować, a potem wprowadzić kolejną zmianę.

Lista kontrolna

• Aktualny Route Precedence udokumentowany system route_precedence show.
• Odnotowano dotknięte źródła, miejsca docelowe, sieci i usługi.
• Sprawdzono trasy statyczne, trasy zasad SD-WAN i trasy VPN.
• Uwzględniono bezpośrednio połączone sieci i wewnętrzne ścieżki zarządzania.
• Szerokie trasy SD-WAN identyfikowane za pomocą Any.
• Sprawdzono reguły NAT i firewall.
• Zdefiniowano okno konserwacji lub ścieżkę awaryjną.
• Zmień zestaw w dokładnej kolejności.
• Po modyfikacji Log Viewer, Packet Capture i przeprowadzeniu testu aplikacji.
• Sprawdzono dostęp do zarządzania z sieci administracyjnych.
• Udokumentowana kolejność wycofania.

Często zadawane pytania