Tworzenie trasy IPsec na Sophos Firewall

Ręczna trasa IPsec nie jest standardowym elementem każdego tunelu. Stosuje się ją przede wszystkim w przypadku policy-based IPsec, gdy przekazywany i poddany translacji ruch trzeba przypisać do określonego tunelu.

Route-based IPsec: Nie należy tworzyć ipsec_route. Ruch przechodzi przez interfejsy XFRM oraz trasy statyczne, SD-WAN lub dynamiczne. Policy-based IPsec bez szczególnego przypadku NAT: Najpierw należy sprawdzić tunel, reguły zapory, NAT i trasę zwrotną. Policy-based IPsec z przekazywanym ruchem DNAT lub SNAT: Poniższe kroki pomagają sprawdzić i skonfigurować trasę.

⚠️ Nieprawidłowa trasa IPsec może skierować ruch produkcyjny do niewłaściwego tunelu. Przed każdą zmianą należy zapisać stan początkowy i przygotować dokładną ścieżkę rollbacku.

Sprawdzanie, tworzenie i usuwanie trasy IPsec

Polecenia do wyświetlania, tworzenia i usuwania tras wykonuje się w Device Console. Jeśli dostęp nie został jeszcze skonfigurowany, artykuł Łączenie z Sophos Firewall przez SSH pokazuje, jak otworzyć Device Console.

Zapisywanie stanu początkowego

Przed wykonaniem polecenia Add trzeba znać konkretną ścieżkę ruchu:

• Jest to aktywny tunel policy-based, a nie route-based IPsec.
• Host lub sieć docelowa pasują do selektorów tunelu i planowanej translacji.
• Reguły zapory i NAT pasują do zdefiniowanego ruchu testowego; przy SNAT opcja Outbound interface ma wartość Any.
• Sprawdzono Route Precedence i konkurujące trasy.
• Strona przeciwna oczekuje widocznego adresu źródłowego i ma trasę zwrotną.

Najpierw należy udokumentować wszystkie ręczne trasy IPsec:

system ipsec_route show

W przypadku problemów z routingiem lub NAT należy również zapisać Route Precedence i ustawienia NAT dla ruchu systemowego:

system route_precedence show
show advanced-firewall

W Advanced Shell przydatny może być również ten starszy widok troubleshootingowy:

ip route show table 220

Według Sophos w SFOS 22 trasy policy-based IPsec i wpisy ipsec_route nie są widoczne w tej tabeli. Brak wpisu nie dowodzi zatem, że trasa IPsec nie istnieje. Decydujące pozostają system ipsec_route show, konfiguracja i test ruchu.

Tworzenie trasy dla hosta

Składnia:

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

Przykład dla hosta 10.33.46.69 przez tunel Azure_CH:

system ipsec_route add host 10.33.46.69 tunnelname Azure_CH

Tworzenie trasy dla sieci

Składnia:

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

Przykład dla sieci 10.33.46.0/24:

system ipsec_route add net 10.33.46.0/255.255.255.0 tunnelname Azure_CH

Maska musi dokładnie odpowiadać żądanemu celowi. Zbyt szeroka trasa może nieumyślnie skierować dodatkowy ruch do tunelu.

Bezpieczne usuwanie trasy

⚠️ Polecenia usuwania nie zawierają nazwy tunelu. Przed usunięciem należy użyć system ipsec_route show, aby sprawdzić, czy host lub sieć są jednoznaczne, i przygotować pełne polecenie Add do rollbacku. Przy niejednoznacznych wpisach nie należy niczego usuwać na podstawie przypuszczeń.

Usuwanie trasy hosta:

system ipsec_route del host <host-ip>

Usuwanie trasy sieci:

system ipsec_route del net <network>/<netmask>

Następnie należy ponownie sprawdzić listę:

system ipsec_route show

Jeśli wynik testu się pogorszy, należy odtworzyć trasę za pomocą zapisanego wcześniej polecenia Add.

Kiedy ipsec_route jest właściwym rozwiązaniem

Policy-based i route-based IPsec

W przypadku policy-based IPsec sieci lokalne i zdalne definiują selektory tunelu. Ręczna ipsec_route może przypisać dodatkowe hosty lub sieci do istniejącego tunelu, ale nie zastępuje poprawnych selektorów, reguł zapory ani trasy zwrotnej.

W przypadku route-based IPsec ruch jest kierowany do interfejsu XFRM. W zależności od projektu używa się do tego trasy statycznej, trasy SD-WAN lub routingu dynamicznego. ipsec_route jest tutaj niewłaściwym narzędziem. Podstawy obu wariantów opisano w artykułach Konfiguracja Site-to-Site IPsec VPN na Sophos Firewall i Konfigurowanie stref i interfejsów na Sophos Firewall.

Różnica między SFOS 21.5 a 22

Zmieniło się przypisanie w ramach Route Precedence:

• W SFOS 21.5 automatycznie utworzone trasy policy-based IPsec należą do kategorii vpn, natomiast ręczne wpisy ipsec_route do static.
• W SFOS 22 zarówno automatyczne, jak i ręczne trasy policy-based IPsec należą do kategorii vpn. Nie są widoczne jak zwykłe trasy kernela i są przetwarzane wewnętrznie na podstawie znaczników, stref i flag.

Po aktualizacji z SFOS 21.5 należy zatem ponownie przetestować Route Precedence i istniejące przypadki szczególne. Kontrola przed aktualizacją do SFOS 22 zawiera ogólne punkty kontrolne. Globalną kolejność wyjaśnia artykuł Bezpieczna zmiana Route Precedence na Sophos Firewall.

Jeżeli sieci policy-based VPN były dotąd przekazywane do OSPF lub BGP przez redistribute kernel, ta kontrola nie wystarczy: od SFOS 22 trasy VPN nie są już zwykłymi trasami kernela. Artykuł Dlaczego redistribute kernel nie rozgłasza tras IPsec po aktualizacji do SFOS 22 wyjaśnia objawy i docelowy projekt route-based XFRM.

Ręczna trasa ma sens dopiero wtedy, gdy tunel, Traffic Selector, reguła zapory, reguła NAT i trasa zwrotna są poprawne. Nie naprawi błędnej maski, brakującej trasy zwrotnej po stronie przeciwnej ani blokującej reguły.

NAT dla przekazywanego ruchu

NAT zmienia adresy, ale nie zmienia automatycznie decyzji routingu. Jeśli tunel policy-based obsługuje dodatkowy ruch poddany translacji przez DNAT lub SNAT, może być potrzebna odpowiednia trasa IPsec do zdalnego hosta lub sieci.

W przypadku SNAT dla policy-based IPsec odpowiednia reguła NAT musi mieć Outbound interface ustawione na Any. Jeśli jest ograniczona do konkretnego interfejsu WAN, nie dopasuje się do ruchu IPsec. Artykuł Zrozumienie NAT na Sophos Firewall dokładniej wyjaśnia kolejność, dopasowanie i trasę zwrotną.

Zmianę należy wykonać w oknie konserwacyjnym lub przy użyciu kontrolowanego przypadku testowego. Wcześniej trzeba określić następujące wartości:

• oryginalne adresy źródłowe i docelowe oraz adresy po translacji,
• lokalną i zdalną sieć połączenia IPsec,
• nazwę tunelu i oczekiwaną regułę zapory,
• trasę zwrotną i dozwolone adresy po stronie przeciwnej.

Osobna obsługa ruchu generowanego przez system

Zapytania DNS, uwierzytelniające i inne żądania samej zapory nie muszą podlegać tej samej logice co przekazywany ruch klientów. W SFOS 22 zwykle nie jest do nich potrzebna ipsec_route. Tylko specjalna instrukcja Sophos dotycząca zapytań uwierzytelniających wymienia ją jako warunkowe rozwiązanie awaryjne, gdy z powodu konkretnego ustawienia Route Precedence żądanie w sposób potwierdzony nie trafia do tunelu policy-based.

W razie potrzeby adres źródłowy takiego ruchu można określić za pomocą sys-traffic-nat. Przykład: zapora ma uzyskać dostęp do serwera 10.10.2.15 przy użyciu zdefiniowanego adresu SNAT/interfejsu 10.10.1.1. Adres ten musi pasować do podsieci IPsec i mieć trasę zwrotną po stronie przeciwnej.

Poniższe polecenia wykonuje się w Device Console:

set advanced-firewall sys-traffic-nat add destination 10.10.2.15 snatip 10.10.1.1
show advanced-firewall

Rollback:

set advanced-firewall sys-traffic-nat delete destination 10.10.2.15 snatip 10.10.1.1

Jeśli podczas dodawania użyto również interface lub netmask, podczas usuwania trzeba podać te same selektory. Więcej przykładów zawiera artykuł Routing SD-WAN dla Reply Packets i System Traffic.

DHCP wymaga osobnej oceny:

• Przy policy-based IPsec relay wymaga opcji Relay through IPsec, odpowiednich lokalnych i zdalnych podsieci IPsec, sys-traffic-nat oraz niezbędnych reguł i tras zwrotnych po stronie przeciwnej. Jeśli z powodu konkretnej konfiguracji routingu żądania nadal nie trafiają do tunelu, może być potrzebna ipsec_route jako sprawdzony fallback.
• Przy route-based IPsec nie włącza się opcji Relay through IPsec. Obsługiwany jest relay do strony serwera DHCP przez interfejs XFRM z podsieciami Any-to-any, trasami statycznymi, SD-WAN lub dynamicznymi oraz odpowiednimi regułami na obu zaporach. ipsec_route nie należy do tej ścieżki.
• Jeśli w konfiguracji policy-based IPsec zapora w centrali sama działa jako serwer DHCP dla sieci zdalnych, należy włączyć Lease over IPsec. Według Sophos interfejsy zapory jako serwery DHCP nie są obsługiwane w tym projekcie route-based.

To polecenie również wykonuje się w Device Console:

system dhcp lease-over-IPSec enable

Starsze procedury dla SFOS 21.5 częściej wskazywały ipsec_route wprost przy uwierzytelnianiu i DHCP. Takie konfiguracje należy sprawdzić przy aktualizacji i nie odtwarzać ich bez weryfikacji.

Testowanie i odbiór zmiany

Zielony tunel lub udany ping nie są wystarczającym dowodem. Test ICMP może działać, mimo że TCP, NAT lub trasa zwrotna nadal są nieprawidłowe.

1. Określ Source, Destination, Service, kierunek i oczekiwany tunel.
2. Włącz logowanie odpowiedniej reguły zapory.
3. Przed testem zapisz system ipsec_route show.
4. Jednorazowo wygeneruj rzeczywisty ruch aplikacji.
5. Filtruj Log Viewer według Source, Destination i reguły.
6. Wykonaj Packet Capture z wąskim filtrem po obu stronach ścieżki.
7. Po stronie przeciwnej sprawdź adres źródłowy, trasę zwrotną i lokalną zaporę.
8. Udokumentuj wynik, zmianę i polecenie rollbacku.

W Advanced Shell poniższe polecenia pokazują wynegocjowane SA, liczniki bajtów i polityki XFRM:

ipsec statusall
ip xfrm policy

Same w sobie nie dowodzą jednak, że NAT, reguła zapory i trasa zwrotna są poprawne. W systematycznej analizie pomaga artykuł Testowanie reguł zapory za pomocą Log Viewer, Policy Test i Packet Capture. Jeśli zawieszają się tylko większe transfery, należy dodatkowo sprawdzić MTU i MSS przy problemach z VPN.

Zawężanie błędów i rollback

Tunel jest aktywny, ale ruch nie przepływa

Należy sprawdzić regułę zapory, NAT, Traffic Selector i trasę zwrotną. Następnie trzeba porównać Log Viewer, Packet Capture i liczniki z ipsec statusall. Pełną procedurę opisano w artykule Rozwiązywanie problemów z IPsec VPN na Sophos Firewall.

Ruch jest kierowany w stronę WAN

Należy sprawdzić Route Precedence, trasy SD-WAN i system ipsec_route show. W SFOS 22 brak wpisu w tabeli 220 nie może być używany jako dowód przeciw istnieniu trasy IPsec.

SNAT nie jest stosowany

Przy policy-based IPsec należy sprawdzić, czy Outbound interface ma wartość Any oraz czy adresy oryginalne i adresy po translacji pasują do tunelu i strony przeciwnej.

Host działa, ale sieć nie

Należy porównać maskę, obiekt hosta/sieci i Traffic Selector po obu stronach. Nie należy tworzyć szerszej trasy przed zrozumieniem rozbieżności.

Ścieżka zmienia się po aktualizacji do SFOS 22

Należy ponownie sprawdzić Route Precedence i wszystkie przypadki szczególne policy-based z NAT, SD-WAN lub MPLS. Nie należy automatycznie usuwać ani ponownie tworzyć starych tras.

Ruch generowany przez zaporę nie dociera do celu

Najpierw trzeba ustalić, czy chodzi o uwierzytelnianie, DNS, DHCP czy inną usługę. Następnie należy sprawdzić Route Precedence, SD-WAN, sys-traffic-nat i odpowiedni workflow dla SFOS 22.

Jeśli błąd pojawia się bezpośrednio po zmianie, należy usunąć nową trasę, sprawdzić wynik za pomocą system ipsec_route show i powtórzyć wcześniejszy test. Jeśli problem nadal występuje, trzeba w pełni odtworzyć udokumentowany stan początkowy.

FAQ