Sophos Firewall SD-WAN Sprawdź routing dla Reply Packets i System Traffic

SD-WAN Trasy w Sophos Firewall są istotne nie tylko dla klasycznego ruchu klient-internet. W zależności od środowiska może to również mieć wpływ na Reply Packets i ruch generowany przez system. Właśnie w tym miejscu często pojawiają się trudne do wykrycia problemy z routingiem: reguła wygląda poprawnie, Gateway jest aktywny, ale odpowiedzi idą niewłaściwą ścieżką lub sama zapora ogniowa nie dociera do usługi przez oczekiwaną linię.

W tym przewodniku wyjaśniono dwie opcje CLI reply-packet i system-generate-traffic, kiedy je sprawdzić i jak bezpiecznie testować zmiany. W przypadku normalnej konfiguracji trasy SD-WAN najpierw sprawdza się Skonfiguruj i przetestuj trasę i test Sophos Firewall SD-WAN. W przypadku ogólnego porządku między trasami statycznymi, trasami zasad SD-WAN i trasami VPN pasuje również Sophos Firewall bezpiecznie zmień Route Precedence.

⚠️ Te ustawienia mogą natychmiast wpłynąć na wydajne wyznaczanie tras. Przed dokonaniem zmiany należy udokumentować aktualny stan, wybrać okno konserwacji i znać jasną drogę powrotną. Szczególnie krytyczne są szerokie trasy SD-WAN z Any, Route Precedence przed trasami statycznymi i aktywowane routing SD-WAN dla System Traffic lub Reply Packets.

O co chodzi w tych dwóch opcjach

Dzięki trasom SD-WAN należy rozróżnić normalny ruch przekazywany, pakiety odpowiedzi i ruch generowany przez samą zaporę ogniową. Obie opcje nie określają, czy pojedyncza trasa SD-WAN jest zbudowana poprawnie. Zamiast tego rozszerzają rodzaj ruchu, który może być uwzględniany przez SD-WAN Policy Routing.

Obie opcje mają różne zadania:

• reply-packet: Wpływa na pakiety odpowiedzi na istniejący ruch. Umożliwia to wpływanie na ścieżkę powrotną poprzez SD-WAN w niektórych scenariuszach innych niż WAN.
• system-generate-traffic: Wpływa na ruch generowany przez samą zaporę ogniową. Umożliwia to kierowanie połączeń specyficznych dla zapory sieciowej za pośrednictwem zdefiniowanych tras SD-WAN.

Obie opcje nie powinny być aktywowane na ślepo tylko dlatego, że „SD-WAN nie działa”. Najpierw musi być jasne, czy rzeczywiście dotyczy to Reply Packets lub ruchu generowanego przez system. W przypadku normalnych połączeń rzeczywistą przyczyną jest często reguła zapory sieciowej, status NAT, Route Precedence, Gateway lub zbyt szeroka trasa SD-WAN.

Reply Packets

Reply Packets to pakiety odpowiedzi na istniejący ruch. Sophos Firewall generalnie wymusza symetryczny routing dla takich odpowiedzi na interfejsach WAN: pakiety odpowiedzi powinny wracać przez ten sam interfejs WAN, przez który nadeszło oryginalne połączenie. Opcja reply-packet jest szczególnie istotna, jeśli w niektórych scenariuszach routingu zasad SD-WAN mają być uwzględniane pakiety odpowiedzi. Typowym przykładem jest routing asymetryczny na interfejsach innych niż WAN, na przykład pomiędzy LAN i DMZ.

Ważnym ograniczeniem jest: Jeśli pierwotny ruch przebiega trasą domyślną lub funkcją równoważenia obciążenia łącza WAN, trasy SD-WAN nie mają zastosowania do tego Reply Packets. Zapora sieciowa w dalszym ciągu korzysta z odpowiedniej ścieżki zwrotnej poprzez interfejs pierwotnego połączenia.

Typowe pytania testowe:

• Czy to naprawdę jest ruch zwrotny, a nie nowe połączenie?
• Czy ruch odbywa się przez WAN, LAN, DMZ, XFRM czy inną strefę?
• Czy istnieje trasa SD-WAN, która ma celowo wpływać na trasę powrotną?
• Czy trasa jest zbyt szeroka, np. miejsce docelowe Any?
• Czy Route Precedence działa przed trasą statyczną lub trasą VPN?

Ruch generowany przez system

Ruch generowany przez system to ruch, który Sophos Firewall generuje sam. W zależności od środowiska może to obejmować DNS, NTP, Sophos Central, Syslog, aktualizacje, monitorowanie, usługi uwierzytelniania lub połączenia diagnostyczne.

Przy tym ruchu zapora nie rozpoznaje normalnego interfejsu przychodzącego ani normalnej sieci źródłowej, jak w przypadku przekazywanego ruchu klienta. Dlatego trasy SD-WAN należy planować szczególnie szczegółowo pod kątem ruchu generowanego przez system: sieci docelowe i Services muszą być wybierane rozsądnie. W przeciwnym razie bardzo szeroka trasa może nieoczekiwanie skierować ruch związany z zarządzaniem lub systemem na złą ścieżkę.

Ponadto obowiązują dwa praktyczne ograniczenia:

• Jeśli wszystkie bramy skonfigurowane w Network > WAN link manager są oznaczone jako Tylko kopia zapasowa, zapora nie będzie przesyłać przez nie ruchu generowanego przez system. Co najmniej jeden Gateway musi być Aktywny. — Ruch RED generowany przez system na UDP 3410 to ruch warstwy 2. SD-WAN Trasy nie mają tu zastosowania.

Kiedy sprawdzać te ustawienia

Obie opcje są szczególnie istotne w przypadku bardziej złożonych projektów tras. W prostych, pojedynczych środowiskach WAN rzadko są one pierwszą dźwignią.

Przydatne wyzwalacze:

— Ruch natywny zapory nie korzysta z oczekiwanej ścieżki WAN lub VPN.

• Syslog, Central, DNS, NTP lub monitorowanie powinny działać na określonej linii.
• IPsec VPN oparty na trasach z interfejsami XFRM jest używany razem z trasami SD-WAN.
• VoIP lub inny wrażliwy ruch działa tylko w jednym kierunku za pośrednictwem SD-WAN/VPN.
• Packet Capture pokazuje odpowiedzi w innym interfejsie niż oczekiwano.
• Po aktualizacji SD-WAN, IPsec lub NAT zachowuje się inaczej niż wcześniej.
• Szeroka trasa SD-WAN nagle wpływa na sieci wewnętrzne lub dostęp do zarządzania. W przypadku scenariuszy IPsec należy również uwzględnić Rozwiązywanie problemów Sophos Firewall IPsec VPN. W przypadku połączeń indywidualnych często lepszym punktem wyjścia jest test reguły Sophos Firewall z Log Viewer i Packet Capture.

Wyświetl bieżący stan

Polecenia są wykonywane w Device Console, a nie w Advanced Shell. Jeśli dostęp do konsoli nie jest jeszcze możliwy, pomocne będzie Połącz Sophos Firewall przez SSH.

Sprawdź status Reply Packets:

show routing sd-wan-policy-route reply-packet

Sprawdź stan ruchu generowanego przez system:

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

Ponadto WebAdmin pod Routing > SD-WAN routes pokazuje w podpowiedzi informacji o routingu, czy routing SD-WAN jest aktywny dla ruchu generowanego przez system i Reply Packets.

Przed dokonaniem jakichkolwiek zmian należy udokumentować aktualne wydanie. Jest to ważne, ponieważ późniejsze wycofanie jest możliwe tylko wtedy, gdy znany jest poprzedni stan.

Włącz opcje

SD-WAN Aktywuj routing dla Reply Packets:

set routing sd-wan-policy-route reply-packet enable

SD-WAN Włącz routing dla ruchu generowanego przez system:

set routing sd-wan-policy-route system-generate-traffic enable

Następnie wykonaj ponownie polecenia stanu i udokumentuj wynik.

⚠️ Nie dokonuj wielu zmian tras jednocześnie. Jeżeli Route Precedence, trasa SD-WAN, reguła NAT i te opcje CLI zostaną zmienione w tym samym czasie, trudno będzie później jednoznacznie przypisać błąd.

Bezpieczny przepływ zmian

Pragmatyczny proces zmniejsza ryzyko:

1. Zdefiniuj szczegółowo dotknięty ruch: źródło, miejsce docelowe, usługa, strefa, oczekiwany Gateway.
2. Udokumentuj istniejące trasy, bramy i Route Precedence SD-WAN.
3. Sprawdź, czy miejsce docelowe Any jest naprawdę potrzebne.
4. Udokumentuj aktualny stan reply-packet i system-generate-traffic.
5. Zmień tylko jedną opcję.
6. Przeprowadź test na wyraźnym przykładzie ruchu.
7. Sprawdź liczniki Log Viewer, Packet Capture i Gateway.
8. Udokumentuj wynik i dopiero wtedy dokonaj dalszych korekt. Jeśli może to mieć wpływ na dostęp do zarządzania, powinien być dostępny dodatkowy sposób dostępu: konsola lokalna, inna wewnętrzna ścieżka dostępu lub dostęp z nienaruszonej sieci zarządzania.

Walidacja po zmianie

Po aktywacji zielony status Gateway nie wystarczy. Musisz sprawdzić, czy żądany ruch rzeczywiście podąża oczekiwaną ścieżką.

Dzienniki Log Viewer i SD-WAN

Zdarzenia związane z zaporą sieciową i SD-WAN należy sprawdzić w przeglądarce logów. Aby uzyskać odpowiednie reguły zapory sieciowej, Log firewall traffic musi być aktywne. Bez logowania często widzisz tylko część decyzji.

Aby sprawdzić:

• Który Firewall Rule ID jest trafiony?
• Który NAT Rule ID jest używany?
• Który Gateway lub który interfejs pojawia się w logu?
• Czy zdarzyły się jakieś upadki, naruszenia zasad lub nieoczekiwane decyzje dotyczące zabezpieczeń?

Packet Capture

Rzeczywisty przepływ pakietów można sprawdzić za pomocą Diagnostics > Przechwytywanie pakietów. W przypadku pytań dotyczących routingu filtr powinien być wąski: Źródło IP, Miejsce docelowe IP, Port i Protokół.

Porównanie jest ważne:

• Czy paczka dociera do oczekiwanego interfejsu?
• Czy wychodzi z zapory ogniowej na oczekiwanym interfejsie?
• Czy odpowiedź wróci?
• Czy używany jest NAT?
• Czy trasa powrotna jest prawdopodobna dla Reply Packets?

Użyj Sophos Firewall Packet Capture w WebAdmin nadaje się do operacji i interpretacji.

Sprawdź usługi systemowe

W przypadku ruchu generowanego przez system należy w szczególności przetestować usługę, której dotyczy problem:

• DNS: Uruchom wyszukiwanie DNS na zaporze i sprawdź ścieżkę docelową.
• NTP: Sprawdź status czasowy i dostępność serwera NTP.
• Syslog: Sprawdź komunikat testowy lub bieżący dziennik w kolektorze.
• Sophos Central: Sprawdź połączenie centralne i raportowanie.
• Monitorowanie: Sprawdź SNMP, sFlow lub zewnętrzne kontrole kolektora.

Jeśli ruch generowany przez system nie jest widoczny, należy również sprawdzić, czy trasa SD-WAN powinna odpowiadać tylko sieciom źródłowym lub interfejsom przychodzącym. Kryteria te nie są dostępne w przypadku ruchu należącego do zapory ogniowej, tak jak w przypadku ruchu klienckiego.

Typowe błędy

• Trasa SD-WAN z miejscem docelowym Any dla ścieżek wewnętrznych: Ruch wewnętrzny lub dostęp do zarządzania można kierować za pośrednictwem WAN. Lepsze są internetowe grupy docelowe lub określone sieci docelowe.
• Route Precedence ustawia SD-WAN przed statycznym: Sieci połączone bezpośrednio lub statyczne mogą nieoczekiwanie zostać dopasowane przez SD-WAN. Sprawdź Route Precedence i w razie potrzeby ustaw Static przed SD-WAN.
• system-generate-traffic aktywny bez ograniczenia miejsca docelowego: Usługi specyficzne dla zapory ogniowej mogą używać niewłaściwej ścieżki. Dlatego należy dokładnie zdefiniować sieci docelowe i Services.
• Reply Packets mylony z normalnymi nowymi połączeniami: Następnie przetwarzana jest niewłaściwa przyczyna. Packet Capture i sprawdź kierunek przepływu.
• Kilka zmian routingu jednocześnie: Przyczyna błędu pozostaje niejasna. Zmieniaj stopniowo i dokumentuj każdy test.
• Brak alternatywnego dostępu do zarządzania: WebAdmin lub SSH może zostać utracony z dotkniętej sieci. Przygotuj okno konserwacji i ścieżkę dostępu.

Szczególnie krytyczne ryzyko pojawia się, gdy zachodzi kilka warunków: Route Precedence znajduje się na SD-WAN przed statycznym, szeroka trasa SD-WAN wykorzystuje Any, a routing SD-WAN dla ruchu generowanego przez system lub Reply Packets jest aktywny. W takim przypadku może zostać utracony dostęp do WebAdmin lub SSH z niektórych podsieci wewnętrznych.

Interakcja z NAT, IPsec i VoIP

SD-WAN rzadko jest zaangażowany sam. NAT, IPsec lub ruch specyficzny dla aplikacji odgrywają rolę w wielu zakłóceniach. Dla SNAT ważne jest to, czy to samo źródło IP jest utrzymywane w różnych bramach. Jeśli używany jest MASQ lub inne przetłumaczone adresy źródłowe, przełączenie awaryjne lub przekierowanie może spowodować problemy z komunikacją. Dla podstaw: Zrozum, że NAT pasuje do Sophos Firewall.

W przypadku sieci VPN IPsec opartych na trasach interfejsy XFRM mogą być używane w trasach SD-WAN lub profilach SD-WAN. Następnie należy sprawdzić łącznie status IPsec, trasę SD-WAN, Route Precedence i reguły firewalla. Podstawy VPN oparte na trasach są podzielone na kategorie w Trasa IPsec na Sophos Firewall. Jeśli masz problemy z VoIP, warto przyjrzeć się także SIP, RTP, NAT i SD-WAN. Informacje o wydaniu SFOS-22.0-MR1 dokumentują naprawiony problem polegający na tym, że dźwięk VoIP działał tylko w jedną stronę za pośrednictwem VPN opartego na trasach z routingiem SD-WAN po aktualizacji do SFOS 22.0 GA. Praktyczny proces można znaleźć w Sophos Firewall Napraw problemy VoIP za pomocą SIP i RTP.

Wycofanie

Przed dokonaniem zmian należy udokumentować stary stan. Jeśli będzie to miało wpływ na dostęp do zarządzania, usługi systemowe lub ruch produkcyjny, improwizacja nie będzie już konieczna. Najpierw przywróć poprzedni stan.

Praktycznie oznacza to:

1. Zresetuj udokumentowane wcześniej wartości dla reply-packet i system-generate-traffic.
2. Przywróć Route Precedence do poprzedniego zamówienia, jeśli zostało zmienione.
3. Tymczasowo dezaktywuj zbyt szerokie trasy SD-WAN lub ogranicz je do określonych miejsc docelowych.
4. Dostęp do zarządzania testami z nienaruszonej sieci.
5. Następnie zawęź rzeczywistą przyczynę.

Jeśli dostęp do WebAdmin i SSH zostanie utracony z wewnętrznej podsieci, ale nadal będzie możliwy z innej podsieci, należy najpierw sprawdzić szeroką trasę SD-WAN, Route Precedence i dwie opcje CLI.

Lista kontrolna

• Udokumentowano bieżący stan dwóch opcji CLI.
• Specjalnie zdefiniowany ruch, którego to dotyczy.
• Trasa SD-WAN nie została zbudowana niepotrzebnie szeroko za pomocą Any.
• Sprawdzono Route Precedence.
• Co najmniej jeden WAN-Gateway dla System Traffic dostępny jako Aktywny.
• Przygotowano alternatywne połączenie do zarządzania.
• Dokonano tylko jednej zmiany na test.
• Log Viewer i Packet Capture używane do walidacji.
• Sprawdzono NAT, IPsec i reguły zapory sieciowej.
• Wynik i wycofanie udokumentowane w dzienniku operacji.

Często zadawane pytania