Konfiguracja redundancji route-based IPsec z dwoma łączami internetowymi

Drugie łącze internetowe nie zapewnia automatycznie redundancji tunelu IPsec. Niezawodny failover wymaga oddzielnego połączenia route-based dla każdego łącza, osobno adresowanego interfejsu XFRM i monitorowanej ścieżki routingu. Dopiero wtedy Sophos Firewall może celowo przełączyć ruch z ISP1 na ISP2 i po przywróceniu wrócić do preferowanej ścieżki.

Ta procedura dotyczy route-based IPsec Any-to-Any między dwoma firewallami Sophos. Tunele policy-based oraz route-based z konkretnymi Traffic Selectors korzystają zamiast tego z grupy failover IPsec.

Skrócony przebieg

1. Osobno przetestować na obu firewallach tunel Any-to-Any przez ISP1 i tunel przez ISP2.
2. Przypisać unikatowy adres transferowy do każdego z czterech interfejsów XFRM.
3. Na każdym firewallu utworzyć monitorowany gateway dla obu adresów XFRM peera.
4. Dodać dwie trasy statyczne do tej samej zdalnej sieci LAN: Primary z niższą i Backup z wyższą Administrative Distance.
5. Zapisać globalną Route Precedence i ustawić ją na static vpn sdwan_policyroute tylko wtedy, gdy pasuje do całego projektu.
6. Sprawdzić reguły firewalla i trasy powrotne dla obu ścieżek XFRM.
7. W kontrolowany sposób przerwać ISP1, przetestować rzeczywisty ruch aplikacji przez ISP2, a następnie sprawdzić Failback do ISP1.

⚠️ Route Precedence obowiązuje na całym firewallu. Zmiana może wpływać również na istniejące ścieżki Static, VPN i SD-WAN. Najpierw należy zapisać aktualną wartość i wszystkie nakładające się trasy, utworzyć backup konfiguracji oraz sprawdzić niezależny dostęp administracyjny.

Projekt i wymagania

Zrozumienie modelu failover

Dwa połączenia IPsec pozostają niezależnymi tunelami. Trasa z niższą Administrative Distance jest preferowaną ścieżką danych. Jeśli jej monitorowany gateway XFRM zostanie uznany za nieosiągalny, ruch może przejąć trasa przez drugi tunel.

Są to dwa oddzielne stany:

• Tunel jest aktywny: zestawiono IKE i Child SA.
• Ścieżka jest użyteczna: gateway, trasa, reguła firewalla, oczekiwane działanie NAT, peer i trasa powrotna działają dla rzeczywistego ruchu.

Sam zielony tunel nie dowodzi więc działania failoveru. Nie wystarcza także zwykły failover WAN: WAN link manager nie tworzy drugiego połączenia IPsec ani odpowiedniej trasy na peerze.

Any-to-Any nie korzysta z dodatkowej grupy failover VPN. Ścieżkę wybierają adresowane interfejsy XFRM, gatewaye i trasy. Artykuł Konfiguracja VPN IPsec Site-to-Site wyjaśnia pełną podstawową konfigurację takiego tunelu.

Planowanie przykładowej topologii

Przykład łączy centralę z oddziałem:

• Centrala: 172.16.16.0/24
• Oddział: 192.168.10.0/24
• Primary: ISP1
• Backup: ISP2
• Sieć XFRM ISP1: 10.255.1.0/30
• Sieć XFRM ISP2: 10.255.2.0/30

Head office 172.16.16.0/24                 Branch office 192.168.10.0/24

       xfrm-ISP1 10.255.1.1  ⇄  10.255.1.2 xfrm-ISP1     AD 1
Firewall HQ                                                   Firewall BO
       xfrm-ISP2 10.255.2.1  ⇄  10.255.2.2 xfrm-ISP2     AD 2

Adresy są wartościami dokumentacyjnymi i należy je zastąpić własnymi, nienakładającymi się sieciami transferowymi. Każda para XFRM potrzebuje oddzielnej sieci. Publiczne adresy ISP, Local i Remote IDs, Profiles oraz Listening Interfaces muszą dla każdego tunelu odpowiadać konfiguracji peera.

Konfiguracja tuneli, gatewayów i tras

Przygotowanie dwóch tuneli

Na każdym firewallu tworzy się dwa połączenia w Site-to-site VPN > IPsec. Oba używają Route-based (Tunnel interface) oraz Any dla Local subnet i Remote subnet. W typowej konfiguracji centrali i oddziału centrala używa Respond only, a oddział Initiate the connection.

Pierwszy tunel korzysta z interfejsu WAN ISP1, drugi z interfejsu WAN ISP2. Oba połączenia testuje się osobno przed konfiguracją failoveru. Za każdym razem aktywny pozostaje wyłącznie przewidziany tunel, a ustalony przepływ danych sprawdza się w obu kierunkach.

W Network > Interfaces automatycznie utworzone interfejsy XFRM otrzymują następujące przykładowe adresy:

• Centrala: 10.255.1.1/30 dla ISP1 i 10.255.2.1/30 dla ISP2
• Oddział: 10.255.1.2/30 dla ISP1 i 10.255.2.2/30 dla ISP2

Nie zmienia się adresacji interfejsu XFRM, dopóki zależą od niego inne trasy lub usługi. Przed każdą zmianą należy sprawdzić Object usage, stan tunelu i istniejące obiekty routingu.

Monitorowanie gatewayów XFRM

Po obu stronach w Routing > Gateways tworzy się po jednym gatewayu na tunel do adresu XFRM peera. W centrali są to 10.255.1.2 i 10.255.2.2, a w oddziale 10.255.1.1 i 10.255.2.1.

Jako Interface wybiera się właściwy XFRM. Jeśli ma być oceniana cała dalsza ścieżka, Monitoring Target powinien być stabilnym i dozwolonym endpointem za peerem. Ping wyłącznie do adresu XFRM peera potwierdza tylko bezpośredni odcinek tunelu.

Wybór celu jest decyzją operacyjną: musi odpowiadać stabilnie, nie może znikać podczas normalnych prac konserwacyjnych i wymaga odpowiedniej reguły dostępu. Artykuł Tworzenie i sprawdzanie Custom Gateway szczegółowo wyjaśnia Health Check, status i warunki zatrzymania.

Dodawanie statycznych tras Primary i Backup

W centrali, w Routing > Static routes, dodaje się dwie trasy IPv4 Unicast do sieci oddziału 192.168.10.0/24:

• przez 10.255.1.2 i XFRM ISP1 z Administrative distance 1
• przez 10.255.2.2 i XFRM ISP2 z Administrative distance 2

W oddziale tworzy się lustrzanie dwie trasy do sieci centrali 172.16.16.0/24:

• przez 10.255.1.1 i XFRM ISP1 z Administrative distance 1
• przez 10.255.2.1 i XFRM ISP2 z Administrative distance 2

Niższa Administrative Distance wygrywa, dopóki odpowiadający jej gateway jest dostępny. Identyczne sieci docelowe i różne odległości tworzą w ten sposób ścieżki Primary i Backup. To nie jest ECMP z równymi priorytetami. Artykuł Konfiguracja i testowanie trasy statycznej wyjaśnia ogólną logikę trasy i ścieżki powrotnej.

Kontrolowane ustawianie Route Precedence

Sophos dokumentuje ten projekt z Static przed VPN i SD-WAN. Najpierw zapisuje się istniejący stan w Device Console:

system route_precedence show

Tylko jeśli ta kolejność pasuje do całego projektu routingu, ustawia się ją na obu firewallach:

system route_precedence set static vpn sdwan_policyroute

Następnie wartość ponownie sprawdza się poleceniem system route_precedence show. Ta zmiana nie jest ogólnym rozwiązaniem problemów IPsec. Wpływa również na inne nakładające się trasy Static, VPN i SD-WAN. Bezpieczna zmiana Route Precedence wyjaśnia globalne działanie i rollback.

Uzgodnienie reguł, NAT i ścieżki powrotnej

Oba firewalle wymagają odpowiednich reguł między LAN i VPN. Źródła, cele i usługi ogranicza się do rzeczywistych sieci lokalizacji i aplikacji; Log firewall traffic pozostaje włączone podczas wdrożenia.

Normalnie routowany ruch między lokalizacjami zazwyczaj nie wymaga SNAT. Jeśli istnieją już wyjątki NAT lub celowane translacje, muszą działać tak samo na obu ścieżkach. Nie należy dodawać szerokiej reguły MASQ jako skrótu dla failoveru.

Trasa na peerze jest równie ważna jak ścieżka wychodząca. Tunel może być aktywny, mimo że odpowiedź wraca przez niewłaściwego ISP lub bardziej ogólną trasę. Dlatego Route Lookup, aktywną trasę, Firewall Rule ID, NAT Rule ID i Packet Capture ocenia się razem.

Testowanie i obsługa failover

Test Failover i Failback

Przed testem awarii oba tunele są osobno sprawdzane z tym samym przepływem aplikacji. Jedno ciągłe połączenie testowe pozostaje widoczne, a podczas testu zestawia się również nowe sesje.

W oknie serwisowym w kontrolowany sposób przerywa się wyłącznie ścieżkę ISP1. Nie należy wyłączać jednocześnie obu portów WAN ani obu tuneli. Test odpowiada na cztery pytania:

1. Czy gateway ISP1 zostaje rozpoznany jako niedostępny?
2. Czy aktywuje się trasa z Administrative Distance 2 przez XFRM ISP2?
3. Czy nowe połączenia docierają do peera, a odpowiedzi wracają przez ISP2?
4. Czy po przywróceniu ISP1 ponownie używana jest trasa z Administrative Distance 1?

W Log Viewer i precyzyjnym Packet Capture muszą zgadzać się oczekiwana Firewall Rule ID, aktywny interfejs XFRM i dwukierunkowy przepływ danych. Sam ping nie wystarcza. HTTPS, RDP, VoIP lub inna rzeczywista aplikacja pokazuje dodatkowo, czy działają zestawianie sesji, MTU i ścieżka powrotna. Artykuł Testowanie reguły firewalla za pomocą Log Viewer i Packet Capture wyjaśnia połączoną procedurę.

W klastrze HA po planowanym Failoverze testuje się nowe połączenie przez obie ścieżki ISP. Aktywny tunel nie gwarantuje, że istniejące sesje TCP lub stany routingu będą kontynuowane bez przerwy.

Systematyczne zawężanie błędów

Oba tunele są zielone, ale ISP2 nie przejmuje ruchu

Sprawdzić status gatewayów, Monitoring Target i obie trasy statyczne. Sieć docelowa i prefix muszą być identyczne, natomiast Next Hops i interfejsy XFRM muszą się różnić. Następnie porównać Administrative Distance i aktualną Route Precedence.

ISP2 przejmuje ruch, ale aplikacje nie odpowiadają

Sprawdzić reguły firewalla, wyjątki NAT i trasę powrotną po obu stronach. Packet Capture musi pokazać request i reply na XFRM ISP2. Jeśli brakuje tylko odpowiedzi, błąd zwykle znajduje się za peerem lub w asymetrycznej ścieżce powrotnej.

Failback przełącza zbyt wcześnie albo wcale

Obserwować Health Check i Monitoring Target. Cel nie może okresowo zgłaszać zdrowego tunelu, gdy ścieżka aplikacji jest jeszcze zakłócona. Wspólnie sprawdzić Administrative Distance, aktywną trasę i rzeczywiście nową sesję; istniejące połączenia mogą pozostać związane z poprzednim stanem.

Działa tylko jeden kierunek

Porównać lustrzaną konfigurację: adres XFRM, gateway, trasa statyczna, reguła i ścieżka powrotna muszą istnieć na obu firewallach. strongswan.log i xfrmi.log pomagają na warstwach IKE i XFRM; artykuł Rozwiązywanie problemów z VPN IPsec wyjaśnia bezpieczną diagnostykę.

Bezpieczny rollback

Przed zmianą dokumentuje się backup, pierwotną Route Precedence, stan tuneli, adresy XFRM, gatewaye, reguły i trasy. Jeśli ścieżka redundantna nie działa niezawodnie:

1. Wyłączyć nowe trasy Backup.
2. Wyłączyć gatewaye ISP2 i drugi tunel zamiast od razu je usuwać.
3. Przywrócić pierwotną Route Precedence na obu firewallach.
4. Przywrócić reguły i NAT do udokumentowanego poprzedniego stanu.
5. Ponownie przetestować pierwotną ścieżkę ISP1 za pomocą nowej sesji aplikacji.

Adresy XFRM, gatewaye lub tunele usuwa się dopiero wtedy, gdy Object usage nie pokazuje już zależności. Backup i odtwarzanie Sophos Firewall wyjaśnia proces backupu i odzyskiwania.

FAQ