Tworzenie trasy IPsec na Sophos Firewall

Zazwyczaj Sophos Firewall sam rozpoznaje, przez który tunel IPsec można osiągnąć sieć docelową. W klasycznym tunelu policy-based IPsec lokalne i zdalne sieci są częścią konfiguracji tunelu. W przypadku route-based IPsec ruch jest kierowany do tunelu za pomocą interfejsów XFRM, tras statycznych, tras SD-WAN lub routingu dynamicznego.

Ręczna trasa IPsec nie jest standardem dla każdego tunelu. Jest to narzędzie do określonych scenariuszy policy-based, zwłaszcza gdy przekierowany ruch musi współpracować z NAT lub specjalnym przypisaniem do tunelu. Jeśli taka trasa zostanie ustawiona nieprawidłowo, ruch może trafić do niewłaściwego tunelu lub istniejące połączenie może stać się trudniejsze do zrozumienia.

Dla nowych tuneli między lokalizacjami najpierw pasuje Konfiguracja Site-to-Site IPsec VPN na Sophos Firewall. Dla ogólnego rozwiązywania problemów z IPsec pasuje Rozwiązywanie problemów z IPsec VPN na Sophos Firewall. Jeśli chodzi o VPN-y route-based, XFRM i planowanie interfejsów, pomocne będzie Konfigurowanie stref i interfejsów na Sophos Firewall.

Kiedy trasa IPsec ma sens

Trasa IPsec jest szczególnie istotna, gdy istnieje tunel policy-based IPsec, ale oczekiwany ruch nie jest poprawnie przypisany do tunelu.

Typowe przypadki:

• Host lub sieć powinny być kierowane przez określony tunel policy-based.
• Istnieje wiele tuneli, nakładające się sieci docelowe lub historycznie rozwinięte konfiguracje VPN.
• Ruch jest tłumaczony przez DNAT lub SNAT i musi być przypisany do istniejącego tunelu IPsec.
• Po aktualizacji do SFOS 22 należy sprawdzić, czy stare przypadki specjalne policy-based działają zgodnie z oczekiwaniami.
• Route Lookup, Log Viewer lub Packet Capture pokazują, że ruch kieruje się w stronę WAN lub niewłaściwej ścieżki.

Nie każdy z tych przypadków zostanie rozwiązany przez ipsec_route. Najpierw należy sprawdzić reguły zapory, reguły NAT, Route Precedence, lokalne bramy i trasy zwrotne.

Policy-based, route-based i SFOS 22

Najważniejsza różnica:

• Policy-based IPsec: Sophos Firewall wykonuje zapytania IPsec w tle lokalne/zdalne sieci w połączeniu IPsec, reguły zapory, w razie potrzeby ipsec_route
• Route-based IPsec: Ruch jest kierowany do interfejsu tunelu Interfejs XFRM, trasa statyczna, trasa SD-WAN lub routing dynamiczny.

Dla nowych lub większych połączeń między lokalizacjami route-based IPsec jest często bardziej przejrzysty, ponieważ zmiany routingu nie zmieniają za każdym razem selektorów tunelu. Dla prostych połączeń Site-to-Site lub istniejących środowisk policy-based IPsec pozostaje jednak nadal istotny.

SFOS 22 wprowadził zmiany w zachowaniu IPsec w kilku miejscach. W notatkach wydania SFOS-22.0-MR1 udokumentowano kilka rozwiązanych problemów związanych z policy-based IPsec, ipsec_route, SD-WAN, SNAT i Route Lookup. Dla administratorów oznacza to: po aktualizacji należy celowo testować przypadki specjalne policy-based, zwłaszcza gdy zaangażowane są NAT, MPLS, SD-WAN lub ręczne trasy IPsec.

Wymagania

Przed wprowadzeniem zmian należy upewnić się, że:

• Dostęp do Device Console, na przykład przez SSH.
• Nazwa tunelu IPsec.
• Host docelowy lub sieć docelowa, które mają być osiągnięte przez tunel.
• Aktywne lub poprawnie skonfigurowane połączenie IPsec.
• Odpowiednie reguły zapory dla oczekiwanego kierunku.
• Jasność, czy zaangażowany jest NAT.
• Aktualny stan istniejących tras IPsec jest udokumentowany.

Jeśli dostęp do konsoli nie został jeszcze skonfigurowany, Łączenie z Sophos Firewall przez SSH wyjaśnia, jak nawiązać połączenie SSH z zaporą i otworzyć Device Console.

⚠️ Nieprawidłowa trasa IPsec może zakłócić ruch produkcyjny. Przed wprowadzeniem zmian należy udokumentować nazwę tunelu, sieć docelową, NAT, trasę zwrotną i istniejące trasy.

Sprawdzenie przed zmianą

Nie należy ustawiać trasy IPsec jako pierwszego kroku. Sensowna jest następująca kolejność:

1. Sprawdzenie statusu tunelu: Połączenie IPsec jest aktywne i oczekiwane sieci są negocjowane.
2. Sprawdzenie reguł zapory: Strefa źródłowa, strefa docelowa, źródło, cel, usługa i logowanie są odpowiednie.
3. Sprawdzenie NAT: Jest jasne, czy przez tunel mają przechodzić oryginalne adresy IP czy przetłumaczone.
4. Sprawdzenie Route Precedence: Trasy statyczne, SD-WAN i VPN są oceniane w oczekiwanej kolejności. Jeśli konkurują różne rodzaje routingu, pomocne będzie Bezpieczna zmiana Route Precedence na Sophos Firewall.
5. Sprawdzenie strony przeciwnej: Strona przeciwna zna trasę zwrotną i oczekiwany adres źródłowy.
6. Użycie Packet Capture: Sprawdzenie, czy ruch dociera, dokąd jest kierowany i czy odpowiedzi wracają.

Dla ogólnego sprawdzania reguł pasuje Testowanie reguł zapory za pomocą Log Viewer, Policy Test i Packet Capture. Dla podstaw NAT pasuje Zrozumienie NAT na Sophos Firewall.

Wyświetlanie istniejących tras IPsec

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

system ipsec_route show

Wynik powinien być udokumentowany przed każdą zmianą. W ten sposób można później zobaczyć, czy trasa została dodana i czy trzeba ją usunąć.

Dodatkowo, przy analizie może być istotna tabela routingu IPsec:

ip route show table 220

To sprawdzenie odbywa się w Advanced Shell i jest raczej przeznaczone do rozwiązywania problemów. Dla normalnych zmian w ipsec_route właściwym miejscem pozostaje Device Console.

Tworzenie trasy IPsec dla hosta

Jeśli tylko jeden host ma być osiągalny przez określony tunel, używa się host.

Składnia:

system ipsec_route add host <host-ip> tunnelname <tunnelname>

Przykład:

system ipsec_route add host 10.33.46.69 tunnelname Azure_CH

Następnie należy przetestować nie tylko ping, ale także rzeczywisty ruch aplikacji. Test ICMP może działać, podczas gdy TCP, NAT lub trasa zwrotna nadal są nieprawidłowe.

Tworzenie trasy IPsec dla sieci

Jeśli cała sieć ma być osiągalna przez tunel, używa się net.

Składnia:

system ipsec_route add net <network>/<netmask> tunnelname <tunnelname>

Przykład:

system ipsec_route add net 10.33.46.0/255.255.255.0 tunnelname Azure_CH

Przy trasach sieciowych należy zachować szczególną ostrożność. Zbyt duża sieć może przyciągnąć więcej ruchu do tunelu niż planowano. Przy nakładających się sieciach musi być jasne, która strona widzi które adresy i czy używany jest NAT.

Usuwanie trasy IPsec

Jeśli trasa nie jest już potrzebna lub została ustawiona nieprawidłowo, można ją usunąć.

Usuwanie trasy hosta:

system ipsec_route del host <host-ip>

Usuwanie trasy sieci:

system ipsec_route del net <network>/<netmask>

Następnie ponownie sprawdź listę:

system ipsec_route show

Jeśli trasa miała wpływ na ruch produkcyjny, po usunięciu należy ponownie przetestować połączenie i porównać wpisy w Log Viewer.

NAT i policy-based IPsec

NAT nie jest zasadniczo błędny przy IPsec. Musi być jednak starannie zaplanowany, ponieważ NAT zmienia adres, który widzi strona przeciwna.

Sophos rozróżnia między innymi następujące przypadki przy IPsec:

• NAT bezpośrednio w konfiguracji IPsec, na przykład przy nakładających się sieciach.
• Samodzielne reguły NAT w Rules and policies > NAT rules.
• ipsec_route dla przekierowanego ruchu, gdy przetłumaczony ruch musi być przypisany do tunelu policy-based.
• sys-traffic-nat dla ruchu generowanego przez samą zaporę.

Reguła NAT nie zmienia automatycznie decyzji routingu zapory. Jeśli istniejący tunel policy-based jest używany z DNAT/SNAT dla dodatkowych hostów, nadal potrzebna jest pasująca IPsec Route do zdalnej sieci. Przy reflexive SNAT przetłumaczony adres źródłowy musi istnieć jako obiekt IP host; nie można po prostu tłumaczyć bezpośrednio na interfejs.

Ważny jest kierunek: Jeśli ruch policy-based IPsec ma być tłumaczony przez SNAT, odpowiednia reguła SNAT musi działać z Outbound interface ustawionym na Any. Jeśli reguła jest ograniczona do określonych interfejsów WAN, nie będzie stosowana do ruchu policy-based IPsec. Takie szczegóły prowadzą w praktyce do tuneli, które są zielone, ale nie przenoszą oczekiwanego ruchu użytkowego.

Ruch generowany przez system to przypadek szczególny

ipsec_route nie rozwiązuje samodzielnie każdego problemu z ruchem. Dla przekazywanego ruchu klienta lub serwera polecenie może być bezpośrednio istotne. Ruch generowany przez samą zaporę, taki jak zapytania uwierzytelniające lub przypadki związane z DHCP, wymaga dodatkowo właściwej logiki source NAT i routingu.

Bez ukierunkowanej konfiguracji ruch generowany przez system zwykle używa bramy z Network > WAN link manager. Zielony tunel IPsec nie wystarczy więc, aby automatycznie wysłać zapytania własne firewalla do tunelu. DHCP Relay należy ocenić osobno: w przypadku policy-based IPsec przy DHCP Relay trzeba celowo włączyć opcję Relay through IPsec. W przypadku VPN route-based ta opcja nie jest potrzebna; tam ruch DHCP jest kierowany jak zwykły ruch przez trasy statyczne, SD-WAN lub dynamiczne do drugiej strony, o ile lokalne i zdalne podsieci są ustawione na Any i po obu stronach istnieją odpowiednie trasy.

Praktycznie oznacza to:

• Ruch klienta lub serwera przez zaporę może być tematem ipsec_route.
• Przy policy-based IPsec zapytania własne zapory mogą wymagać kombinacji ipsec_route, sys-traffic-nat oraz pasujących podsieci lokalnych lub zdalnych.
• Przy route-based IPsec takie przypadki zwykle prowadzi się trasami SD-WAN do interfejsu XFRM oraz przez sys-traffic-nat.
• Nie należy próbować rozwiązywać każdego problemu z ruchem systemowym za pomocą ipsec_route.

Dla ruchu generowanego przez system i kontekstu SD-WAN pasuje Routing SD-WAN dla pakietów odpowiedzi i ruchu systemowego.

Testowanie zmiany

Po utworzeniu lub usunięciu trasy IPsec należy celowo przetestować dotknięty ruch.

Praktyczny przebieg:

1. Zdefiniuj przypadek testowy: źródło, cel, usługa, kierunek i oczekiwany tunel.
2. Włącz logowanie reguł zapory dla dotkniętej reguły.
3. Udokumentuj system ipsec_route show.
4. Wygeneruj ruch testowy dokładnie raz.
5. Filtruj Log Viewer według źródła, celu i reguły zapory.
6. Wykonaj Packet Capture z wąskim filtrem.
7. Sprawdź, czy bajty w ipsec statusall rosną w obu kierunkach.
8. Sprawdź stronę przeciwną pod kątem trasy zwrotnej, NAT i lokalnej zapory.

Jeśli większe transmisje się zawieszają, mimo że routing i NAT wydają się poprawne, należy dodatkowo sprawdzić MTU i MSS przy problemach z VPN.

Typowe błędy

• Tunel zielony, brak ruchu: często brakuje reguły, NAT, trasy zwrotnej lub przypisania IPsec. Sprawdzić Log Viewer, Packet Capture i ipsec statusall.
• Ruch kieruje się w stronę WAN: Route Precedence lub przypisanie IPsec nie pasuje. Sprawdzić Route Lookup, SD-WAN Routes i ipsec_route show.
• SNAT nie działa przy policy-based IPsec: reguła SNAT prawdopodobnie ma niewłaściwe Outbound Interface. Sprawdzić regułę SNAT z Any.
• Jeden host działa, sieć nie: maska sieci, obiekt lub Traffic Selector nie pasuje. Porównać lokalne i zdalne sieci.
• Po aktualizacji do SFOS 22 inne zachowanie: może być zaangażowany stary przypadek specjalny z policy-based IPsec, NAT lub SD-WAN. Sprawdzić release notes, przypadek testowy i stronę przeciwną.
• Ruch własny zapory nie przechodzi przez tunel: ruch systemowy jest inaczej kierowany. Sprawdzić SD-WAN, Route Precedence i sys-traffic-nat.

Lista kontrolna

Przed zmianą:

• Udokumentowano nazwę tunelu i stronę przeciwną.
• Host docelowy lub sieć docelowa są jednoznaczne.
• Sprawdzone reguły zapory i reguły NAT.
• Sprawdzone Route Precedence i kontekst SD-WAN.
• Zabezpieczone istniejące trasy IPsec.
• Zaplanowano okno konserwacyjne lub kontrolowany czas testu.

Po zmianie:

• Ponownie sprawdzono system ipsec_route show.
• Log Viewer pokazuje oczekiwaną regułę.
• Packet Capture pokazuje oczekiwaną ścieżkę.
• Strona przeciwna widzi oczekiwany adres źródłowy.
• Trasa zwrotna działa.
• Zmiana i uzasadnienie udokumentowane.

FAQ