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 z SFOS 22.0 i opiera się na opisanym przez Sophos projekcie z dwoma łączami internetowymi. Tunele policy-based oraz route-based z konkretnymi Traffic Selectors korzystają zamiast tego z grupy failover IPsec.

⚠️ Aktualna pomoc Sophos jest sprzeczna w kwestii dwóch połączeń Any-to-Any. Dedykowana instrukcja dla dwóch ISP tworzy dwa tunele bez grupy failover. Ogólne wskazówki diagnostyki IPsec stwierdzają natomiast, że wiele połączeń z identycznymi Local i Remote Subnets, w tym Any-Any, działa tylko w tej samej grupie failover. Grupa zmienia DPD i Failback, dlatego nie dodajemy tu nieudokumentowanego kroku: projekt należy przetestować na zainstalowanej wersji serwisowej SFOS 22, a odmienne zachowanie wyjaśnić z Sophos Support przed wdrożeniem produkcyjnym.

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ć dla obu adresów XFRM peera Custom Gateway ze świadomie dobranym Health Check.
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.

SFOS 22 dopuszcza trasy statyczne, SD-WAN lub dynamiczne dla interfejsów XFRM Any-to-Any. Dedykowana procedura dla dwóch ISP używa wyraźnie dwóch tras statycznych. Ta procedura stosuje ten projekt; nie należy dodawać trasy SD-WAN do tego samego celu bez osobnego zaprojektowania i przetestowania jej współdziałania oraz priorytetu.

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.

Na obu firewallach w Network > Interfaces rozwija się interfejs WAN używany dla danego połączenia IPsec. Pod nim znajdują się automatycznie utworzone interfejsy XFRM jako interfejsy podrzędne. Pozwala to powiązać każdy interfejs XFRM z tunelem przez ISP1 lub ISP2 przed przypisaniem mu adresu transferowego.

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.

Dla każdego gatewaya ustawić co najmniej Name, Gateway IP i Interface. Gateway IP to adres XFRM peera, a Interface to odpowiedni XFRM. Health check jest domyślnie wyłączony i trzeba go włączyć do monitorowania ścieżki. SFOS 22 pokazuje wtedy Interval (domyślnie 60 sekund), Time-out (2 sekundy), Retries (3) oraz co najmniej jedną Monitoring condition z Protocol, Port dla TCP i IP address.

Adres testowy musi należeć do hosta za gatewayem. Aby ocenić całą dalszą ścieżkę, należy wybrać stabilny, dozwolony endpoint za peerem. Ping tylko do adresu XFRM potwierdza jedynie bezpośredni odcinek. Warunki można łączyć przez AND lub OR: AND wymaga wszystkich odpowiedzi, a OR sprawdza cele od góry do pierwszej odpowiedzi.

Protokół, cel i interwały są decyzją operacyjną: cel musi odpowiadać stabilnie, pozostawać dostępny podczas zwykłych prac i mieć właściwe reguły dostępu. Wartości domyślne są punktem wyjścia, a nie gwarantowanym czasem przełączenia. Zmianę akceptuje się dopiero po pomiarze czasu wykrycia, Failover i Failback. Tworzenie i sprawdzanie Custom Gateway 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.

Dedykowana instrukcja Sophos przypisuje temu projektowi automatyczne Failover i Failback. Ogólna referencja tras statycznych potwierdza priorytet Administrative Distance, ale nie opisuje osobno, jak nieudany Health Check usuwa trasę z wyboru. Dlatego podczas odbioru trzeba obserwować aktywną trasę, nie tylko status gatewaya.

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.

Pomoc SFOS 22 podaje ogólną wartość domyślną static, sdwan_policyroute, vpn, natomiast dedykowana instrukcja wymaga static vpn sdwan_policyroute. Rollback musi więc odtworzyć dokładną kolejność zapisaną wcześniej przez show, a nie ślepo zastosować wartość domyślną.

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.

To coś innego niż NAT Traversal. Sophos Firewall automatycznie włącza NAT-T i przy wykryciu NAT używa UDP 4500; bez NAT IKE używa UDP 500, a ESP protokołu IP 50. Jeśli firewall znajduje się za routerem nadrzędnym, jego DNAT i reguły dostępu muszą prowadzić do właściwego Listening Interface na obu ścieżkach ISP. Nakładające się sieci lokalizacji wymagają natomiast odpowiednich reguł SNAT i DNAT dla ruchu użytkowego.

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. SFOS 22 bezproblemowo odtwarza tunele route-based IPsec, ale ogranicza przejęcie sesji ruchu w tunelu do protokołów bezstanowych, takich jak UDP i ICMP; TCP nie jest obsługiwany. Osobno ocenia się istniejące i nowe połączenie TCP. Logi i raporty HA pozostają tylko na węźle, który przetwarzał ruch, więc trzeba sprawdzić oba urządzenia.

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. Aktualna diagnostyka Sophos wskazuje /log/strongswan.log, /log/charon.log, /log/strongswan-monitor.log i /log/dgd.log; ostatni zawiera zdarzenia Dead Gateway Detection i VPN Failover. W Advanced Shell polecenie tylko do odczytu ip xfrm state pokazuje, czy istnieją Transform States. Rozwiązywanie problemów z VPN IPsec wyjaśnia bezpieczną diagnostykę.

Status tunelu i gatewaya są sprzeczne

DPD i Gateway Health Check mierzą różne elementy. Dead Peer Detection konfiguruje się w Profiles > IPsec profiles i wykrywa nieodpowiadającego peera IKE po bezczynności tunelu Phase 2; Sophos zaleca włączenie DPD. Health Check Custom Gateway sprawdza wybrany host za ścieżką XFRM. Nie należy wyłączać DPD, aby ukryć wadliwy cel testowy. Jeśli Sophos Support zażąda grupy failover z powodu powyższego konfliktu dokumentacji, trzeba pamiętać, że grupa wyłącza DPD w profilu, ustawia Key negotiation tries na 3 i dodaje własny Automatic failback z maksymalnie pięcioma próbami. To inny model operacyjny, którego nie wolno mieszać z tą procedurą bez osobnego odbioru.

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