Tworzenie trasy IPsec na Sophos Firewall

Ręczna trasa ipsec_route służy do obsługi połączeń IPsec typu policy-based. Przypisuje docelowego hosta lub sieć do istniejącego tunelu policy-based. Nie rozszerza jednak zakresu Traffic Selectors ani nie zastępuje reguł zapory, reguł NAT czy ścieżki powrotnej po stronie zdalnej.

Tego polecenia nie należy używać w połączeniach IPsec typu route-based. W tunelu Any-to-any interfejs XFRM otrzymuje adres IP, a ścieżkę wyznaczają trasy statyczne, SD-WAN lub dynamiczne. W tunelu route-based z Traffic Selectors system SFOS tworzy trasę automatycznie. Powiązanemu interfejsowi XFRM nie można przypisać adresu IP ani własnych tras.

⚠️ Trasa o zbyt szerokim zakresie lub przypisana do niewłaściwego tunelu może przekierować ruch produkcyjny. Przed wprowadzeniem zmiany zapisz stan początkowy i przygotuj dokładne polecenie usuwające trasę.

Kiedy warto utworzyć ręczną trasę IPsec

Typowym zastosowaniem jest przekazywany ruch, którego adres zmienia DNAT lub SNAT. Translacja NAT zmienia adres, ale nie zmienia decyzji o trasowaniu. Z tego powodu może być potrzebna dodatkowa trasa do sieci zdalnej.

Przed wykonaniem polecenia sprawdź następujące kwestie:

• Połączenie w sekcji Site-to-site VPN > IPsec > IPsec connections jest typu policy-based.
• Lokalne i zdalne Traffic Selectors obejmują adresy, które mechanizm IPsec rzeczywiście otrzymuje po translacji NAT.
• Reguły zapory i NAT obejmują zdefiniowany ruch testowy. W przypadku SNAT dla połączenia IPsec typu policy-based opcja Outbound interface ma wartość Any.
• Zdalne urządzenie oczekuje widocznego adresu źródłowego i ma trasę powrotną prowadzącą przez ten sam tunel.
• Istniejąca trasa statyczna lub SD-WAN oraz globalne ustawienie Route Precedence nie kierują ruchu do miejsca docelowego inną ścieżką.

Ręczna trasa nie rozwiąże problemu z nieprawidłową maską sieci, niezgodnym selektorem ani regułą blokującą ruch. Typy tuneli opisano w artykule Konfiguracja sieci VPN IPsec site-to-site na Sophos Firewall.

Zapisywanie stanu początkowego w Device Console

W interfejsie WebAdmin otwórz admin > Console i wybierz 4. Device console. W przypadku dostępu przez SSH instrukcja Łączenie z Sophos Firewall przez SSH prowadzi do tego samego menu.

Najpierw wyświetl istniejące ręczne trasy IPsec oraz globalną kolejność tras:

system ipsec_route show
system route_precedence show

Zapisz wyniki poleceń wraz z nazwą tunelu, Traffic Selectors, identyfikatorem Firewall Rule ID, identyfikatorem NAT Rule ID i planowanym przepływem testowym. W systemie SFOS 22 zarówno automatycznie tworzone trasy sieci VPN typu policy-based, jak i ręczne wpisy ipsec_route należą do kategorii vpn. Trasy te nie są widoczne w tabeli tras interfejsu WebAdmin, dlatego wynik polecenia ip route show table 220 nie stanowi wiarygodnego dowodu na ich brak.

Nie zmieniaj Route Precedence przy okazji wykonywania tej procedury. Jest to ustawienie globalne, które wpływa także na inne połączenia. Jeśli zmiana jest rzeczywiście konieczna, oddzielną procedurę wraz z wycofaniem opartym na zapisanych wartościach zawiera artykuł Bezpieczna zmiana Route Precedence na Sophos Firewall.

Tworzenie trasy na podstawie kontrolowanego przykładu NAT

Sophos opisuje następujący, ściśle określony przypadek użycia:

• Tunel policy-based HO_to_Branch łączy sieć lokalną 192.168.2.0/24 z siecią zdalną 192.168.3.0/24.
• Rzeczywisty serwer lokalny 172.16.16.10 znajduje się poza zakresem lokalnego selektora.
• Zdalne urządzenie łączy się z nim pod adresem 192.168.2.1. Ten adres zastępczy należy do zakresu lokalnego selektora, a w tym przykładzie jest adresem interfejsu LAN zapory.

Remote 192.168.3.0/24 → 192.168.2.1 → DNAT → Server 172.16.16.10
Server 172.16.16.10 → reflexive SNAT → 192.168.2.1 → IPsec → Remote

Zastąp sieć, adresy i nazwę tunelu własnymi wartościami. Adres zastępczy musi należeć do lokalnego zakresu Phase 2, a istniejący tunel musi obejmować zdalną sieć docelową.

1. Przypisywanie sieci zdalnej do tunelu

Wykonaj następujące polecenie w Device Console:

system ipsec_route add net 192.168.3.0/255.255.255.0 tunnelname HO_to_Branch

W parametrze net system SFOS wymaga pełnej maski w notacji dziesiętnej z kropkami. Użyj najwęższego zakresu docelowego, jakiego wymaga aplikacja. Odpowiadające mu polecenie wycofujące zmianę to:

system ipsec_route del net 192.168.3.0/255.255.255.0

Polecenie usuwające nie zawiera nazwy tunelu. Przed jego wykonaniem użyj system ipsec_route show i upewnij się, że miejsce docelowe jest jednoznaczne. Nie usuwaj niejednoznacznych wpisów wyłącznie na podstawie przypuszczeń.

Dla pojedynczego hosta docelowego konsola obsługuje następującą postać polecenia:

system ipsec_route add host 10.33.46.69 tunnelname Azure_CH
system ipsec_route del host 10.33.46.69

Trasa do hosta ma węższy zakres, ale jest właściwa tylko wtedy, gdy miejscem docelowym jest dokładnie ten host i zakres Traffic Selectors jest z nim zgodny.

2. Konfigurowanie DNAT i reflexive SNAT

1. W sekcji Rules and policies > NAT rules > Add NAT rule > New NAT rule utwórz regułę DNAT. Dla opcji Original source ustaw 192.168.3.0/24, opcję Translated source pozostaw jako Original, dla Original destination ustaw 192.168.2.1, a dla Translated destination — 172.16.16.10.
2. Włącz opcję Create reflexive rule.
3. Otwórz utworzoną regułę Reflexive_NAT#_<DNAT_rule_name>. Dla opcji Translated source wybierz obiekt hosta IP z adresem 192.168.2.1. Utwórz go w sekcji Hosts and services > IP host > Add. Sophos nie może w tej regule wykonać translacji bezpośrednio na interfejs.
4. Sprawdź kolejność, stan i rejestrowanie zdarzeń obu reguł NAT oraz powiązanej reguły zapory.

Nie dodawaj ogólnej reguły MASQ ani nie zezwalaj dodatkowo na przesyłanie przez tunel ruchu rzeczywistego serwera z adresem bez translacji. Zasady dopasowywania i kolejności reguł opisano w artykule Zasady NAT na Sophos Firewall.

Weryfikowanie ścieżki ruchu

Zielony stan tunelu ani odpowiedź na ping nie potwierdzają działania translacji NAT czy ścieżki powrotnej. Na potrzeby weryfikacji zdefiniuj rzeczywisty przepływ aplikacyjny, na przykład połączenie TCP od zdalnego klienta do opublikowanej usługi serwera.

1. Ponownie wykonaj system ipsec_route show. Sieć docelowa musi być przypisana dokładnie raz do właściwego tunelu.
2. Zainicjuj jedno kontrolowane połączenie z sieci 192.168.3.0/24 do adresu 192.168.2.1, korzystając z dozwolonej usługi.
3. W narzędziu Log viewer ustaw filtry Source, Destination i Firewall Rule ID. W widoku szczegółowym pole src_trans_ip wskazuje rzeczywisty adres źródłowy po translacji bardziej wiarygodnie niż widok podsumowania.
4. Otwórz Monitor & analyze > Diagnostics > Packet capture i ustaw filtry obejmujące klienta, adres zastępczy i rzeczywisty serwer. Wartości Rule ID i NAT ID muszą odpowiadać udokumentowanym regułom, a interfejsy wejściowy i wyjściowy — planowanej ścieżce.
5. Po stronie zdalnej sprawdź, czy odpowiedzi z adresu 192.168.2.1 są oczekiwane i wracają przez ten sam tunel.
6. Przetestuj pobliskiego hosta lub usługę, które nie są dozwolone. Ten test negatywny nadal musi zakończyć się niepowodzeniem, potwierdzając, że zakres trasy i reguł nie jest zbyt szeroki.

Sama aktywna SA lub rosnące liczniki bajtów nie są wystarczającym potwierdzeniem. Pełną procedurę diagnostyczną zawiera artykuł Rozwiązywanie problemów z VPN IPsec na Sophos Firewall, a analizę reguł i przechwyconych pakietów — Testowanie reguły zapory za pomocą Log Viewer, Policy Test i Packet Capture.

Całkowite wycofywanie zmiany

Najpierw zakończ wszystkie nowe sesje testowe. Osobno przywróć udokumentowany wcześniejszy stan reguł DNAT i reflexive SNAT. Późniejsza zmiana reguły DNAT nie usuwa automatycznie reguły reflexive.

Następnie usuń wyłącznie nowo utworzoną trasę:

system ipsec_route del net 192.168.3.0/255.255.255.0
system ipsec_route show

Nowy obiekt hosta IP usuń dopiero wtedy, gdy Object usage nie wskazuje już żadnego odwołania. Następnie powtórz pierwotny przepływ testowy i test negatywny. Zapisane wcześniej ustawienie Route Precedence musi pozostać bez zmian.

Jeśli omyłkowo usunięto tylko trasę, zapisane polecenie dodające przywróci dokładnie ten sam wpis:

system ipsec_route add net 192.168.3.0/255.255.255.0 tunnelname HO_to_Branch

Systematyczne diagnozowanie typowych błędów

Trasa istnieje, ale ruch trafia do sieci WAN

Sprawdź wynik system ipsec_route show, ustawienie Route Precedence oraz konkurencyjne trasy SD-WAN. W systemie SFOS 22 brak wpisu w tabeli tras interfejsu WebAdmin lub w tabeli 220 nie świadczy o braku trasy IPsec. W ramach Route Precedence kategoria vpn ma pierwszeństwo przed static tylko dla ruchu kierowanego do strefy WAN, dlatego trzeba również sprawdzić strefy i rzeczywistą ścieżkę do miejsca docelowego.

Tunel jest aktywny, ale NAT nie działa

Porównaj adresy pierwotne i adresy po translacji z Traffic Selectors. W przypadku SNAT dla połączenia policy-based opcja Outbound interface musi mieć wartość Any. Następnie sprawdź Firewall Rule ID, NAT ID i src_trans_ip, zamiast polegać wyłącznie na stanie tunelu.

Ścieżka wychodząca działa, ale brakuje odpowiedzi

Zdalne urządzenie musi znać adres po translacji i kierować ruch powrotny przez ten sam tunel. Sprawdź po jego stronie selektor, regułę zapory i trasę powrotną. Odmiennej ścieżki powrotnej nie można naprawić przez poszerzenie lokalnej trasy ipsec_route.

Problem dotyczy ruchu generowanego przez system lub DHCP

Żądania uwierzytelniania, DNS i DHCP generowane przez zaporę są obsługiwane w odrębny sposób. W systemie SFOS 22 zwykle nie wymagają ręcznej trasy IPsec. Zamiast stosować do nich tę procedurę przekazywania ruchu, skorzystaj z artykułu Routing SD-WAN dla pakietów odpowiedzi i ruchu systemowego albo z osobnej procedury dotyczącej przekaźnika DHCP.

Po aktualizacji do SFOS 22 brakuje dynamicznego rozgłoszenia trasy

W systemie SFOS 22 trasy sieci VPN typu policy-based nie są zwykłymi trasami jądra. Jeśli wcześniej protokół OSPF lub BGP rozgłaszał je za pomocą redistribute kernel, ten odrębny problem migracyjny opisano w artykule Dlaczego redistribute kernel nie rozgłasza tras IPsec po aktualizacji do SFOS 22.