Konfiguracja i test trasy statycznej Sophos Firewall

Trasa statyczna wskazuje Sophos Firewall, przez jaki stały Next Hop lub interfejs tunelowy można osiągnąć określony cel. Jest właściwa, gdy ścieżka jest stała i nie trzeba wybierać jej na podstawie źródła, usługi, aplikacji ani jakości łącza.

Krótka odpowiedź

Trasę IPv4 tworzy się tutaj:

Routing > Static routes > IPv4 unicast route > Add

Dla sieci docelowej 10.20.0.0/24, osiągalnej przez router 192.0.2.2 za pośrednictwem Port4, należy wprowadzić:

Destination IP / Netmask: 10.20.0.0/24
Gateway IP: 192.0.2.2
Interface: Port4
Administrative distance: 1
Metric: 10
Description: Branch_10.20_via_Core

Następnie w Diagnostics > Tools > Route lookup należy sprawdzić cel 10.20.0.10. Oczekiwany interfejs to Port4.

Aby ruch faktycznie działał, potrzebna jest również odpowiednia reguła zapory oraz trasa zwrotna po stronie przeciwnej. Trasa statyczna nie zezwala na ruch i nie wykonuje automatycznie NAT.

Jak działa przykład

W przykładzie użyto następującej topologii:

Sieć klientów za Sophos Firewall to 10.10.0.0/24.
Klient testowy w tej sieci ma adres 10.10.0.10.
Port4 zapory ma adres tranzytowy 192.0.2.1/30.
Następny router ma w tej sieci adres IP 192.0.2.2.
Za tym routerem znajduje się sieć docelowa 10.20.0.0/24.
System testowy ma adres 10.20.0.10.

Destination zawsze oznacza zdalny cel, a nie następny router. Gateway IP to bezpośrednio osiągalny Next Hop, który przekazuje pakiet. Interface to port lub interfejs tunelowy, przez który osiągany jest ten Next Hop.

Adres wpisuje się bezpośrednio w polu Gateway IP; nie jest do tego potrzebny obiekt gateway w Routing > Gateways. Dla własnego środowiska trzeba wspólnie zastąpić sieć docelową, gateway i interfejs. Skopiowanie tylko jednego adresu przykładowego może pozwolić na zapisanie trasy, ale skierować ją do niewłaściwej sieci lub przez nieosiągalny router. Adres IP gatewaya musi należeć do sieci wybranego interfejsu.

Podstawy dotyczące portów, stref i adresów interfejsów opisano w artykule Konfiguracja stref i interfejsów Sophos Firewall.

Kiedy trasa statyczna jest właściwa

Trasa statyczna ma sens, gdy sieć jest stale osiągalna przez ten sam Next Hop, na przykład:

sieć oddziału za wewnętrznym Core Routerem
sieć serwerowa za przełącznikiem warstwy 3
sieć za tunelem RED
zdalna sieć przez interfejs XFRM tunelu route-based IPsec

Jeśli zapora musi dodatkowo decydować na podstawie źródła, usługi lub aplikacji albo zmieniać ścieżkę według opóźnienia, jittera i utraty pakietów, zwykle lepszym narzędziem jest trasa SD-WAN. W większych i często zmienianych sieciach OSPF lub BGP zmniejszają nakład pracy związany z ręcznym utrzymaniem tras.

Konfiguracja trasy IPv4

Przed zmianą należy udokumentować sieć docelową, Next Hop, interfejs wyjściowy, oczekiwaną strefę, trasę zwrotną i osiągalny host testowy. Następnie:

Otworzyć Routing > Static routes.
W sekcji IPv4 unicast route kliknąć Add.
W polu Destination IP / Netmask wprowadzić 10.20.0.0/24.
W polu Gateway IP wprowadzić następny router 192.0.2.2.
Jako Interface wybrać Port4.
Ustawić Administrative distance na 1.
W polu Metric wprowadzić 10.
Dodać jednoznaczny Description, na przykład Branch_10.20_via_Core.
Zapisać ustawienia za pomocą Save.

Sophos Firewall uwzględnia dla tej trasy najpierw wybrany interfejs, a następnie gateway. Jeśli którekolwiek z tych pól jest nieprawidłowe, zamierzony Next Hop nie zostanie osiągnięty.

Administrative Distance i Metric

Administrative Distance ocenia konkurujące źródła routingu. Mniejsza wartość ma pierwszeństwo: trasa z wartością 1 jest preferowana względem trasy z wartością 5.

Jeśli kilka tras statycznych do tego samego celu ma taką samą Administrative Distance, decyduje Metric. Również w tym przypadku mniejsza wartość ma pierwszeństwo.

Globalna Route Precedence między Static, SD-WAN i VPN działa na innym poziomie niż Administrative Distance i Metric. Nie należy zmieniać jej pochopnie z powodu jednej nowej trasy.

Przykładowe wartości 1 i 10 są prostymi wartościami początkowymi dla pojedynczej trasy, a nie ogólnym ustawieniem produktu. Przed ich zastosowaniem należy porównać istniejące trasy do tego samego celu. W przypadku Primary/Backup lub ECMP wartości Administrative Distance i Metric dobiera się świadomie zgodnie z wymaganą kolejnością.

Dwie trasy z różną Administrative Distance mogą definiować ścieżkę preferowaną i zapasową. Administrative Distance i Metric nie monitorują jednak samodzielnie Next Hopa. Do prostego failover opartego na osiągalności można użyć monitorowanych obiektów gateway wraz z trasami statycznymi o różnych wartościach Administrative Distance. Do wyboru na podstawie opóźnienia, jittera lub utraty pakietów używa się SD-WAN Profile i trasy SD-WAN.

Dla IPv4 ECMP tworzy się kilka tras do tego samego celu z taką samą Administrative Distance i Metric, ale różnymi Next Hopami. Powoduje to rozłożenie ruchu, ale nie tworzy jakościowej ścieżki Primary/Backup.

Świadome użycie Blackhole

Opcja Blackhole odrzuca ruch do wskazanego celu bez odpowiedzi do źródła. Może to być przydatne dla celowo blokowanych lub zagregowanych sieci, ale nie zastępuje zwykłego Next Hopa.

Jeśli trasy statyczne są redystrybuowane przez RIP, OSPF lub BGP, trzeba tam celowo odfiltrować trasy Blackhole. W przeciwnym razie zapora może przekazać tę trasę odrzucającą także innym routerom.

Przypadki szczególne IPv6 i tuneli

W sekcji IPv6 unicast route wprowadza się adres docelowy z prefiksem, Gateway IP, Interface i Metric. W formularzu IPv6 Sophos nie dokumentuje Administrative Distance, opcji Blackhole, opisu ani funkcji Clone, włączania lub wyłączania. Dlatego ustawień IPv4 nie należy bez sprawdzenia przenosić do IPv6.

W przypadku tunelu route-based IPsec z Any-to-Any-Subnets trasa może wskazywać bezpośrednio interfejs XFRM bez oddzielnego gatewaya. Jeśli tunel używa konkretnych Traffic Selectors, SFOS tworzy trasę automatycznie; wtedy na interfejsie XFRM nie konfiguruje się własnych adresów IP ani dodatkowych tras. Trasa XFRM nie jest też zależnym od wersji przypadkiem szczególnym CLI ipsec_route; różnicę wyjaśnia artykuł Tworzenie trasy IPsec na Sophos Firewall.

Dla sieci za interfejsem peer w tunelu Site-to-Site RED między zaporami Sophos Firewall obowiązuje kolejny wyjątek: jako gateway wprowadza się adres IP interfejsu RED peera, ale nie wybiera się interfejsu. Dzięki temu zapora może określić osiągalny interfejs za pomocą ARP. Nie dotyczy to usuniętych w SFOS 22 tuneli Legacy RED Server/Client do Sophos UTM.

Reguła zapory, NAT i trasa zwrotna

Routing określa ścieżkę. Reguła zapory decyduje, czy pakiet może przejść, a NAT w razie potrzeby zmienia jego adresy. Te trzy funkcje konfiguruje się oddzielnie.

W tym przykładzie potrzebna jest reguła z sieci klientów 10.10.0.0/24 do sieci docelowej 10.20.0.0/24. Jako Destination Zone obowiązuje strefa Port4. Regułę należy ograniczyć do rzeczywiście potrzebnych usług i włączyć dla niej logowanie na czas testu.

W normalnie routowanej sieci lokalizacji SNAT zwykle nie jest pożądany, ponieważ strona przeciwna powinna widzieć rzeczywisty adres IP klienta. Router 192.0.2.2 potrzebuje wtedy tej trasy zwrotnej:

Zielnetz: 10.10.0.0/24
Next Hop: 192.0.2.1

Jeśli po stronie przeciwnej nie można skonfigurować trasy zwrotnej, SNAT może technicznie pomóc. Ukrywa jednak pierwotny adres IP klienta i powinien pozostać świadomą decyzją projektową. Zależności opisano w artykule Zrozumienie NAT na Sophos Firewall.

Sprawdzanie trasy

Zapisaną trasę można uznać za zweryfikowaną dopiero wtedy, gdy rzeczywisty klient osiąga stronę przeciwną i działa trasa zwrotna.

W Diagnostics > Tools > Route lookup wprowadzić 10.20.0.10. Wynik musi wskazywać Port4.
W Device Console sprawdzić skonfigurowane trasy IPv4 lub IPv6, a przy konkurencji z SD-WAN albo VPN także Route Precedence:
```
show static-route
show static-route6
system route_precedence show
```
Z klienta 10.10.0.10 uruchomić rzeczywiste połączenie do 10.20.0.10, na przykład Ping lub TCP 443, zgodnie z regułą zapory.
W Log viewer sprawdzić źródło, cel, usługę, Firewall Rule ID i ewentualny NAT Rule ID.
W Diagnostics > Packet capture użyć filtra host 10.20.0.10, aby sprawdzić, czy żądania wychodzą przez Port4 i czy odpowiedzi wracają.

Jeśli Route Lookup wskazuje prawidłową ścieżkę, ale ruch nie przepływa, przyczyną jest zwykle reguła zapory, NAT, trasa zwrotna lub system docelowy. Pełny test przepływu pakietów opisano w artykule Testowanie reguły Sophos Firewall za pomocą Log Viewer i Packet Capture.

W przypadku głębszych problemów z routingiem w Device Console pomocne są ostatnie wpisy logów Unicast i kernela:

show logs staticd.log lines 50
show logs zebra.log lines 50

staticd.log dotyczy statycznych tras Unicast; zebra.log pokazuje instalowanie statycznych tras Unicast IPv4 w kernelu. Inne pliki dziennika przypisano do odpowiednich usług w artykule Usługi i pliki dziennika Sophos Firewall.

Po ponownym uruchomieniu interfejsu lub tunelu trasa oparta wyłącznie na gatewayu może początkowo nie być widoczna w tabeli routingu. Pojawia się, gdy pasujący ruch odpowiada celowi i gatewayowi, a zapora wybiera interfejs. Brak wpisu bezpośrednio po restarcie nie oznacza jeszcze usterki.

Ograniczanie błędów i rollback

Route Lookup wskazuje nieprawidłowy interfejs

Sprawdzić adres docelowy i prefiks; literówka może dopasować inną sieć.
Gateway musi być bezpośrednio osiągalny przez wybrany interfejs.
Porównać konkurujące trasy statyczne oraz Administrative Distance i Metric.
W przypadku SD-WAN lub VPN sprawdzić bieżącą kolejność za pomocą system route_precedence show. Globalną zmianę wyjaśnia artykuł Bezpieczna zmiana Route Precedence.

Żądanie wychodzi, ale odpowiedź nie wraca

Sprawdzić trasę zwrotną na następnym routerze i w systemie docelowym.
Sprawdzić regułę zapory dla kierunku inicjującego oraz istniejące reguły NAT. Reguła w kierunku przeciwnym jest potrzebna tylko wtedy, gdy strona przeciwna sama inicjuje nowe połączenia.
Za pomocą Packet Capture ustalić, czy odpowiedź wraca do Port4.
Sprawdzić lokalną zaporę i default gateway systemu docelowego.

Bezpieczny rollback

Nową trasę IPv4 najpierw się wyłącza, zamiast ją usuwać. Następnie ponownie sprawdza się Route Lookup, nowe połączenie klienta i dotychczasową ścieżkę. Dopiero po potwierdzeniu stanu początkowego można w razie potrzeby usunąć trasę oraz reguły lub obiekty NAT utworzone wyłącznie na potrzeby tej zmiany.

Dla IPv6 Sophos nie dokumentuje funkcji włączania ani wyłączania. Dlatego wcześniej zapisuje się dotychczasowe wartości, a podczas rollbacku nową trasę edytuje lub usuwa. W klastrze HA test powtarza się po failover na nowym Primary; logi nie są synchronizowane między urządzeniami.

Często zadawane pytania

Czy zawsze trzeba podawać gateway i interfejs?

W przypadku zwykłej trasy Ethernet zazwyczaj tak. Route-based IPsec może używać wyłącznie interfejsu XFRM; w opisanym przypadku szczególnym RED jako gateway podaje się tylko adres IP interfejsu RED peera.

Dlaczego połączenie nie działa mimo prawidłowego Route Lookup?

Route Lookup potwierdza tylko wybraną ścieżkę. Często brakuje reguły zapory, trasy zwrotnej, właściwej decyzji NAT albo zezwolenia w systemie docelowym.

Czy trasa statyczna automatycznie monitoruje gateway?

Administrative Distance i Metric nie monitorują gatewaya. Prosty failover oparty na osiągalności jest możliwy z monitorowanymi obiektami gateway i priorytetowymi trasami statycznymi; dla kryteriów jakościowych, takich jak opóźnienie, jitter lub utrata pakietów, używa się SD-WAN.