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

Wariant: klienci zdalni uzyskują dostęp do adresu wirtualnego

Wirtualny adres docelowy może ukrywać adresy serwerów wewnętrznych przed zdalnym urządzeniem. Tego scenariusza nie należy mylić z powyższym przykładem NAT dla połączenia policy-based: udokumentowany wariant wykorzystuje IPsec typu route-based z podsieciami Any-to-any, interfejsy XFRM z przypisanymi adresami oraz zwykłe trasy. Nie tworzy się w tym celu ręcznej trasy ipsec_route.

W przykładzie za zaporą 1 znajduje się sieć 192.168.2.0/24; klienci zdalni za zaporą 2 korzystają z sieci 192.168.3.0/24. Uzyskują dostęp do serwerów 172.16.16.2 i 172.16.16.3 przez adres wirtualny 10.10.10.1. Jest to adres docelowy DNAT, a nie adres bramy XFRM. Wszystkie wartości należy zastąpić obiektami odpowiednimi dla własnego środowiska.

1. W połączeniach IPsec na obu zaporach ustaw Connection type na Route-based (Tunnel interface), a Local subnet i Remote subnets na Any. W przykładzie zapora 1 używa ustawienia Respond only, a zapora 2 — Initiate the connection. W sekcji Network > Interfaces otwórz niebieski pasek przy odpowiednim Listening interface, wybierz interfejs XFRM, wpisz zaplanowany dla niego adres IP i zapisz ustawienia. Podstawową konfigurację tunelu opisuje procedura konfiguracji IPsec site-to-site.
2. Ogranicz reguły zapory do rzeczywistej usługi aplikacyjnej: na zaporze 2 ze strefy LAN do VPN, ze źródłem 192.168.3.0/24 i wymaganymi adresami docelowymi 192.168.2.0/24 lub 10.10.10.1; na zaporze 1 ze strefy VPN do rzeczywistej strefy serwerów, z tym samym zdalnym źródłem i wymaganymi obiektami docelowymi 192.168.2.0/24 lub 10.10.10.1. Przykładowa strefa docelowa Any nie jest zaleceniem dla stałej reguły zezwalającej.
3. W sekcji Routing > SD-WAN routes > IPv4 > Add na zaporze 2 skieruj ruch ze źródła 192.168.3.0/24 do wymaganych adresów docelowych 192.168.2.0/24 lub 10.10.10.1 przez bramę na lokalnym interfejsie XFRM. W sekcji Link selection settings > Primary and backup gateways wybierz lub utwórz odpowiednią Primary gateway. Na zaporze 1 dodaj ścieżkę powrotną ze źródłami 192.168.2.0/24 lub 10.10.10.1 i adresem docelowym 192.168.3.0/24 przez jej bramę XFRM. Można również użyć tras statycznych lub dynamicznych.
4. Opcja Route only through specified gateways zapobiega użyciu ścieżki alternatywnej przez odrzucanie ruchu, gdy tunel jest niedostępny. W przykładzie jest ona włączona na zaporze 2, a na zaporze 1 przedstawiona jako opcjonalna; oczekiwane zachowanie w razie awarii trzeba świadomie określić po obu stronach. Ustawienie Administration > Device access > Ping/Ping6 > VPN dotyczy pingowania lokalnych usług zapory, a nie zezwolenia na przekazywanie ruchu do usługi na serwerze.
5. Na zaporze 1 w sekcji Rules and policies > NAT rules > Add NAT rule > New NAT rule utwórz regułę DNAT: Original source 192.168.3.0/24, Translated source Original, Original destination 10.10.10.1, Translated destination — obiekt listy serwerów z adresami 172.16.16.2 i 172.16.16.3, Load balancing method Round-robin. Zezwól tylko na wymaganą usługę; lista jest przeznaczona dla kilku odpowiednich serwerów backendowych, a nie dowolnych hostów.

W ramach weryfikacji końcowej zainicjuj kilka nowych połączeń aplikacyjnych z adresem wirtualnym i sprawdź w Packet Capture oraz na podstawie Rule ID i NAT ID wybrane serwery backendowe, ścieżkę XFRM i odpowiedzi. Sam ping nie potwierdza działania DNAT, aplikacji ani rozdzielania połączeń. Wcześniej wykonaj kopię zapasową tras, reguł i obiektów; przy wycofywaniu konfiguracji usuń po sprawdzeniu zależności tylko elementy utworzone dla tego wariantu lub przywróć poprzednie wartości. Nie ma tu trasy ipsec_route do usunięcia. Dlatego poniższe procedury diagnostyczne nadal rozróżniają oba typy tuneli.

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.

Przy wartości Any zapora używa adresu Translated source z pasującej reguły SNAT, również wtedy, gdy opcja Override source translation (SNAT) jest włączona dla określonych interfejsów wychodzących. Reguła wskazująca w polu Outbound interface tylko określone porty WAN, w tym typowa domyślna reguła SNAT, nie pasuje do tego ruchu IPsec typu policy-based. Wyjaśnienie NAT w artykule o IPsec site-to-site opisuje tę zależność; nie jest to powód do zbiorczej zmiany ustawień nadpisywania. Po wprowadzeniu konkretnej poprawki w regule zainicjuj nowy, kontrolowany przepływ aplikacyjny i ponownie sprawdź NAT ID, src_trans_ip, selektory oraz ścieżkę powrotną, zgodnie z wcześniejszą procedurą weryfikacji ścieżki ruchu.

Ś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 samą zaporę są obsługiwane w odrębny sposób. Ogólne stwierdzenie, że ruch systemowy nie wymaga ręcznej trasy IPsec, byłoby jednak błędne: w przypadku policy-based IPsec instrukcja uwierzytelniania dla SFOS 22.0 i 23.0 wyraźnie przewiduje trasę IPsec, jeśli żądanie nie trafia do tunelu z powodu wybranego ustawienia Route Precedence. Najpierw muszą być poprawne adres źródłowy, sys-traffic-nat, Traffic Selectors i ścieżka powrotna; dopiero wtedy przypisuje się wyłącznie wymagany adres docelowy do istniejącego tunelu policy-based. Weryfikację końcową przeprowadza się przy użyciu rzeczywistego żądania uwierzytelniania i Packet Capture, a wycofanie konfiguracji wykonuje się osobno, odpowiednim poleceniem system ipsec_route del host lub del net, po sprawdzeniu wpisu.

Pełna procedura uwierzytelniania dla połączeń policy-based i route-based znajduje się w artykule Routing SD-WAN dla pakietów odpowiedzi i ruchu systemowego. Omówiono tam również sprzeczności między opisanymi rolami adresów NAT a przykładami poleceń. Jeśli adres źródłowy nie został jednoznacznie ustalony, nie wprowadzaj zmian w środowisku produkcyjnym, a w szczególności nie używaj adresu serwera AD jako adresu źródłowego po translacji. W przypadku IPsec typu route-based stosuje się trasy XFRM, a nie ipsec_route; przekaźnik DHCP nadal wymaga odrębnej procedury. Nie wynika z tego ani konieczność zbiorczej zmiany globalnego ustawienia Route Precedence, ani gwarancja działania.

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.