Konfiguracja High Availability (HA) Sophos Firewall

High Availability, w skrócie HA, łączy dwie zapory Sophos w klaster. W większości środowisk najlepszym wyborem jest Active-Passive z QuickHA: jedna zapora obsługuje ruch, a druga przejmuje pracę w razie awarii lub konserwacji. Przed rozpoczęciem trzeba dopasować oba urządzenia, build firmware, licencje, okablowanie i dostęp administracyjny.

Ten artykuł prowadzi od wyboru trybu HA przez konfigurację aż po test failover, eksploatację i RMA. HA nie zastępuje prawidłowego projektu sieci ani kopii zapasowych.

Wybór trybu i architektury HA

Rekomendacja operacyjna Avanet: w większości środowisk produkcyjnych lepszym wariantem HA jest Active-Passive. Jedna zapora obsługuje cały ruch, a druga pozostaje gotowa do przejęcia pracy w razie awarii lub konserwacji. Projekt jest prostszy, licencjonowanie tańsze, a zachowanie podczas awarii łatwiejsze do prześledzenia. Jest to zalecenie projektowe, a nie wymóg Sophos.

Active-Active ma sens tylko wtedy, gdy świadomie akceptuje się jego ograniczenia. Nie jest to klasyczne symetryczne równoważenie obciążenia, w którym obie zapory są równorzędne w całej sieci. Primary Firewall nadal przyjmuje ruch i przekazuje wybrane połączenia do Auxiliary Firewall. Nie każdy rodzaj ruchu i nie każda usługa są rozdzielane.

Szybkie wskazówki:

• Maksymalna stabilność i prosta eksploatacja: Active-Passive.
• Druga zapora bez oddzielnej licencji ochronnej: Active-Passive.
• Potrzebna większa przepustowość dla określonych połączeń TCP: rozważyć Active-Active.
• Wiele przypadków VPN, proxy, RED, NDR lub rozwiązań specjalnych: preferować Active-Passive.
• Małe lub średnie środowisko bez wyraźnego problemu wydajności: Active-Passive.
• Jasne wymagania wydajnościowe i odpowiednie licencje dla obu urządzeń: Active-Active po testach.

Poniższe dwa materiały Sophos Techvids pokazują konfigurację i zmianę ról:

Co oznacza High Availability

Klaster HA Sophos Firewall składa się z dwóch zapór. Urządzenia wymieniają przez dedykowane łącze HA sygnały Heartbeat, status urządzeń, informacje o połączeniach i dane konfiguracyjne. Konfiguracja jest synchronizowana z Primary Firewall do Auxiliary Firewall.

HA chroni przed typowymi awariami:

• awarią Primary Firewall
• awarią zasilania lub sprzętu
• awarią monitorowanego interfejsu
• problemem z oprogramowaniem lub usługą, który uniemożliwia pracę urządzenia
• planowanymi aktualizacjami firmware
• planowaną zmianą ról podczas konserwacji

HA nie rozwiązuje jednak każdego problemu:

• Błędny zestaw reguł firewall pozostaje błędny również w klastrze.
• Awaria wspólnego przełącznika może jednocześnie dotknąć obie zapory.
• Wadliwy projekt VLAN lub routingu nie zostanie automatycznie naprawiony.
• Logi i raporty nie są w pełni synchronizowane między zaporami.
• Kopia zapasowa nadal jest obowiązkowa.

Przed planowaniem HA trzeba uporządkować podstawy dotyczące stref, interfejsów, VLAN, LAG i mostów. Pomaga w tym artykuł Planowanie i konfiguracja stref oraz interfejsów Sophos Firewall.

Active-Passive czy Active-Active

Active-Passive

W trybie Active-Passive jedna zapora obsługuje cały ruch produkcyjny. Druga pozostaje pasywna i przejmuje pracę dopiero wtedy, gdy aktywna zapora ulegnie awarii albo failover zostanie uruchomiony ręcznie lub w ramach konserwacji.

Typowe właściwości:

• Primary Firewall obsługuje ruch.
• Auxiliary Firewall pozostaje w trybie standby.
• Sesje są synchronizowane, o ile obsługuje to dany protokół i usługa.
• W przypadku urządzeń sprzętowych licencji ochronnych wymaga tylko urządzenie posiadające licencję.
• Gdy używany jest wirtualny MAC klastra, po failover Auxiliary Firewall przejmuje ten sam wirtualny adres MAC.
• W tym przypadku urządzenia sieciowe zwykle nie muszą ponownie uczyć się sąsiadów.

Active-Passive jest zazwyczaj najlepszym wyborem dla klasycznych środowisk firmowych, oddziałów, centrów danych i wszędzie tam, gdzie stabilność jest ważniejsza od potencjalnego wzrostu wydajności.

Active-Active

W trybie Active-Active obie zapory obsługują ruch. Architektura pozostaje jednak asymetryczna: Primary Firewall przyjmuje ruch i decyduje, czy przetworzyć połączenie samodzielnie, czy przekazać je do Auxiliary Firewall.

Sophos wykorzystuje do dystrybucji źródłowy adres IP: połączenia TCP z parzystych adresów źródłowych zwykle obsługuje Primary, a połączenia z nieparzystych adresów trafiają do Auxiliary. Rozdzielane są przekazywane lub translacjonowane połączenia TCP, także przez interfejsy VLAN. Po przetworzeniu połączenia Auxiliary wysyła pakiety bezpośrednio do miejsca docelowego, bez powrotu przez Primary. Ta metoda parzysta-nieparzysta jest stała i nie można jej zmienić. Ruch inny niż TCP, SD-RED, ruch tunelowany oraz połączenia Layer 7 przez DPI lub proxy, w tym SMTP Proxy, HTTPS, skanowany FTP i H.323, nie są rozdzielane. Sophos nie obsługuje zewnętrznych load balancerów przed klastrem dla tej logiki HA.

Oba węzły wymagają odpowiednich licencji i lokalnie zapisują logi obsługiwanego ruchu. Active-Active ma więc sens tylko przy jasno określonym celu wydajnościowym i potwierdzeniu, że odpowiedni ruch rzeczywiście jest rozdzielany. Dla samej wysokiej dostępności Active-Passive jest zwykle lepszym rozwiązaniem.

Role, status i failover

Role w klastrze HA

• Primary: urządzenie prowadzące centralną konfigurację klastra. W obu trybach HA Primary przyjmuje ruch.
• Auxiliary: drugie urządzenie w klastrze. Synchronizuje konfigurację z Primary i w razie potrzeby przejmuje pracę.
• Initial primary: urządzenie uruchomione podczas konfiguracji jako Primary. W Active-Passive zwykle jest też urządzeniem posiadającym licencję. Ta rola właściciela pozostaje bez zmian niezależnie od tego, czy węzeł jest obecnie Active, czy Passive.
• Preferred primary: preferowane urządzenie, które po failover ma ponownie zostać Primary, gdy będzie stabilnie dostępne.

W trybie Active-Passive WebAdmin na Auxiliary nie pokazuje Live users, DHCP leases ani aktywnych połączeń IPsec. Jest to oczekiwane zachowanie, a nie dowód błędu synchronizacji. Dla tych danych czasu rzeczywistego miarodajna jest aktualnie aktywna Primary.

Statusy podczas pracy

• Active: urządzenie obsługuje ruch.
• Passive: urządzenie jest gotowe, ale w Active-Passive nie obsługuje ruchu produkcyjnego.
• Standalone: urządzenie nie widzi drugiego węzła lub HA nie jest w pełni aktywne. Przy problemach z łączem HA oba urządzenia mogą przejść w stan Standalone.
• Faulty: urządzenie nie jest wystarczająco sprawne, aby normalnie uczestniczyć w klastrze.

Wirtualny adres MAC

Gdy używany jest wirtualny MAC klastra HA, interfejsy produkcyjne korzystają z wirtualnych adresów MAC. Tylko Primary odpowiada na zapytania ARP dotyczące klastra. Po failover Auxiliary przejmuje wirtualny adres MAC. Dzięki temu dostępność dla przełączników, routerów i klientów pozostaje stabilniejsza, ponieważ przypisanie IP i MAC zasadniczo się nie zmienia. Opisana poniżej opcja MAC interfejsu jest innym wariantem; nie należy zakładać takiego samego przejmowania wirtualnego MAC.

Ważna jest Cluster ID. Jest ona używana do tworzenia wirtualnego adresu MAC. Jeśli w tej samej domenie Layer 2 działa kilka klastrów HA, każdy musi mieć unikatową Cluster ID. W przeciwnym razie mogą wystąpić konflikty MAC.

Co jest synchronizowane

• Reguły firewall, Policies, obiekty, routing i konfiguracja CLI są synchronizowane z Primary do Auxiliary.
• Aktywne sesje są synchronizowane zależnie od protokołu i usługi.
• Secure Storage Master Key i dane dostępowe WebAdmin są synchronizowane.
• Dedicated HA link nie jest synchronizowany jak zwykła konfiguracja interfejsu produkcyjnego.
• Peer Admin Port jest obsługiwany oddzielnie i nie jest synchronizowany jak zwykły interfejs.
• Logi i raporty nie są synchronizowane między urządzeniami.

Zachowanie podczas failover

Failover może zostać wywołany przez różne zdarzenia:

• brak Heartbeat przez łącze HA
• awarię monitorowanego portu
• utratę zasilania
• awarię sprzętu
• problem z oprogramowaniem lub usługą
• planowaną zmianę ról
• aktualizację firmware

Jeśli pojedynczy Node uruchamia się w trybie Failsafe, najpierw dokumentuje się jego rolę i stan peera. Diagnostyka Sophos Firewall w trybie Failsafe pokazuje polecenie diagnostyczne tylko do odczytu i wyjaśnia, dlaczego nie należy bez koordynacji restartować obu Nodes ani wyłączać HA na próbę.

Sygnały Heartbeat przez Dedicated HA Link są żądaniami VRRP. SFOS 22 domyślnie używa 250 ms i 16 utraconych heartbeatów, co daje timeout heartbeat wynoszący 4 sekundy. SFOS 23 domyślnie używa 100 ms i 3 prób, co daje 300 ms; łącza HA oparte na LAG wymagają innych wartości, opisanych poniżej. Te timeouty nie gwarantują czasu przywrócenia ruchu. W przypadku Monitored Ports wystarczy natomiast awaria jednego portu, aby urządzenie zostało uznane za niedostępne i nastąpił failover.

Po failover WebAdmin na dotychczasowej Auxiliary Firewall pokazuje konfigurację Primary. Dla aktywnych sesji obowiązują różne ograniczenia:

Gdy Initial Primary wróci, pozostaje Auxiliary, jeśli nie wybrano Preferred primary. Jeśli jest Preferred primary, SFOS najpierw synchronizuje usługi, a następnie automatycznie przełącza role z powrotem. Urządzenie, które do tej pory działało samodzielnie, uruchamia się ponownie podczas tego procesu. Ten failback należy więc zaplanować w oknie serwisowym, mimo że klaster zasadniczo pozostaje dostępny podczas operacji.

Obsługiwane i ograniczone usługi

Sophos HA obsługuje większość usług firewall, ale ich ograniczenia operacyjne znacznie się różnią:

Jeśli ważne są raportowanie lub retencja logów, trzeba wcześnie zaplanować zewnętrzny serwer Syslog albo Sophos Central Firewall Reporting. Więcej informacji zawiera artykuł Włączanie Central Firewall Reporting.

Konfigurację, ograniczenia bezpieczeństwa i testy opisuje artykuł Konfigurowanie mDNS reflector. Wykrywanie usług nie przyznaje dostępu do aplikacji; obsługa HA nie gwarantuje nieprzerwanych sesji aplikacji. Ta informacja o mDNS dotyczy SFOS 23, nie SFOS 22.

Wymagania i projekt sieci

Przed wdrożeniem trzeba dokładnie porównać wymagania HA z własnym środowiskiem. Szczególnie zgodność modeli, wersja firmware, interfejsy, Cellular WAN i platformy wirtualne mogą mieć duży wpływ nawet przy niewielkich różnicach.

Zgodność sprzętu i modeli

• Model urządzenia: obie zapory muszą być tym samym modelem urządzenia XGS Appliance, na przykład XGS 2100 z XGS 2100.
• Rewizja sprzętowa: różne rewizje sprzętowe są możliwe przy tym samym modelu urządzenia XGS Appliance.
• Modele urządzeń XGS Appliance z Wi-Fi: nie są obsługiwane, na przykład XGS 126w i XGS 136w.
• Flexi Port Module: jeśli używane są moduły rozszerzeń, ich liczba i model muszą być takie same na obu urządzeniach.
• Firmware: oba urządzenia muszą używać tej samej wersji SFOS, w tym Maintenance Release i build.
• Sprzęt i urządzenie wirtualne: nie mogą tworzyć pary HA.

Ważne: modułów Flexi Port nie można wymieniać podczas pracy. Aby je dodać, należy bezpiecznie wyłączyć obie zapory, zainstalować ten sam model modułu w obu urządzeniach i ponownie uruchomić oba urządzenia. Następnie nowe Flexi Ports należy skonfigurować wyłącznie na aktualnym Primary w Network > Interfaces. SFOS synchronizuje tę konfigurację portów z Auxiliary. Nie należy modyfikować tylko jednego węzła podczas pracy klastra.

SFOS 22 nie obsługuje już sprzętu XG ani SG Series. Przed migracją do SFOS 22 takie urządzenia trzeba zastąpić obsługiwanym urządzeniem XGS Appliance lub odpowiednią platformą wirtualną.

Urządzenia wirtualne i programowe

Urządzenia wirtualne lub programowe również muszą być dokładnie dopasowane.

• Platforma: ten sam typ urządzenia i ta sama platforma SFOS.
• Hypervisor: ten sam typ Hypervisor.
• Zasoby: taka sama liczba rdzeni CPU, porównywalne zasoby i taka sama liczba interfejsów sieciowych.
• Firmware: ta sama wersja SFOS wraz z build.
• Adresy MAC: w środowiskach wirtualnych opcja adresów MAC przypisanych przez hypervisor może być istotna, aby nie wymagać Promiscuous Mode. Jej zmiana powoduje jednak przerwę w działaniu.

Jeśli klaster używa wirtualnego adresu MAC generowanego przez SFOS, platforma wirtualizacyjna musi akceptować zmiany MAC. W VMware ESXi ustawić MAC Address Changes i Forged Transmits na Accept na vSwitch lub port group; grupy portów muszą dziedziczyć wartości vSwitch albo mieć odpowiednią konfigurację. W Hyper-V włączyć Enable MAC address spoofing na wszystkich wirtualnych kartach sieciowych obu zapór z wyjątkiem karty Dedicated HA Link. Alternatywnie wybrać Use host or hypervisor-assigned MAC address w SFOS 22 lub Use interface MAC address w SFOS 23; na urządzeniach wirtualnych obie opcje używają MAC przypisanego przez hypervisor, więc te zmiany platformy nie są potrzebne. Opcja SFOS 23 używa też MAC interfejsu na urządzeniach sprzętowych zamiast wirtualnego MAC klastra. Włączenie lub wyłączenie aktualizuje konfigurację interfejsów i powoduje przerwę w działaniu.

Wdrożenia w chmurze

W środowiskach chmurowych obowiązują dodatkowe wymagania platformy. Routing, interfejsy wirtualne, adresy IP, Security Groups, UDR i mechanizmy failover specyficzne dla chmury muszą odpowiadać danemu projektowi. Standardowego podejścia HA dla urządzeń nie można bez weryfikacji przenieść do Azure, AWS ani innych środowisk chmurowych.

Jeśli Sophos Firewall działa w chmurze, przed planowaniem HA trzeba sprawdzić aktualną dokumentację Sophos dla danej platformy oraz architekturę sieci chmurowej.

Gateway, Bridge i Discover/TAP

HA jest dostępne w trybie gateway i bridge. Tryb Discover lub TAP obsługuje wyłącznie Active-Passive. Jeśli co najmniej jeden węzeł pracuje w trybie discover, nie można utworzyć klastra Active-Active. Aktywny interfejs TAP blokuje również konfigurację Active-Passive. Wyłączyć interfejs TAP przez CLI na obu zaporach, utworzyć HA, a następnie włączyć TAP osobno na każdym węźle. TAP pozostaje aktywny także na pasywnej Auxiliary.

Licencjonowanie i rejestracja

Licencjonowanie HA różni się zależnie od platformy i trybu HA. Decydują trzy pytania: czy jest to sprzęt, czy Virtual/Software? Czy używany jest Active-Passive, czy Active-Active? Które urządzenie jest Initial Primary, czyli posiada licencję klastra? Przed wdrożeniem trzeba zestawić te informacje ze statusem licencji, numerami seryjnymi i trybem docelowym.

Najważniejsze zasady licencjonowania:

• Base Firewall: HA wymaga licencji Base Firewall. Urządzenia sprzętowe mają ją standardowo, ale licencja kończy się wraz z End of Life urządzenia. Na urządzeniach cloud, wirtualnych i programowych Base Firewall nie wygasa, ale musi być obecna dla HA.
• Sprzęt w Active-Passive: tylko Initial Primary wymaga produkcyjnych subskrypcji. Auxiliary Firewall otrzymuje kopię subskrypcji i po failover może obsługiwać ruch.
• Sprzęt w Active-Active: obie zapory wymagają własnych odpowiednich licencji. Typy licencji muszą być zgodne, ale daty wygaśnięcia mogą się różnić.
• Active-Passive Virtual/Software: tylko Primary wymaga potrzebnych licencji, w tym Base Firewall.
• Active-Active Virtual/Software: oba urządzenia wymagają własnej Base Firewall i odpowiednich dodatkowych licencji ochronnych.
• Rejestracja sprzętu: przed konfiguracją HA oba urządzenia sprzętowe muszą zostać przypisane do konta Sophos Fusion (dawniej Sophos Central) i mieć możliwość synchronizacji licencji.
• Rejestracja Virtual/Software Active-Passive: według Sophos w Active-Passive Virtual/Software do konta przypisywana jest tylko Primary.
• Sophos Central Management: synchronizacja licencji i przypisanie urządzeń do konta nie oznaczają automatycznie zarządzania przez Sophos Central Firewall Management. Wymaga ono odpowiedniej dodatkowej subskrypcji.
• RMA i wsparcie: Advance Hardware Replacement wymaga Enhanced Plus Support na Primary sprzętowego klastra Active-Passive. W Active-Active każde urządzenie wymaga Enhanced Support albo Enhanced Plus Support.

Zarządzanie parą HA w Sophos Fusion

Istniejąca para HA jest zarządzana w Sophos Fusion jako jedna para, a nie jako dwie niezależne zapory. Oba węzły muszą mieć tę samą wersję firmware, a Central Management wymaga działającego dostępu do Internetu przez IPv4 i odpowiedniej subskrypcji. Samo przypisanie urządzeń i synchronizacja licencji nie włączają zarządzania.

Jeśli dwie zapory zarządzane już osobno w Sophos Fusion mają zostać połączone w parę HA, Sophos zaleca najpierw wyrejestrować obie. Utworzyć HA lokalnie, ponownie zarejestrować gotową parę do Central Management i w razie potrzeby przenieść ją do innej grupy Central.

Na aktualnym Primary otworzyć System > Sophos Central i wybrać Register both HA devices. Następnie włączyć Central Management, a w Sophos Fusion pod My Products > Firewall Management > Firewalls otworzyć przy Primary stan Approval Pending i potwierdzić accept-services. Po kilku minutach para powinna pojawić się jeden raz z ikoną HA; zmiany z Sophos Fusion dotyczą wtedy obu zapór.

Status w Central nie zastępuje lokalnej weryfikacji. Po rejestracji lokalnie sprawdzić role HA, synchronizację, stan licencji i nieszkodliwe porównanie konfiguracji. Jeśli pojawią się dwa niezależne wpisy lub pozostanie Approval Pending, nie wyrejestrowywać zapór zapobiegawczo. Najpierw porównać numery seryjne, tenant Central, ścieżkę IPv4 i lokalny stan HA.

Ważne: w Active-Passive Initial Primary jest szczególnie istotne, ponieważ posiada licencję klastra. W widoku HA odpowiednie urządzenie jest oznaczone jako posiadacz licencji klastra. W razie wątpliwości należy jednoznacznie udokumentować je w instrukcji eksploatacyjnej.

Licencja na niewłaściwej zaporze – tylko Active-Passive: Jeśli subskrypcje Active-Passive zostały omyłkowo przypisane do Auxiliary zamiast do Initial Primary posiadającego licencje, sama synchronizacja nie wystarczy. Należy zaplanować wyłączenie HA na aktualnym Primary, przenieść subskrypcje z Auxiliary do Primary w Sophos Fusion, a następnie ponownie skonfigurować klaster Active-Passive. Transfery licencji są istotne także przy RMA lub zmianie modelu, ale wymagają procedury właściwej dla konkretnego przypadku. Ponieważ modele w parze HA muszą być identyczne, przy zmianie modelu trzeba wymienić oba urządzenia. W Active-Active również Auxiliary musi posiadać własne licencje. Nie jest to błąd i nie należy tego korygować tym transferem. Nie stosować tej procedury Active-Passive do RMA Active-Active bez odpowiednich instrukcji Sophos.

Wygasłe lub niezsynchronizowane licencje Active-Active mogą zatrzymać równoważenie obciążenia i wyłączyć HA. Dla sprzętu oraz Virtual/Software Sophos opisuje początek zatrzymania sprzecznie: podsumowanie wskazuje koniec trzech dni, a szczegóły pierwsze trzy dni i późniejsze wyłączenie HA. Dokładny początek pozostaje nierozstrzygnięty; nie jest to gwarantowany trzydniowy okres karencji. Niezwłocznie skorygować problemy z licencjami i w razie potrzeby uzgodnić z Sophos Support bezpieczny plan eksploatacji dla zainstalowanego buildu. Podczas konfiguracji początkowej Active-Active nie zostanie aktywowane z niezgodnymi licencjami.

W Active-Passive synchronizować licencje Primary. Initial Primary posiadający licencje musi je synchronizować co najmniej raz w ciągu 90 dni. W przypadku sprzętu w przeciwnym razie zatrzymują się objęte tym ograniczeniem subskrypcje ochronne; Base Firewall i Enhanced Support pozostają aktywne. W Virtual/Software licencja Base Firewall zostaje wyłączona, HA dezaktywowane, a pozostałe funkcje ochronne stają się nieaktywne. Klastry licencjonowane online wymagają do tego DNS, prawidłowego czasu systemowego, routingu i dostępu do Internetu do usług licencyjnych Sophos. Klastry izolowane używają zamiast tego udokumentowanego ręcznego procesu licencjonowania Air-Gap.

W Active-Active, na sprzęcie oraz Virtual/Software, synchronizować licencje obu urządzeń osobno z Sophos Fusion i sprawdzić powodzenie na Primary oraz Auxiliary. Zgodne typy licencji i samo posiadanie licencji nie zastępują tego kroku. Na sprzęcie Base Firewall i Enhanced Support pozostają aktywne przy opisanych problemach z licencjami; w Virtual/Software dezaktywacja licencji Base Firewall wyłącza HA i dezaktywuje pozostałe licencje. Nie używać nierozstrzygniętej informacji o trzech dniach jako interwału synchronizacji.

W dokumentacji eksploatacyjnej trzeba co najmniej zapisać:

• które urządzenie jest Initial Primary
• jakie numery seryjne lub Appliance IDs należą do klastra
• które licencje są aktywne na poszczególnych urządzeniach
• kiedy ostatnio pomyślnie synchronizowano licencje; w Active-Active zapisać stan i czas oddzielnie dla obu węzłów
• jaki poziom wsparcia jest dostępny dla RMA lub Advance Replacement
• kto zatwierdza zmiany licencji, Renewals i procesy RMA

Wymagania sieciowe

• Łącze HA: dedykowane połączenie między zaporami, najlepiej bezpośrednim kablem Ethernet.
• Strefa łącza HA: strefa DMZ z włączonym SSH dla tej strefy.
• Adresy IP łącza HA: statyczne adresy w tej samej podsieci, ale różne.
• Jakość łącza HA: duża przepustowość, małe opóźnienia, brak utraty pakietów.
• Przełączniki: włączyć RSTP na przełącznikach połączonych z portami firewall.
• Monitored Ports: monitorować tylko porty rzeczywiście podłączone i krytyczne.
• Cellular WAN: wyłączyć dla HA.
• Peer Admin Port: zaplanować oddzielnie, aby Auxiliary Firewall pozostała dostępna.
• Adresy interfejsów: Active-Active wymaga statycznych adresów IP na wszystkich interfejsach. Active-Passive dopuszcza DHCP lub PPPoE, ale dla tych połączeń nie ma przejmowania sesji.

W Active-Passive interfejsy produkcyjne mogą używać DHCP, DHCP Prefix Delegation lub PPPoE, ale Dedicated HA Link i oba porty administracyjne nadal wymagają adresów statycznych. W Active-Active wszystkie interfejsy muszą mieć adresy statyczne.

Interfejsy breakout konfiguruje się na Primary. Najpierw uruchomić ponownie Primary, aby zastosować zmianę, a następnie Auxiliary. Jeśli na Primary nie ma odpowiedniej konfiguracji breakout, synchronizacja usuwa konfigurację breakout istniejącą tylko na Auxiliary.

Łącze HA nie obsługuje zwykłego ruchu klientów ani serwerów. Służy wyłącznie do Heartbeat, statusu, synchronizacji sesji i konfiguracji oraz dystrybucji Active-Active. Nie można go używać do HSRP, ponieważ komunikaty hello HSRP nie przechodzą przez Dedicated HA Link. Jest jednak krytyczne. Jeśli łącze HA przestanie działać, obie zapory mogą uznać się za Primary. Takiego scenariusza Split-Brain trzeba uniknąć.

Peer Admin Port jest oddzielnym dostępem administracyjnym do Auxiliary Firewall. Oba węzły używają tej samej sieci zarządzania. SFOS synchronizuje jednak zwykłą konfigurację interfejsu, łącznie z adresem IP PortMGMT, z Primary do Auxiliary, dlatego ten adres interfejsu nie może różnić się między węzłami. Oddzielne ustawienie Peer Administration przypisuje Auxiliary dodatkowy, inny adres administracyjny w tej samej podsieci. QuickHA automatycznie używa interfejsu bieżącej sesji WebAdmin. Po utworzeniu HA dostęp do Auxiliary jest możliwy tylko przez ten adres Peer Admin z odpowiedniej podsieci.

Domyślny adres zwykłych portów to 172.16.16.16, a dedykowany PortMGMT większych urządzeń używa 10.0.1.1. Primary jest dostępne z każdej strefy, w której HTTPS jest dozwolone pod Administration > Device access. Aby otworzyć WebAdmin Auxiliary, stacja administracyjna musi znajdować się w tej samej podsieci co jej port administracyjny.

Porty i interfejsy

• Dedicated HA link: służy do Heartbeat, statusu oraz synchronizacji konfiguracji i sesji. Należy połączyć go bezpośrednio albo przez bardzo niezawodny przełącznik. Nie używać do ruchu produkcyjnego.
• Monitored ports: monitorują krytyczne łącza produkcyjne. Należy monitorować WAN, ważne uplinki DMZ lub Core, ale nie wybierać nieużywanych portów.
• Peer Admin Port: zapewnia dostęp do WebAdmin Auxiliary. Trzeba go oddzielnie zaplanować i udokumentować; klient musi znajdować się w odpowiedniej podsieci.
• Interfejsy produkcyjne: LAN, WAN, DMZ, VLAN i LAG należy identycznie okablować i równoważnie zaprojektować na obu zaporach.

Jako Dedicated HA link można użyć interfejsów fizycznych, VLAN lub LAG. Bridge Interfaces i Alias IP nie mogą pełnić tej funkcji. QuickHA może połączyć maksymalnie cztery nieprzypisane interfejsy fizyczne w HA redundant link; przy skonfigurowanym LAG Parent Interfaces muszą być identyczne na obu urządzeniach.

W SFOS 23 Dedicated HA link wykorzystujący LAG lub VLAN na LAG wymaga Keepalive request interval × Keepalive attempts ≥ 2500 ms. Domyślna wartość konfiguracji SFOS 23, 100 ms × 3 = 300 ms, nie spełnia tego wymogu LAG i nie może być tutaj stosowana bez zmian. Dozwolony przykład to 250 ms × 10 prób = 2500 ms, a nie uniwersalna wartość domyślna. QuickHA tworzy HA redundant link jako LAG po wybraniu więcej niż jednego nieprzypisanego interfejsu fizycznego, więc wymóg dotyczy też tej topologii. Sprawdzić rzeczywistą konfigurację łącza. Nie zakładać automatycznego negocjowania odpowiednich wartości przez QuickHA; sprawdzić skonfigurowane wartości przed poleganiem na klastrze.

Porty wysokiej prędkości: Dla portów 25, 50 i 100 GbE w XGS 7500/8500 Series ustawić po obu stronach ten sam Link mode z jednakową prędkością i duplex pod Network > Interfaces > Advanced settings. Następnie użyć Show recommended settings > Load recommended configuration dla negotiation i Forward Error Correction (FEC). Jeśli zalecenia są puste, wyłączyć Auto-negotiation dla Media Type i FEC. Dla innych portów użyć Automatic lub identycznych wartości speed/duplex oraz pozostawić domyślne MTU i MSS. Gdy QuickHA wybiera nieprzypisany interfejs, SFOS resetuje jego Advanced settings; sprawdzić je ponownie po utworzeniu HA.

Ważne: Dedicated HA link i Monitored Port nie mogą być tym samym interfejsem. Jeśli interfejs jest już używany w konfiguracji produkcyjnej, a mimo to zostanie wybrany jako łącze HA, zapora może zmienić lub usunąć zależne konfiguracje interfejsu. Dlatego łącze HA powinno być wcześniej zwolnione i udokumentowane.

Projekt sieci

Obie zapory muszą w razie awarii przejąć tę samą pozycję w sieci. Interfejsy produkcyjne, VLAN Trunks, LAG, porty przełączników i łącza operatora należy więc równoważnie okablować po obu stronach. Redundancja WAN, SD-WAN i failover operatora pozostają osobnymi zadaniami; HA ich nie zastępuje.

• Dedicated HA link najlepiej połączyć bezpośrednio. Jeśli przebiega przez przełączniki, ścieżka musi być stabilna, mieć małe opóźnienia i nie gubić pakietów.
• Geograficznie rozdzielone węzły HA mają sens tylko w sieci Layer 2 o małych opóźnieniach i w tej samej domenie broadcast. Dedicated HA Link pozostaje w tej samej podsieci IP; duże opóźnienia lub utrata pakietów czynią taki projekt nieodpowiednim.
• Włączyć RSTP na odpowiednich przełącznikach oraz identycznie skonfigurować VLAN, Trunks i LAG po obu stronach.
• Monitorować tylko stale podłączone uplinki WAN, Core lub DMZ. Celowo odłączony Monitored Port wywoła failover.
• VLAN i LAG są obsługiwane, ale na obu węzłach muszą używać tych samych Parent Interfaces. Bridge Mode działa, lecz jego diagnostyka jest bardziej złożona niż Gateway Mode.
• Oddzielnie przetestować scenariusze VPN, RED i Remote, ponieważ nie każda sesja jest przejmowana bez przerwy.
• Świadomie ograniczyć dostęp administracyjny i Device Access. Pomaga w tym Zabezpieczenie dostępu do Sophos Firewall: prawidłowa konfiguracja Device Access.

Dla Active-Active trzeba dodatkowo ustalić, jakie wąskie gardło ma zostać odciążone przez faktycznie rozdzielany ruch TCP. Jeśli licencjonowanie, usługi i diagnostyka obu węzłów nie są wyjaśnione, Active-Passive pozostaje lepszym wyborem.

Uwaga: W stanie Split-Brain obie zapory uznają się za odpowiedzialne. Może to spowodować podwójne użycie IP i MAC oraz awarię produkcyjną. Gdy łącze HA przestanie działać, należy najpierw ustalić, który węzeł ma pozostać aktywny, a drugi wyłączyć w kontrolowany sposób lub odłączyć od sieci produkcyjnej.

Przygotowanie konfiguracji

Konfiguracji HA nie należy improwizować w sieci produkcyjnej. Poniższe przygotowanie oszczędza później dużo czasu.

Przygotowanie obu zapór

• Zaktualizować obie zapory do tej samej wersji SFOS wraz z build.
• Sprawdzić status licencji i rejestracji.
• Wyłączyć Cellular WAN.
• Upewnić się, że modele są zgodne.
• Sprawdzić wyposażenie Flexi Port.
• Udokumentować interfejsy i porty przełączników.
• Wyznaczyć port łącza HA.
• Połączyć łącze HA bezpośrednio lub sprawdzić ścieżkę przez przełączniki.
• Dla łącza HA zaplanować strefę DMZ i dostęp SSH.
• Udokumentować dostęp administracyjny do obu urządzeń.
• Utworzyć kopię zapasową istniejącej konfiguracji.
• Jeśli LINCE jest potrzebne, przed HA ujednolicić tryb na obu urządzeniach.

FIPS ma inną kolejność niż LINCE. Tryb FIPS 140-3 włącza się najpierw na samodzielnym Primary, co wykonuje reset fabryczny; podczas późniejszej konfiguracji HA Sophos automatycznie włącza FIPS na Auxiliary.

Kopie zapasowe nie są opcjonalne w HA. Kopia powinna być dostępna przed konfiguracją, aktualizacjami firmware i większymi zmianami interfejsów. Podstawy opisuje Tworzenie i przywracanie kopii zapasowej Sophos Firewall.

Przed kliknięciem Initiate HA trzeba dodatkowo sprawdzić:

• Porty administracyjne w tej samej podsieci, ale z różnymi IP: inaczej HA może nie powstać prawidłowo lub Auxiliary nie będzie później dostępna.
• Dedicated HA link bez zależności produkcyjnych: HA może zmienić adresy IP interfejsu i konfiguracje zależne.
• Monitored Ports podłączone na obu urządzeniach: niepodłączony Monitored Port może uniemożliwić utworzenie klastra lub natychmiast wywołać failover.
• Unikatowa Cluster ID: kilka klastrów HA w tej samej domenie Layer 2 wymaga różnych wirtualnych adresów MAC.
• Udokumentowana kopia zapasowa, SSMK i build firmware: klaster musi być odtwarzalny przy przywracaniu, RMA lub ponownej instalacji.

Ustalenie LINCE przed HA

Od SFOS 21.5 MR1 po utworzeniu klastra HA nie można już włączyć ani wyłączyć LINCE. Jeśli certyfikacja jest wymagana, na obu jeszcze niezależnych zaporach trzeba uruchomić w Device Console następujące polecenie.

Ostrzeżenie: Najpierw trzeba zapewnić alternatywny dostęp administracyjny przez WebAdmin lub konsolę lokalną. Polecenie włącza LINCE, ponownie uruchamia usługę SSH i rozłącza istniejące sesje SSH.

system certification lince enable

Następnie trzeba sprawdzić status LINCE na obu urządzeniach i dopiero wtedy utworzyć HA. Przy przywracaniu kopia zapasowa i klaster docelowy muszą mieć ten sam status LINCE.

Zrozumieć i włączyć tryb LINCE na Sophos Firewall wyjaśnia, dlaczego tryb nie certyfikuje automatycznie wdrożonej kompilacji SFOS i które algorytmy SSH trzeba sprawdzić przed aktywacją.

QuickHA czy Interactive mode

• QuickHA: wariant standardowy. Szybki, niezawodny i wystarczający dla większości konfiguracji Active-Passive oraz Active-Active.
• Interactive mode: przydatny, gdy przed utworzeniem klastra trzeba świadomie zdefiniować Admin Ports, adresy łącza HA, Cluster ID, Monitored Ports i wartości szczegółowe.

QuickHA początkowo pyta tylko o rolę, Node Name, Passphrase i Dedicated HA link. Passphrase musi mieć od 10 do 20 znaków oraz zawierać co najmniej jedną wielką literę, małą literę, cyfrę i znak specjalny. Jest używana raz do utworzenia kluczy SSH, a następnie usuwana. Przy wymianie urządzenia HA trzeba dlatego wyłączyć i skonfigurować ponownie.

Przygotowane urządzenia QuickHA nadal szukają peera, dopóki go nie znajdą. Można je więc skonfigurować wcześniej i podłączyć później w lokalizacji docelowej. Gdy urządzenie wykryje peera i rozpocznie tworzenie HA, tego procesu discovery nie można już zatrzymać. Wybór interfejsów, Passphrase i właściwy peer muszą zatem być poprawne, zanim oba łącza HA staną się jednocześnie osiągalne.

Opisane kroki opierają się na oficjalnej konfiguracji Sophos HA, ale celowo mają formę praktycznej listy kontrolnej dla administratora. Przy zmianach produkcyjnych nie należy tylko przechodzić przez kreator; role, łącze HA, dostęp administracyjny, kopię zapasową, status licencji i drogę powrotu trzeba udokumentować wcześniej.

Konfiguracja HA

Active-Passive z QuickHA

1. Przygotowanie Primary Firewall

1. Zalogować się do WebAdmin na przyszłej Primary Firewall.
2. Przejść do System services > High availability.
3. Jako tryb wybrać Primary (active-passive).
4. Użyć QuickHA.
5. Opcjonalnie nadać Node Name, na przykład FW01.
6. Ustawić HA Passphrase o długości od 10 do 20 znaków, zawierającą wielką i małą literę, cyfrę oraz znak specjalny.
7. Bezpiecznie zachować Passphrase, ponieważ będzie zaraz potrzebna na Auxiliary Firewall.
8. Wybrać Dedicated HA link.
9. Uruchomić Initiate HA.

Uwagi:

• Jeśli QuickHA używa nieprzypisanego interfejsu, Sophos przypisuje mu strefę DMZ i domyślnie adres 169.254.192.1. SSH dla tej strefy zostaje automatycznie włączony.
• Zapora usuwa zależne konfiguracje wybranego interfejsu łącza HA. Dlatego interfejs nie może mieć zależności produkcyjnych.

2. Przygotowanie Auxiliary Firewall

1. Zalogować się do przyszłej Auxiliary Firewall.
2. Przejść do System services > High availability.
3. Jako rolę wybrać Auxiliary.
4. Użyć QuickHA.
5. Opcjonalnie nadać Node Name, na przykład FW02.
6. Wpisać tę samą HA Passphrase.
7. Wybrać ten sam port łącza HA co po stronie Primary.
8. Uruchomić Initiate HA.

Po utworzeniu klastra Primary Firewall synchronizuje konfigurację do Auxiliary Firewall. Wiele ustawień lokalnych Auxiliary zostanie nadpisanych. Dlatego przed konfiguracją HA Auxiliary nie powinna być równolegle konfigurowana jako niezależna zapora produkcyjna.

3. Sprawdzenie ustawień zaawansowanych

Po utworzeniu klastra trzeba sprawdzić następujące elementy:

• status HA obu węzłów
• rolę i status w prawym górnym rogu WebAdmin
• Dedicated HA link
• Monitored Ports
• Peer Admin Port
• Preferred primary
• Keepalive interval i Attempts
• posiadacza licencji w Active-Passive
• rejestrację Sophos Fusion, jeśli jest używana

4. Ustawienie Monitored Ports

Monitored Ports decydują, czy awaria interfejsu wywoła failover. Typowi kandydaci:

• WAN Uplink
• Core LAN Uplink
• ważne uplinki DMZ lub serwerów

Nie należy monitorować portów, które bywają celowo odłączone, nie są okablowane albo służą tylko do opcjonalnych scenariuszy. Błędnie ustawiony Monitored Port często powoduje nieoczekiwany failover lub uniemożliwia uruchomienie klastra.

Można wybrać interfejsy fizyczne, LAG oraz nieprzypisane interfejsy ze skonfigurowanym VLAN. Nieprzypisanego interfejsu bez VLAN nie można wybrać jako Monitored Port. Monitored Ports wymagają statycznych adresów IP w obu trybach HA.

SFOS 23 pozwala na maksymalnie 24 Monitored ports. Wybór musi być odrębny od Dedicated HA link i obejmować tylko rzeczywiście potrzebne łącza produkcyjne.

Active-Active z QuickHA

Active-Active konfiguruje się podobnie, ale w innym celu. Obie zapory muszą wcześniej posiadać odpowiednie licencje.

Przebieg odpowiada Active-Passive, lecz na FW01 wybiera się Primary (active-active). Wcześniej oba urządzenia muszą zostać przypisane do konta, mieć ten sam build SFOS i odpowiednie typy licencji; wszystkie interfejsy wymagają statycznych adresów IP. Monitorowanie i diagnostyka muszą obejmować oba węzły, a odpowiedni ruch musi korzystać z opisanej wcześniej dystrybucji TCP.

Testy po konfiguracji

W Active-Active trzeba sprawdzić więcej niż sam status HA:

• Czy połączenia są rozdzielane na oba węzły?
• Czy licencje obu węzłów pomyślnie zsynchronizowano osobno, zapisując oddzielnie stan i czas?
• Czy logi są widoczne na obu urządzeniach?
• Czy połączenia VPN działają po zmianie ról?
• Czy działają Web Protection, IPS, Application Control i odpowiednie Security Features?
• Czy jakieś aplikacje wykazują problemy z powodu asymetrycznego zachowania?
• Czy raporty i alerty są generowane zgodnie z oczekiwaniami?

Interactive mode

Interactive mode jest przydatny, gdy automatyczna logika QuickHA nie zapewnia wystarczającej kontroli.

Przed konfiguracją na obu urządzeniach trzeba zezwolić na SSH oraz Ping/Ping6 dla strefy DMZ w Administration > Device access. Interactive mode początkowo automatycznie wybiera pierwszy interfejs DMZ jako Dedicated HA link. Jeśli ten interfejs nie jest przeznaczony dla HA lub ma zależności produkcyjne, przed zapisaniem należy wybrać wolny interfejs fizyczny, VLAN albo przygotowany LAG.

Typowe powody:

• wymagane są stałe adresy IP łącza HA
• Peer Admin Port musi zostać precyzyjnie zdefiniowany
• Cluster ID ma zostać ustawiona świadomie
• w tej samej domenie Layer 2 działa kilka klastrów HA
• urządzenia wirtualne mają używać określonych opcji MAC
• wymagane jest ściśle kontrolowane wdrożenie

W Interactive mode najpierw konfiguruje się Auxiliary, a następnie Primary. Dzięki temu wykrywanie drugiego węzła na Primary nie wygaśnie, gdy jest on jeszcze przygotowywany.

1. Konfiguracja Auxiliary

1. Na FW02 przejść do System services > High availability.
2. Wybrać Initial device role > Auxiliary i HA configuration mode > Interactive mode.
3. Ustawić Node Name i Passphrase zgodną z powyższymi zasadami.
4. Wybrać wolny port DMZ jako Dedicated HA link. Zapora usuwa istniejące zależne konfiguracje tego interfejsu.
5. Zapisać i poczekać na potwierdzenie zastosowania konfiguracji Auxiliary.

2. Konfiguracja Primary

1. Na FW01 wybrać Primary (active-passive) lub Primary (active-active) oraz Interactive mode.
2. Ustawić unikatową Cluster ID i Node Name.
3. Wprowadzić Passphrase z FW02.
4. Wskazać ten sam Dedicated HA link oraz statyczny adres IP łącza HA dla Auxiliary.
5. Wybrać krytyczne Monitored ports; SFOS 23 pozwala na maksymalnie 24.
6. W Peer administration settings wskazać interfejs zarządzania i oddzielny adres IP dla FW02.
7. W razie potrzeby wybrać Use host or hypervisor-assigned MAC address dla urządzeń wirtualnych w SFOS 22 albo Use interface MAC address w SFOS 23. Opcja SFOS 23 używa MAC hypervisora na urządzeniach wirtualnych i MAC interfejsu na sprzęcie zamiast wirtualnego MAC klastra. Włączenie lub wyłączenie powoduje przerwę w działaniu.
8. Ustawić Preferred primary i wybrać Initiate HA.

Po utworzeniu klastra wartości Keepalive należy zmieniać tylko z udokumentowanego powodu. SFOS 22 pozwala na interwały 250–500 ms i 16–24 prób; domyślne 250 ms i 16 prób dają timeout 4 sekund. SFOS 23 pozwala na 100–500 ms i 3–24 prób; domyślne 100 ms i 3 próby dają 300 ms. Dla Dedicated HA link w SFOS 23 z LAG lub VLAN na LAG iloczyn musi wynosić co najmniej 2500 ms: 250 ms × 10 prób to dozwolony przykład, nie ogólna wartość domyślna. Sprawdzić to również dla redundantnych LAG utworzonych przez QuickHA. Tych wartości nie można zmieniać, gdy urządzenia mają status Standalone lub Faulty. Po upływie timeoutu nowa Primary wykonuje kontrole wewnętrzne i dopiero potem zaczyna obsługiwać ruch. Żaden z tych timeoutów nie gwarantuje czasu przywrócenia ruchu.

W zaawansowanych ustawieniach HA SFOS 23 Monitor hardware components jest opcjonalne i dodaje wyzwalacz failover po wykryciu problemu z urządzeniem pamięci masowej, obok wykrywania awarii heartbeat i monitorowanych interfejsów. Nie zakładać domyślnego włączenia ani wykrywania wszystkich usterek sprzętowych.

Uwaga dotycząca API SFOS 23: Tabela parametrów API wymienia HardwareMonitor jako opcjonalny parametr skalarny (SCALAR, Mandatory: No), z wartościami Enable i Disable oraz udokumentowaną wartością domyślną API Enable. Ten zapis w dokumentacji nie potwierdza rzeczywistego ustawienia w GUI ani stanu działającego urządzenia. Sprawdzić ustawienie na zainstalowanym urządzeniu; opisany powyżej zakres ograniczony do urządzeń pamięci masowej pozostaje bez zmian.

Przykład XML API SFOS 23 nadal zawiera Number(250-500) i Number(16-24). Te symbole zastępcze nie odpowiadają zakresom w tabeli, 100–500 ms i 3–24 próby, i nie wolno ich traktować jako pełnych limitów. Nie dowodzi to ani odrzucania niższych wartości przez produkt, ani przetestowanego zachowania API.

Podłączanie nowej wirtualnej Auxiliary jako HA spare

Dla nowej wirtualnej Auxiliary w Active-Passive Setup Assistant może użyć Connect as HA spare. Active-Active lub dwie istniejące zapory Virtual/Software nadal wymagają QuickHA albo Interactive mode na obu urządzeniach.

1. Na istniejącym Primary zezwolić na SSH dla DMZ pod Administration > Device access i przygotować Active-Passive w Interactive mode. Zapisać Dedicated HA Link, adres IP peer, Peer Administration i passphrase HA. Primary może pokazywać Standalone, dopóki nowa Auxiliary nie dołączy.
2. Zainstalować nową zaporę wirtualną z dokładnie tym samym build SFOS, uruchomić Setup Assistant i ustawić nowe hasło administratora.
3. Wybrać Connect as HA spare i wprowadzić numer seryjny istniejącego Primary, tę samą passphrase HA, ten sam interfejs Dedicated HA Link oraz wolny adres IP z taką samą maską podsieci.
4. Wybrać Apply, Continue i Finish. SFOS tworzy Auxiliary, nadaje numer seryjny zaczynający się od HAAUX i automatycznie konfiguruje Dedicated HA Link oraz port administracyjny.
5. Po kilku minutach odświeżyć WebAdmin Auxiliary i zalogować się ponownie. Następnie na Primary sprawdzić role, synchronizację, Peer Admin, Monitored Ports i failover.

Walidacja klastra

Po konfiguracji klaster HA trzeba sprawdzić systematycznie.

Kontrola w WebAdmin

1. Zalogować się do Primary Firewall.
2. Sprawdzić status HA w prawym górnym rogu.
3. Przejść do System services > High availability.
4. Sprawdzić role, status, numery seryjne i tryb.
5. Upewnić się, że klaster jest zsynchronizowany.
6. W Active-Passive sprawdzić, które urządzenie posiada licencję klastra.

Kontrola w CLI

W Device Console poniższe polecenie tylko do odczytu pokazuje role, status i synchronizację klastra. Nie zmienia konfiguracji:

system ha show details

Sprawdzenie parametrów operacyjnych SFOS 22

SFOS 22 publikuje dwa dodatkowe mechanizmy sterowania HA. Oba należy najpierw tylko odczytać:

system ha auxiliary_system_traffic_through_dedicated_link show
system ha load-balancing show

Pierwszy mechanizm określa ścieżkę dla ruchu systemowego wysyłanego przez samą Auxiliary Firewall. Domyślnie cały ten ruch przechodzi przez Dedicated HA Link. Oprócz all dostępne są none i only_dynamic_interface. Sophos nie precyzuje, które przepływy są w ostatnim trybie uznawane za interfejs dynamiczny. Tej opcji używa się więc tylko w przypadku potwierdzonym dla zainstalowanego buildu, a nie jako ogólnej korekty routingu.

Drugi mechanizm włącza lub wyłącza rozdzielanie kwalifikującego się ruchu między zapory. Nie zastępuje wyboru trybu HA ani nie sprawia, że wykluczone wyżej usługi i tunele zaczynają podlegać load balancing. Zmiany wykonuje się pojedynczo w oknie serwisowym, zapisując wcześniej oba wyniki show:

system ha auxiliary_system_traffic_through_dedicated_link [all|none|only_dynamic_interface]
system ha load-balancing [on|off]

Następnie sprawdza się role, synchronizację, Dedicated HA Link, nowe sesje, logi lokalne węzłów i połączenia systemowe inicjowane przez samą Auxiliary. W celu wycofania przywraca się odczytaną wcześniej wartość. Sophos dokumentuje all jako wartość domyślną tylko dla pierwszego mechanizmu; dla load balancing nie należy zakładać wartości domyślnej.

Urządzenie będące licencjonowanym Initial Primary sprawdza się w System services > High availability. Sophos dokumentuje również następującą oficjalną kontrolę CLI w Advanced Shell:

nvram get "#li.master"

YES identyfikuje Initial Primary posiadające licencje klastra, a NO urządzenie skonfigurowane jako Auxiliary. Polecenie jest tylko do odczytu. Widok HA pozostaje wygodniejszy do codziennej kontroli, ale wynik w shellu jest również oficjalnie udokumentowany.

Jeśli dostęp do Shell nie został jeszcze przygotowany, pomaga artykuł Połączenie z Sophos Firewall przez SSH.

Test funkcjonalny

• Przetestować klienta z LAN do Internetu.
• Przetestować dostęp do serwerów wewnętrznych.
• Przetestować VPN.
• Przetestować scenariusze DNAT lub WAF.
• Przetestować DNS i DHCP, jeśli te usługi zapewnia zapora.
• Sprawdzić logi w Log Viewer.
• Przetestować zmianę ról HA w oknie serwisowym.
• Następnie udokumentować role, status i zachowanie sesji.

Eksploatacja i utrzymanie

Bieżące monitorowanie

Należy monitorować status HA i ról, Dedicated HA link, Monitored Ports, licencje, firmware, CPU, RAM, dysk i kluczowe usługi. Alerty powinny trafiać do Sophos Fusion, e-maila lub istniejącego systemu monitoringu.

Stan dysków i sprzętu obu węzłów trzeba oceniać oddzielnie. Lokalne raporty, pliki logów i stan SSD mogą się różnić. Pomagają w tym artykuły Sprawdzanie miejsca i zarządzanie raportami Sophos Firewall oraz Sprawdzanie stanu SSD Sophos Firewall przez SMART.

Logi i raporty

Każdy węzeł zapisuje logi obsługiwanego ruchu. W Active-Active trzeba więc sprawdzać oba urządzenia. Do wspólnej analizy nadaje się Sophos Central Firewall Reporting lub Syslog. Lokalne pliki opisuje Diagnostyka Sophos Firewall: usługi i logi.

Auxiliary wysyła raporty e-mailem tylko wtedy, gdy dany raport zawiera dane na tym węźle, na przykład aktywność poczty lub Pattern Updates. Nie wysyła raportów bez danych, takich jak Security Dashboard lub Security Audit. Brak wiadomości e-mail dla tych typów raportów sam w sobie nie świadczy więc o błędzie.

Dla zdarzeń HA na każdym węźle osobno otwiera się Log viewer > System i filtruje odpowiedni okres. Do szczegółowej analizy na obu urządzeniach otwiera się Diagnostics > Tools > Troubleshooting logs > Select files, wybiera co najmniej csc.log i zapisuje każdy pakiet oddzielnie przez Download. Dopiero porównanie obu węzłów pokazuje pełny przebieg zdarzeń klastra.

Instrukcja eksploatacji HA

W instrukcji operacyjnej należy co najmniej udokumentować:

• numer seryjny, lokalizację, pozycję w szafie rack i rolę obu urządzeń
• Dedicated HA link, Peer Admin Port, Cluster ID i Monitored Ports
• Preferred primary i oczekiwane zachowanie po failover
• posiadacza licencji, status wsparcia i drogę kontaktu RMA
• przebieg i odpowiedzialność za aktualizacje firmware, kopie zapasowe, ponowną instalację, wymianę sprzętu, logi i przypadki wsparcia

Jeśli na jednym węźle zawiesi się tylko WebAdmin, nie oznacza to automatycznie awarii całego klastra HA. Przed uruchomieniem failover lub ponownym uruchomieniem urządzenia trzeba sprawdzić, czy wystarczy ponowne uruchomienie WebAdmin GUI albo kontrolowany restart usługi.

Zmiany w klastrze

Reguły, interfejsy i Policies należy zmieniać wyłącznie na Primary. Przed zmianami w interfejsach, VLAN, LAG, strefach, routingu, NAT, VPN, Device Access lub SD-WAN:

• utworzyć kopię zapasową
• zdefiniować okno serwisowe
• sprawdzić status HA
• zaktualizować dokumentację
• ustalić drogę powrotu
• następnie przetestować synchronizację i ruch

Ręczna synchronizacja i wymuszona zmiana roli

Automatyczna synchronizacja jest normalnym trybem pracy. Opcji Sync auxiliary device na Primary lub Auxiliary należy używać tylko do usunięcia potwierdzonego problemu z synchronizacją. Auxiliary uruchamia się ponownie, wykonuje pełną synchronizację bazy danych i powiązanych plików, a następnie pozostaje Auxiliary. Logi i raporty pozostają lokalne na każdym węźle. Podczas tego procesu zapora przerywa wszystkie połączenia z masqueradingiem, dlatego operację trzeba zaplanować w oknie serwisowym.

W Active-Passive można wymusić przejęcie roli przez Auxiliary za pomocą Switch to passive device na aktualnym Primary lub Switch to active device na aktualnym Auxiliary. Aktualny Primary uruchamia się ponownie. Jest to planowana zmiana roli z ryzykiem dla sesji, a nie nieszkodliwy przełącznik.

Kontrolowane wyłączanie HA

Jeśli to możliwe, HA należy wyłączać na aktualnym Primary w System services > High availability > Disable HA. Użyty węzeł decyduje o wyniku:

Aktualizacje firmware i kopie zapasowe

Aktualizacje firmware w środowiskach HA

Aktualizacje firmware uruchamia się na Primary Firewall. Urządzenia są aktualizowane kolejno, a klaster może w tym czasie zmieniać role.

Typowy przebieg:

1. Uruchomić aktualizację na Primary Firewall.
2. Auxiliary Firewall zostaje zaktualizowana.
3. Auxiliary Firewall uruchamia się ponownie i tymczasowo przejmuje pracę.
4. Dotychczasowa Primary zostaje zaktualizowana.
5. Dotychczasowa Primary uruchamia się ponownie.
6. Jeśli ustawienie Preferred primary jest włączone, może nastąpić powrót do preferowanego urządzenia.

Aktualizacje firmware należy mimo to przeprowadzać w oknie serwisowym. Chociaż proces ma minimalizować przerwę w działaniu, pojedyncze sesje, połączenia VPN lub specjalne aplikacje mogą zostać na krótko zakłócone.

Rollback firmware pary HA przebiega w ten sam sposób i nie wymaga wcześniejszego wyłączenia HA.

W przygotowaniu pomaga Aktualizacja firmware Sophos Firewall — przygotowanie i Best Practices.

Pattern Updates

Pattern Updates instaluje się na Primary, po czym są automatycznie synchronizowane do Auxiliary. Dotyczy to również środowisk, w których aktualizacje są kontrolowane lub instalowane bez dostępu do Internetu.

W izolowanym klastrze HA przed każdą ręczną aktualizacją Pattern lub licencji trzeba wiedzieć, który węzeł jest Initial Primary, a który jest aktualnie Primary. Proces Air-Gap opisuje Licencjonowanie Air-Gap i Pattern Updates na Sophos Firewall.

Kopia zapasowa i przywracanie

Kopie zapasowe należy tworzyć regularnie i przed każdą większą zmianą. Przy włączonym LINCE kopia i klaster docelowy muszą mieć ten sam status LINCE. Występują trzy scenariusze przywracania:

Uwaga przy kopii bez HA: Opisy Sophos dla SFOS 22 i 23 są wewnętrznie sprzeczne co do stanu Auxiliary po tym przywracaniu: tekst mówi o zachowaniu poprzedniej konfiguracji, a podsumowanie o przywróceniu ustawień fabrycznych z wyjątkiem Peer Admin Port i Dedicated HA Link. Ani pełne zachowanie konfiguracji, ani reset fabryczny nie są więc potwierdzonym zachowaniem. Nie polegać na zachowaniu konfiguracji Auxiliary. Najpierw zapisać konfiguracje poza urządzeniami, udokumentować administracyjne adresy IP i dane logowania oraz zaplanować przerwę i odbudowę HA. Przed uzależnieniem działania od niepewnego stanu Auxiliary wyjaśnić procedurę dla zainstalowanego buildu SFOS z Sophos Support.

Jeśli Primary było zarejestrowane jako gateway Sophos ZTNA, po przywróceniu do klastra HA należy dodać je ponownie jako gateway w Sophos ZTNA.

Reimage węzłów HA w Active-Passive

Reimage przerywa pracę i według Sophos te procedury dotyczą tylko Active-Passive. Najpierw wykonać system diagnostics show version-info w Device Console na obu węzłach, udokumentować firmware wraz z build oraz Initial Primary i zapisać aktualną kopię poza klastrem.

Jeśli klaster korzysta z Sophos Fusion Synchronized Security, parę HA należy usunąć z zarządzania Central przed zwrotem urządzenia w ramach procesu RMA. Po wymianie nowy klaster HA rejestruje się ponownie w Central. Zapobiega to konfliktom synchronizacji numerów seryjnych i licencji ze starym urządzeniem, które nadal pozostaje zarejestrowane.

Wymiana Auxiliary po RMA

Wymiana lub ponowna instalacja węzła powoduje planowaną przerwę. Poniższe procedury dotyczą Active-Passive; w Active-Active konkretny przebieg trzeba uzgodnić z Sophos Support.

1. Sprawdzić, czy model i rewizja sprzętowa urządzenia zastępczego są odpowiednie, i zainstalować dokładnie ten sam build firmware co na sprawnej Primary.
2. Przypisać urządzenie zastępcze do konta Sophos Fusion i przenieść licencję z uszkodzonej Auxiliary.
3. Przepiąć kable z uszkodzonego urządzenia do zastępczego.
4. Na sprawnej Primary wyłączyć HA w System services > High availability.
5. W Advanced Shell sprawdzić, czy msync jest zatrzymany:

service -S | grep msync

Oczekiwany wynik to UNTOUCHED lub STOPPED. Polecenie niczego nie zmienia; inny status oznacza, że nie należy jeszcze ponownie tworzyć HA. Następnie skonfigurować sprawną Primary jako Primary, a urządzenie zastępcze jako Auxiliary.

Wymiana Primary po RMA

1. Pobrać aktualną kopię zapasową ze sprawnej Auxiliary i wyrejestrować urządzenie z Sophos Fusion.
2. Zainstalować na urządzeniu zastępczym ten sam build firmware, przypisać je do konta Sophos Fusion i przenieść licencję uszkodzonej Primary.
3. Przywrócić kopię zapasową na urządzeniu zastępczym.
4. Przepiąć kable ze sprawnej Auxiliary do urządzenia zastępczego. Od tego momentu urządzenie zastępcze obsługuje ruch jako niezależna zapora.
5. Przywrócić dotychczasową Auxiliary do ustawień fabrycznych, ponownie przypisać ją do konta Sophos Fusion i podłączyć przewidziane kable.
6. Ponownie utworzyć HA z urządzeniem zastępczym jako Primary i zresetowanym urządzeniem jako Auxiliary.

Uwaga: Przywracanie kopii zapasowej, Factory Reset i przepinanie kabli powodują przerwę w działaniu. Przed rozpoczęciem trzeba udokumentować numery seryjne, Initial Primary, build firmware, transfer licencji, status Central i drogę powrotu.

W ponownej instalacji pomaga Ponowna instalacja Sophos Firewall OS z pamięci USB. Jeśli podejrzewana jest awaria sprzętu lub proces RMA, trzeba również uwzględnić Prawidłowe przygotowanie awarii sprzętu Sophos i RMA.

Diagnostyka

Przy złożonych problemach trzeba zachować kolejność: najpierw sprawdzić status, łącze HA, Monitored Ports, wersję firmware i status licencji, a dopiero później analizować przypadki szczególne lub wskazówki producenta. Dzięki temu wiadomo, czy problem rzeczywiście dotyczy HA, czy wynika z licencji, interfejsu, firmware lub monitoringu.

Ważne logi i miejsca diagnostyczne

• Status HA: System services > High availability.
• Event Logs: Log viewer > System.
• Troubleshooting Logs: Monitor & Analyze > Logs > Troubleshooting logs lub przez SSH w /log.
• Szczegóły HA w CLI: patrz jednorazowo opisana kontrola CLI w sekcji Walidacja klastra.
• Problemy interfejsów: show network interfaces, ifconfig, dmesg w odpowiednich przypadkach diagnostycznych.
• Posiadacz licencji: System services > High availability.

Do pierwszej analizy szczególnie przydatne są:

• ha.log: błędy tworzenia, pomyślne utworzenie HA i zmiany statusu.
• ha_pair.log: wykrywanie drugiego węzła w QuickHA.
• ha_tunnel.log: tunel SSH przez Dedicated HA link.
• msync.log: synchronizacja konfiguracji HA.
• ctsyncd.log: synchronizacja sesji Conntrack.
• filesync.log: synchronizacja plików związanych z usługami, na przykład dla tras dynamicznych lub DHCP.

Każdy węzeł przechowuje tylko logi i raporty ruchu, który sam obsługuje. Do Auxiliary należy zalogować się przez jej adres Peer Admin albo pobrać pliki logów przez SSH bezpośrednio z tego węzła.

Przy głębszej analizie pomaga Diagnostyka Sophos Firewall CLI: ważne polecenia.

Typowe problemy HA

• Klaster nie powstaje, różni się wersja firmware lub numer build: sprawdzić wersje na obu urządzeniach i zaktualizować obie zapory do identycznej wersji SFOS.

• Klaster nie powstaje, niezgodny model lub urządzenie: sprawdzić model i numer seryjny. Dla sprzętowego HA używać tylko zgodnych, identycznych modeli urządzeń XGS Appliance.

• HA could not be enabled: Dedicated HA link może nie być podłączony lub drugi węzeł jest niedostępny. Sprawdzić stan portu, kabel, przełącznik i Ping do adresu IP łącza HA, a następnie ustabilizować okablowanie lub łącze.

• HA-Link down: przyczyną może być kabel, port przełącznika, VLAN lub LAG. Sprawdzić status interfejsu, Speed/Duplex, VLAN Trunk i członków LAG.

• Oba urządzenia przechodzą do Standalone: łącze HA nie działa i istnieje ryzyko Split-Brain. Sprawdzić fizyczne połączenie i ścieżkę przez przełączniki, wyłączyć jedno urządzenie w kontrolowany sposób, naprawić łącze HA i dopiero potem ponownie je uruchomić.

• WebAdmin Auxiliary jest niedostępny: Peer Admin Port, podsieć, trasa lub Device Access są nieprawidłowe. Sprawdzić adres IP Admin Port i dostęp z sieci zarządzającej.

• Validation failed for HA interface IP: Admin Ports lub adresy łącza HA nie znajdują się w oczekiwanej podsieci. Sprawdzić adresy IP i /log/syslog.log, a następnie poprawić adresację.

• Failover występuje nieoczekiwanie: często zawiódł lub został błędnie wybrany Monitored Port. Sprawdzić Monitored Ports i stan przełącznika oraz monitorować tylko rzeczywiście krytyczne, stabilne porty. Jeśli dotknięty węzeł rzeczywiście się zrestartował, a nie tylko zmienił rolę, należy sprawdzić nieoczekiwany restart dla tego węzła.

• Failover nie występuje: odpowiedni port prawdopodobnie nie jest monitorowany. Dodać krytyczne porty WAN, Core lub DMZ jako Monitored Ports.

• Active-Active nie rozdziela ruchu zgodnie z oczekiwaniami: dany rodzaj ruchu może nie podlegać równoważeniu obciążenia. Sprawdzić typ połączenia, protokół i logi obu węzłów; jeśli korzyść pozostaje niejasna, użyć Active-Passive lub dostosować projekt.

• Pozornie brakuje logów: ruch mógł zostać obsłużony przez drugi węzeł albo rejestrowanie nie jest aktywne. Sprawdzić oba węzły i Log Viewer, włączyć rejestrowanie w regułach oraz użyć Central Reporting lub Syslog.

• Raporty się różnią: raporty lokalne są zależne od węzła. Porównać raporty obu urządzeń albo użyć Sophos Central Firewall Reporting.

• Problem licencji w Active-Active: typy licencji mogą być niezgodne. Sprawdzić Licensing na obu zaporach i ujednolicić licencje.

• Problemy po aktualizacji firmware: jeden węzeł nie został poprawnie zaktualizowany lub klaster nie jest zsynchronizowany. Sprawdzić status HA, wersje firmware i logi; w środowisku produkcyjnym używać okna serwisowego i zaangażować Sophos Support.

• Łącze HA przez Flexi Port nie działa po aktualizacji: w modelach 1U XGS 2100, XGS 2300, XGS 3100, XGS 3300, XGS 4300 i XGS 4500 HA może nie zostać zestawione, jeśli Flexi Port pełni rolę Dedicated HA link. Po aktualizacji i ponownym uruchomieniu pierwszego urządzenia jego Interface speed nie jest już ustawione na Auto negotiation, podczas gdy drugie urządzenie nadal używa Auto negotiation.

  Przed zmianą ustawienia: udokumentować role HA i ustawienia portów obu urządzeń, zapewnić kopię zapasową i oddzielny dostęp administracyjny oraz wykonać zmianę w oknie serwisowym. W przypadku Split-Brain najpierw zastosować poniższą procedurę awarii łącza HA: ustalić, który węzeł ma pozostać aktywny, a drugi odłączyć od sieci produkcyjnej lub wyłączyć w kontrolowany sposób. Nie uruchamiać ponownie obu węzłów bez koordynacji.

  1. Na obu urządzeniach otworzyć Network > Interfaces.
  2. Wybrać odpowiedni interfejs Flexi Port i otworzyć Advanced settings.
  3. Ustawić Interface speed na Auto negotiation.

  Następnie sprawdzić stan łącza, role HA, synchronizację i ruch produkcyjny. Jeśli problem nadal występuje, zapisać ustawienia i logi obu węzłów oraz skontaktować się z Sophos Support. Poprzednie udokumentowane wartości przywracać wyłącznie w ramach kontrolowanej zmiany z zapewnionym dostępem administracyjnym; może to ponownie wywołać awarię łącza HA. Alternatywnie można zaplanować użycie portu wbudowanego jako Dedicated HA link, a nie stałej wartości prędkości. Zmianę zweryfikowano na podstawie dokumentacji, lecz nie przetestowano jej na urządzeniu.

Postępowanie przy awarii łącza HA

Gdy Dedicated HA link przestanie działać, trzeba zachować ostrożność. Zapory nie widzą się wzajemnie. W niekorzystnym przypadku oba urządzenia wysyłają ARP/GARP i próbują przejąć Cluster MAC.

Bezpieczna procedura:

1. Ustabilizować stan sieci.
2. Zdecydować, które urządzenie ma pozostać aktywne.
3. Drugie urządzenie wyłączyć w kontrolowany sposób lub odłączyć od sieci produkcyjnej.
4. Naprawić kabel łącza HA, port przełącznika, VLAN lub LAG.
5. Ponownie uruchomić urządzenie.
6. Sprawdzić status HA.
7. Skontrolować logi i role.

Dodatkowe polecenia CLI

Oprócz odczytu statusu HA opisanego w sekcji Walidacja klastra, następujące polecenie tylko do odczytu w Device Console:

show network interfaces

pokazuje stan interfejsów i łączy. Dla Dedicated HA link i podłączonych Monitored Ports oczekiwany jest stan UP.

Aby sprawdzić cykliczne zaniki łącza, należy przejść do powłoki przez Device Management > Advanced Shell i zastąpić PortE rzeczywistą nazwą interfejsu:

dmesg | grep PortE

Wynik filtruje komunikaty jądra systemu dla tego interfejsu. Powtarzające się komunikaty Link Up/Link Down wskazują na problem z kablem, modułem nadawczo-odbiorczym, portem lub negocjacją. Polecenie niczego nie zmienia; dmesg zawiera jednak tylko bieżący bufor jądra systemu i nie zastępuje długoterminowej analizy logów.

Pełną diagnostykę warstwy fizycznej za pomocą ethtool, danych modułu i opisów znanych przypadków przedstawia artykuł Dobór i diagnostyka SFP oraz SFP+ w Sophos Firewall.

Przed każdą głębszą ingerencją trzeba najpierw zabezpieczyć wyniki i znaczniki czasu. Polecenia zostały sprawdzone względem aktualnej dokumentacji Sophos, ale nie wykonano ich na indywidualnym sprzęcie klienta.

Lista kontrolna Go-live

• Wybór Active-Passive lub Active-Active został uzasadniony.
• Sprawdzono modele, Flexi Ports, build SFOS, status LINCE, przypisanie urządzeń do konta i licencje.
• Dostępne są kopia zapasowa i droga powrotu.
• Dedicated HA link jest wolny, stabilny i w miarę możliwości połączony bezpośrednio.
• VLAN, LAG, porty przełączników i RSTP są spójne po obu stronach.
• Przetestowano dostęp Peer Admin do Auxiliary.
• Jako Monitored Ports wybrano tylko stabilne, krytyczne interfejsy.
• Udokumentowano Cluster ID, Initial Primary, Preferred primary i numery seryjne.
• Sprawdzono WebAdmin, status CLI i odpowiednie logi.
• Funkcjonalnie przetestowano LAN, Internet, serwery, VPN, DNAT/WAF, DNS i DHCP.
• Failover i powrót ról przetestowano w oknie serwisowym.
• Monitorowanie oraz procedury firmware, przywracania i RMA zapisano w instrukcji operacyjnej.

FAQ