Konfiguracja i test grupy failover IPsec w Sophos Firewall

Grupa failover IPsec ustawia kilka połączeń Site-to-Site IPsec według priorytetu. Jeśli tunel podstawowy przestanie działać, Sophos Firewall aktywuje następne dostępne połączenie. Przełączenie pomoże jednak tylko wtedy, gdy oba tunele działają już osobno i obejmują te same sieci produkcyjne, reguły, założenia NAT oraz drogi powrotne.

Skrócony przebieg: Przetestować osobno dwa połączenia IPsec, sprawdzić Remote IDs i kolejność, połączyć je w grupę w Site-to-site VPN > IPsec > Failover group, wybrać odpowiednią Failover condition, a następnie odebrać failover i failback przy użyciu stałego przepływu testowego.

Przewodnik zakłada istniejącą konfigurację Site-to-Site IPsec. Wyjaśnia sterowanie redundancją, a nie ponownie całą konfigurację tunelu.

Kiedy stosować grupę failover IPsec

Grupa pasuje przede wszystkim do policy-based IPsec oraz route-based IPsec z konkretnymi Traffic Selectors. Kilka połączeń z identycznymi Local i Remote subnets musi należeć do wspólnej grupy failover albo używać jednoznacznie różnych selektorów. W przeciwnym razie tunele mogą wzajemnie na siebie wpływać.

W przypadku route-based Any-to-Any decyzja wygląda inaczej: interfejsy XFRM otrzymują adresy transferowe, a ścieżkę danych wyznaczają trasy statyczne, dynamiczne lub SD-WAN Routes. Wiele gatewayów XFRM można tam priorytetyzować bezpośrednio przez SD-WAN Profile i kontrole SLA. Dodatkowa grupa failover VPN nie jest wtedy potrzebna.

Zwykły failover WAN również nie zastępuje grupy. WAN link manager może zmienić łącze internetowe, ale nie tworzy drugiego połączenia IPsec z własnym Gateway Address, Listening Interface i konfiguracją strony zdalnej.

FQDN z wieloma adresami WAN nie jest mechanizmem failover

Jeśli ten sam rekord DNS A wskazuje jednocześnie podstawowy adres WAN i adres aktywny tylko podczas awarii, zdalna strona może wybrać adres nieaktywny. DNS round robin nie zna ani stanu WAN, ani stanu tunelu. Lokalna grupa failover IPsec nie koryguje automatycznie tego zdalnego wyboru DNS.

Dla tuneli inicjowanych przez stronę zdalną potrzebne są zatem dwie jawnie skonfigurowane połączenia albo FQDN, którego DNS zależny od stanu lub aktualizacja DDNS wskazuje wyłącznie aktualnie osiągalny adres. Jeśli nie można kontrolować ani konfiguracji strony zdalnej, ani aktualizacji DNS, projekt należy w tym miejscu zatrzymać. Dwóch jednocześnie publikowanych adresów nie wolno uznawać za przetestowany failover.

Grupa failover VPN nie jest też tym samym co klaster HA. Grupa przełącza tunele, natomiast HA przełącza dwa węzły firewall. W środowisku krytycznym trzeba więc osobno zaplanować i przetestować awarie WAN, VPN oraz możliwe awarie HA.

Co monitoruje grupa

Sophos Firewall sprawdza stronę zdalną za pomocą Failover condition grupy. Interwał pochodzi z globalnej wartości Gateway failover time-out w:

Network > WAN link manager

Ta sama wartość wpływa również na ogólne monitorowanie gatewayów WAN. Nie należy jej więc zmieniać wyłącznie z myślą o pojedynczym tunelu VPN. Krótka wartość reaguje szybciej, ale przy chwilowej utracie pakietów może niepotrzebnie przełączyć połączenie. Długa wartość dłużej toleruje zakłócenia, lecz wydłuża awarię przed przełączeniem.

Health Check potwierdza jedynie, że zdalna strona odpowiada na wybrany warunek ping lub TCP. Nie dowodzi, że działają DNS, aplikacja biznesowa, NAT, routing i pełna droga powrotna. Elementy te testuje się oddzielnie po przełączeniu.

Przygotowanie dwóch tuneli do grupy

W poniższym przykładzie dwa tunele łączą centralę z oddziałem:

• centrala: 10.10.0.0/16
• oddział: 10.20.0.0/16
• połączenie podstawowe: HQ-Branch-ISP1
• połączenie zapasowe: HQ-Branch-ISP2
• podstawowy adres strony zdalnej: 198.51.100.20
• zapasowy adres strony zdalnej: 203.0.113.20
• wspólny Remote ID oddziału: 10.255.255.2
• grupa failover: HQ-Branch-Zurich

Adresy 198.51.100.0/24 i 203.0.113.0/24 są sieciami dokumentacyjnymi i zastępuje się je prawdziwymi publicznymi adresami stron zdalnych. Sieci, nazwy i Remote ID są również wartościami przykładowymi. Najważniejsza jest zasada: Gateway addresses mogą być różne, ale adres IP Remote ID musi być taki sam dla wszystkich członków grupy. Po drugiej stronie ten Remote ID musi każdorazowo odpowiadać Local ID.

Przed zgrupowaniem należy sprawdzić każde połączenie osobno:

1. Oba połączenia są aktywne w Site-to-site VPN > IPsec.
2. Każde połączenie można zestawić oddzielnie i przenosi ten sam ustalony przepływ testowy.
3. Local i Remote subnets lub Traffic Selectors są lustrzanym odbiciem ustawień drugiej strony.
4. Reguły firewall zezwalają na wymagany ruch przez strefę VPN w obu kierunkach.
5. NAT jest na obu ścieżkach taki sam i świadomie skonfigurowany.
6. Strona zdalna zna drogę powrotną przez oba tunele.
7. Profile odpowiadają danej stronie zdalnej. Artykuł Profile IPsec na Sophos Firewall wyjaśnia znaczenie DPD, rekeyingu i lifetimes.
8. Dostępna jest alternatywna ścieżka administracyjna i okno serwisowe.

⚠️ Dodanie połączenia do grupy failover przerywa już zestawione połączenia. Nie należy wprowadzać tej zmiany podczas nienadzorowanej sesji zdalnej ani bez przetestowanej drogi wycofania.

Połączenie może należeć tylko do jednej grupy failover. Dopóki jest przypisane do grupy, nie można go usunąć. Połączenia Remote Access IPsec nie mogą być członkami grupy.

Wybór odpowiedniej Failover condition

Sophos obsługuje ping lub TCP ze zdefiniowanym portem. Warunek należy świadomie dopuścić na obu firewallach:

• Ping: łatwy do sprawdzenia, ale wymaga Ping/Ping6 dla strefy WAN w Administration > Device access. Przy stałych adresach stron zdalnych wąska Local Service ACL Exception jest lepsza niż niepotrzebnie szerokie zezwolenie. Bezpieczną konfigurację opisuje Device Access i Local Service ACL.
• TCP 22: wymaga SSH przez strefę VPN. Nie należy w tym celu otwierać SSH w WAN. Usługa administracyjna nie jest dobrym ogólnym Health Checkiem, jeśli miałaby zostać wystawiona wyłącznie do monitorowania.
• Inny port TCP: wymaga odpowiednich przychodzących i wychodzących reguł firewall. Usługa musi być stale dostępna i nie może zależeć wyłącznie od stanu przypadkowej aplikacji.

Warunek powinien odzwierciedlać stabilnie dostępną usługę odpowiedzi lub ścieżkę strony zdalnej. Jeśli usługa TCP nie odpowiada z powodu konserwacji, lokalnej awarii lub host firewalla, grupa może się przełączyć, mimo że sama ścieżka IPsec nadal jest dostępna.

Konfiguracja grupy failover IPsec

Ścieżka menu:

Site-to-site VPN > IPsec > Failover group > Add

1. W polu Name wpisać jednoznaczną nazwę, w przykładzie HQ-Branch-Zurich.
2. W Member connections wybrać co najmniej dwa aktywne połączenia Site-to-Site IPsec.
3. Ustawić połączenia w żądanej kolejności: najpierw HQ-Branch-ISP1, następnie HQ-Branch-ISP2. Pierwsze połączenie jest tunelem podstawowym.
4. Włączyć Mail notification, jeśli przełączenie tunelu ma być zgłaszane e-mailem. Wcześniej muszą działać Notification settings i powiadomienia VPN.
5. Włączyć Automatic failback, jeśli po przywróceniu grupa ma wrócić do preferowanego tunelu.
6. Ustawić odpowiednią Failover condition z ping lub TCP i portem.
7. Zapisać przez Save.
8. Włączyć przełącznik stanu grupy. Dopiero wtedy grupa staje się aktywna i próbuje zestawić połączenie podstawowe.

W przypadku dwóch urządzeń Sophos Firewall po obu stronach sprawdza się właściwości połączeń, kolejność członków, Remote IDs i zezwolenia Health Check. Poprawna grupa tylko po jednej stronie nie zastępuje odpowiedniej konfiguracji strony zdalnej.

Co dzieje się z DPD i Key negotiation tries

Gdy połączenie staje się członkiem grupy, SFOS wyłącza dla niego Dead Peer Detection i efektywnie ustawia Key negotiation tries na 3. Monitorowanie przejmuje Failover condition. Dlatego same wartości w widoku profilu nie pokazują pełnego efektywnego zachowania.

Po usunięciu z grupy połączenie ponownie korzysta z wartości DPD i Key negotiation przypisanego profilu IPsec. Jest to ważne przy rollbacku: po rozwiązaniu grupy tunel może zachowywać się inaczej, mimo że sam profil nie został zmieniony.

Kontrolowany test failover i failback

Przed testem awarii należy zdefiniować konkretny przepływ danych, na przykład:

• Source: 10.10.10.25
• Destination: 10.20.20.15
• Service: TCP 443
• oczekiwana reguła firewall: HQ-to-Branch-HTTPS

Następnie przeprowadzić test w jasnej kolejności:

1. Udokumentować stan grupy, kolejność członków, build firmware i Gateway failover time-out.
2. Sprawdzić tunel podstawowy po obu stronach w WebAdmin. Rzeczywistym ruchem HTTPS potwierdzić działanie drogi w obie strony.
3. Zapisać stan w Advanced Shell za pomocą ipsec statusall.
4. W oknie serwisowym w kontrolowany sposób przerwać podstawową ścieżkę WAN lub upstream. Nie wyłączać całej grupy failover, ponieważ dezaktywuje to wszystkie aktywne tunele grupy.
5. Obserwować dłużej niż skonfigurowany Gateway failover time-out i zanotować moment przełączenia.
6. Sprawdzić, czy zestawiany jest HQ-Branch-ISP2 i czy ten sam test HTTPS działa w obu kierunkach.
7. Skontrolować regułę firewall, NAT, drogę powrotną i działanie aplikacji. Sam zielony tunel nie jest kryterium sukcesu.
8. Przywrócić ścieżkę podstawową i obserwować Automatic failback.
9. Po przełączeniu z powrotem powtórzyć ten sam test i udokumentować rzeczywisty zmierzony czas przerwy.

Istniejące sesje TCP mogą zostać przerwane podczas zmiany. Nowy tunel ma inne Security Associations i może korzystać z innego publicznego adresu. Aplikacja często musi więc zestawić nową sesję. Failover IPsec zwiększa dostępność, ale nie gwarantuje nieprzerwanej sesji.

Automatic failback kończy się po pięciu nieudanych próbach

Gdy podstawowa strona zdalna jest ponownie osiągalna, SFOS przy włączonym Automatic failback próbuje do pięciu razy odtworzyć preferowane połączenie. Jeśli się to nie uda, tunel zapasowy pozostaje aktywny. Firewall nie sprawdza potem tunelu podstawowego bez końca; kolejny powrót następuje dopiero po awarii ścieżki zapasowej.

Grupę można ręcznie wyłączyć i ponownie włączyć, aby jeszcze raz zainicjować zestawianie połączenia podstawowego. Powoduje to jednak downtime i nie jest nieszkodliwym przełącznikiem odświeżania. Najpierw należy sprawdzić logi, stronę zdalną, profil, identyfikatory i ścieżkę.

Odczyt logów bez zmian konfiguracji

Dla decyzji grupy istotny jest dgd.log, a dla właściwego zestawiania IPsec — strongswan.log. Poniższe polecenia wykonuje się w Advanced Shell i nie zmieniają konfiguracji:

tail -n 200 /log/dgd.log
tail -n 200 /log/strongswan.log
ipsec statusall

W razie potrzeby uzupełnić analizę o charon.log, ipsec_monitor.log i log akcji konkretnego połączenia. W ostatnim wierszu zastąpić HQ-Branch-ISP1 rzeczywistą nazwą połączenia:

tail -n 200 /log/charon.log
tail -n 200 /log/ipsec_monitor.log
tail -n 200 /log/ipsec_conn/ipsec_HQ-Branch-ISP1.log

Porównać znaczniki czasu z dgd.log, status IPsec, zdarzenie WAN i test aplikacji. Nieudany Health Check bez odpowiadającego błędu tunelu lub aplikacji nie dowodzi jeszcze awarii operatora. Pełną ścieżkę diagnostyczną opisuje Rozwiązywanie problemów z IPsec VPN na Sophos Firewall.

Typowe błędy i bezpieczny powrót

Grupy nie można poprawnie aktywować

Należy wybrać co najmniej dwa aktywne połączenia. Sprawdzić, czy połączenie nie należy już do innej grupy, nie zostało utworzone jako Remote Access albo nie używa odmiennego Remote ID. Następnie ponownie przetestować oba tunele osobno przed aktywacją grupy.

Tunel zapasowy jest zielony, ale ruch nie działa

Logika grupy prawdopodobnie zadziałała, lecz ścieżka danych nie. Sprawdzić reguły firewall, NAT, Local i Remote subnets, trasy automatyczne lub ręczne oraz drogę powrotną po stronie zdalnej. Tunel zapasowy musi obsługiwać ten sam produkcyjny przepływ testowy co tunel podstawowy.

Grupa przełącza się zbyt wcześnie lub zbyt późno

Sprawdzić razem Failover condition i Gateway failover time-out. Niestabilny cel ping lub TCP może powodować niepotrzebne przełączenia. Długi globalny timeout opóźnia natomiast także inne zależne kontrole gatewayów. Nie należy zmieniać wyłącznie liczby, lecz udokumentować przyczynę, utratę pakietów i rzeczywisty czas przełączenia.

Kolejność jest nieprawidłowa po drag-and-drop

Sophos potwierdza dla SFOS 22.0 GA błąd NC-178121: po zmianie drag-and-drop połączenia Site-to-Site IPsec mogły znaleźć się w nieprawidłowej pozycji w grupie failover. Ten konkretny błąd naprawiono w SFOS 22.0 MR2 Build 546.

W SFOS 22.0 GA należy dokumentować kolejność przed każdą zmianą i po niej, nie polegając wyłącznie na wizualnym przesunięciu. Publiczne informacje o wersji nie określają dla MR1 jednoznacznej osobnej granicy wersji podatnych ani wersji z poprawką. Podobnego błędu w MR2 Build 546 lub nowszym nie wolno więc automatycznie nadal przypisywać do NC-178121.

Wycofanie grupy

Wyłączenie grupy failover dezaktywuje aktywne tunele jej członków. Potrzebne pojedyncze połączenia należy potem ponownie aktywować oddzielnie. Kontrolowany rollback:

1. Zapisać stan początkowy, kolejność członków i używane profile.
2. Potwierdzić okno serwisowe i alternatywną ścieżkę administracyjną.
3. Wyłączyć grupę i udokumentować przerwę.
4. Usunąć połączenia z grupy lub przywrócić pierwotne przypisanie.
5. Aktywować wymagane pojedyncze połączenie.
6. Ponownie uwzględnić zachowanie DPD i Key negotiation z profilu.
7. Sprawdzić ten sam przepływ testowy, logi i drogę powrotną.

Eksploatacja

• Ponownie testować failover i failback po zmianach firmware, operatora, strony zdalnej, routingu, NAT lub profilu.
• Dokumentować kolejność członków, Remote IDs, profile, warunek Health Check i globalny timeout.
• Traktować Mail notification wyłącznie jako powiadomienie; odbiór techniczny nadal opiera się na statusie, logach i rzeczywistym ruchu.
• Oba tunele objąć monitoringiem, planem konserwacji i dokumentacją strony zdalnej.
• Sprawdzić, czy zapasowy operator spełnia te same wymagania dotyczące allowlist, zależności NAT i dostępności publicznej.
• Ręcznie wyłączać i włączać grupę wyłącznie z zaplanowaną przerwą.

FAQ