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 sprawdzić, czy oba urządzenia, kompilacje firmware, licencje, okablowanie i dostęp administracyjny spełniają wymagania HA.

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ą synchronizowane między obiema 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: kwalifikujące się połączenia TCP z parzystych adresów źródłowych obsługuje Primary, a połączenia z nieparzystych adresów trafiają do Auxiliary. Rozdzielany jest przekazywany ruch TCP oraz połączenia TCP poddawane translacji, w tym SNAT i ruch Virtual Host, 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ć. Obsługa Layer 7 jest zróżnicowana: według Sophos DPI Engine, transparentne, bezpośrednie i nadrzędne serwery proxy (Parent Proxies), a także ruch SMTP Proxy i HTTPS obsługują równoważenie obciążenia. Skanowany FTP i H.323 go nie obsługują. Wykluczony jest również ruch inny niż TCP, taki jak UDP, ICMP, multicast i broadcast, SD-RED oraz tunelowany ruch TCP i inny niż TCP, w tym VPN. Zewnętrzne load balancery nie są obsługiwane w 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 rozdzielanie odpowiedniego ruchu rzeczywiście przynosi korzyść wydajnościową. 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 miarodajne jest aktualnie aktywne urządzenie 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, SFOS przypisuje wirtualne adresy MAC interfejsom fizycznym, z wyjątkiem Dedicated HA Link i portów administracyjnych. Dedicated HA Link używa własnego fizycznego adresu MAC. Tylko Primary odpowiada na zapytania ARP dotyczące klastra. Po failover Auxiliary przejmuje wirtualny adres MAC danego interfejsu produkcyjnego. 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żny jest identyfikator Cluster ID. Jest on używany do tworzenia wirtualnego adresu MAC. Jeśli w tej samej domenie Layer 2 działa kilka klastrów HA, każdy musi mieć unikatowy identyfikator 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. W Active-Active oba urządzenia wymieniają z drugim węzłem status i szczegóły aktywnych sesji; synchronizacja konfiguracji nadal odbywa się natomiast z Primary do Auxiliary.
• Secure Storage Master Key i dane dostępowe WebAdmin są synchronizowane.
• Dedicated HA link i porty administracyjne są wyłączone z synchronizacji zgodnie z oficjalnym opisem trybów i ról HA. Dokumentacja dotycząca PortMGMT zawiera jednak sprzeczne instrukcje, opisane poniżej w sekcji Wymagania sieciowe.
• Logi i raporty nie są synchronizowane między urządzeniami.

Zachowanie podczas failover

W Active-Passive Auxiliary przejmuje cały ruch w razie awarii Primary. W Active-Active awaria jednego z dwóch aktywnych urządzeń może natomiast spowodować przejęcie pracy przez sprawny drugi węzeł. Jeśli awarii ulegnie Auxiliary, Primary samodzielnie obsługuje cały ruch; nie musi to oznaczać zmiany ról. Gdy drugi węzeł staje się niedostępny, pozostałe urządzenie działa jako Standalone. Sam ten status nie dowodzi więc jeszcze awarii łącza HA po obu stronach; przed zastosowaniem procedury Split-Brain sprawdzić role i dostępność obu węzłów.

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 węzeł uruchamia się w trybie Failsafe, najpierw dokumentuje się jego rolę i stan drugiego węzła. Diagnostyka Sophos Firewall w trybie Failsafe opisuje bezpieczną procedurę diagnostyczną i wyjaśnia, dlaczego nie należy bez koordynacji restartować obu węzłów 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.

Rozbieżne informacje o Heartbeat w SFOS 23: Ogólny opis failover nadal podaje 250 ms i 16 prób, natomiast szczegółowa instrukcja konfiguracji SFOS 23 — 100 ms i 3 próby. Wartości domyślne dotyczą konfiguracji SFOS 23; bieżące ustawienia należy odczytać z urządzenia. Przed zmianą w System services > High availability udokumentować rzeczywiście skonfigurowane wartości i topologię łącza HA na obu węzłach. Ani starsze wartości, ani krótszy domyślny timeout z instrukcji konfiguracji nie uzasadniają zmiany istniejącego klastra bez wcześniejszej weryfikacji; jeśli wartości są niejasne lub nie spełniają wymogu dla LAG, uzgodnić plan z Sophos Support.

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 w klastrze, jeśli nie ustawiono Preferred primary. Jeśli jest ustawione jako 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ę wtedy ponownie. Ten failback należy więc zaplanować w oknie serwisowym. Opisane zmiany ról i ponowne uruchomienia nie gwarantują nieprzerwanej obsługi istniejących połączeń.

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 reflektora mDNS. 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. Przykładowe platformy wirtualne to Microsoft Hyper-V, VMware i Nutanix Prism; urządzenia programowe działają na własnym sprzęcie. Wymienienie platformy nie zastępuje sprawdzenia poniższych wymagań HA.

• Platforma: ten sam typ urządzenia i ta sama platforma SFOS.
• Hypervisor: ten sam typ Hypervisor.
• Zasoby: identycznie przydzielone zasoby sprzętowe, w tym taka sama liczba rdzeni CPU, oraz taka sama liczba interfejsów sieciowych.
• Firmware: ta sama wersja SFOS wraz z numerem kompilacji.
• 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

Parę HA można podłączyć do przełączników warstwy dostępowej, w tym Sophos Switches. Sophos Fusion, dawniej Sophos Central, umożliwia centralne zarządzanie zaporami i przełącznikami Sophos. Nie zastępuje to jednak redundantnego projektu sieci przełączników: awaria wspólnego przełącznika nadal może dotknąć oba węzły. Starszy przegląd SFOS 23 nadal używa nazwy Sophos Central; nie oznacza to innej architektury HA.

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ę i stan licencji oraz porównać konfiguracje bez wprowadzania zmian. 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. 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. Przed każdą zmianą udokumentować źródłowy numer seryjny Auxiliary, do którego omyłkowo przypisano licencje, oraz zamierzony docelowy numer seryjny Initial Primary, niezależnie od aktualnych ról HA, i porównać te dane w SFOS oraz Sophos Fusion. Ta skrócona procedura korekty obowiązuje tylko wtedy, gdy aktualny Primary i Initial Primary są tym samym fizycznym urządzeniem. Jeśli są to różne urządzenia lub przypisanie jest niejasne, zatrzymać się przed wyłączeniem HA lub transferem licencji i ustalić właściwą procedurę na podstawie instrukcji Sophos lub z pomocą Sophos Support; nie improwizować powrotnej zmiany ról. Dopiero po jednoznacznym ustaleniu przypisania planowo wyłączyć HA na aktualnym Primary, przenieść subskrypcje w Sophos Fusion z udokumentowanego źródłowego numeru seryjnego na udokumentowany docelowy numer seryjny Initial Primary, 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 objęte tym ograniczeniem subskrypcje ochronne stają się w przeciwnym razie nieaktywne; 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, DHCP Prefix Delegation lub PPPoE. Udokumentowany brak przejmowania sesji dotyczy połączenia PPPoE, a nie ogólnie interfejsów DHCP.

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. Ograniczenie przejmowania sesji PPPoE nie ustanawia ogólnego wyjątku dla interfejsów DHCP: przydzielanie adresów i ruch protokołu DHCP to inne kwestie niż zachowanie przekazywanych sesji TCP. Stosować opisane powyżej ograniczenia protokołów i usług; nie wynika z tego również ogólna gwarancja zachowania sesji na interfejsach DHCP.

Interfejsy breakout konfiguruje się na Primary. Przy nowej konfiguracji breakout najpierw uruchomić ponownie Primary, aby zastosować zmianę, a następnie uruchomić ponownie Auxiliary. Jeśli odpowiednia konfiguracja breakout już istnieje na Primary, po synchronizacji uruchomić ponownie tylko Auxiliary. Jeśli na Primary nie ma odpowiedniej konfiguracji breakout, synchronizacja usuwa konfigurację breakout istniejącą tylko na Auxiliary. Poszczególne przypadki wyjaśnia artykuł Konfigurowanie interfejsów breakout.

Łą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 zapewnia oddzielny dostęp administracyjny do Auxiliary Firewall. QuickHA automatycznie wybiera interfejs bieżącej sesji WebAdmin; dostęp do WebAdmin Auxiliary przez Peer Admin wymaga stacji administracyjnej w tej samej podsieci. Sprzeczność w oficjalnej dokumentacji dotyczącej adresacji zarządzania: opis trybów i ról HA wyłącza Dedicated HA Link oraz porty administracyjne z synchronizacji, a wymagania interfejsów HA nakazują użycie na obu portach administracyjnych różnych statycznych adresów IP w tej samej podsieci. Z kolei instrukcja początkowej konfiguracji portu zarządzania zabrania różnych adresów PortMGMT w HA, uzasadniając to synchronizacją konfiguracji. Te instrukcje są sprzeczne. Wspólny adres PortMGMT i dodatkowy adres Peer Administration nie stanowią potwierdzonego rozwiązania tej sprzeczności. Przed konfiguracją HA lub zmianą adresów zarządzania udokumentować aktualne role Primary/Auxiliary (lub planowane role urządzeń działających samodzielnie), dokładny zainstalowany build SFOS, wybrany interfejs administracyjny i bieżące adresy IP obu urządzeń, zabezpieczyć kopię zapasową oraz zapewnić oddzielny dostęp przez konsolę lub lokalną ścieżkę administracyjną. Zweryfikować zasady adresacji właściwe dla zainstalowanego buildu albo uzgodnić je z Sophos Support. Jeśli sprzeczność pozostaje nierozstrzygnięta, zatrzymać się przed Initiate HA lub zmianą adresów zarządzania.

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 wybrać po obu stronach ten sam Link mode z odpowiednią prędkością i trybem dupleksu w Network > Interfaces > Advanced settings i zapisać ustawienia przyciskiem Save. Następnie ponownie otworzyć interfejs do edycji, użyć Show recommended settings > Load recommended configuration dla negocjacji i Forward Error Correction (FEC) oraz ponownie zapisać ustawienia przyciskiem Save. Jeśli po pierwszym zapisaniu i ponownym otwarciu zalecenia nadal są puste, wyłączyć Auto-negotiation dla Media Type i FEC oraz zapisać zmianę. Dla innych portów użyć Automatic lub identycznych wartości prędkości i dupleksu oraz pozostawić domyślne wartości MTU i MSS. Gdy QuickHA wybiera nieprzypisany interfejs, SFOS resetuje jego Advanced settings; sprawdzić te wartości 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 numerem kompilacji.
• 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 powoduje przywrócenie ustawień fabrycznych; 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ć:

• Zweryfikowana adresacja administracyjna: ze względu na opisaną sprzeczność instrukcji HA i PortMGMT udokumentować aktualne role Primary/Auxiliary (lub planowane role urządzeń działających samodzielnie), dokładny build SFOS, wybrany interfejs administracyjny i bieżące IP obu urządzeń. Zabezpieczyć kopię zapasową i oddzielny dostęp przez konsolę lub lokalną ścieżkę administracyjną. Potwierdzić zasady dla zainstalowanego buildu albo uzgodnić je z Sophos Support; bez rozstrzygnięcia nie wybierać Initiate HA ani nie zmieniać adresów zarządzania.
• 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.
• Unikatowy identyfikator 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. Dlatego przed wymianą urządzenia w nadal działającej parze HA trzeba wyłączyć HA, a następnie skonfigurować je ponownie z urządzeniem zastępczym. Odrębny stan wyjściowy po RMA oraz rozbieżne opisy ponownej instalacji systemu wyjaśniają odpowiednie sekcje poniżej.

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.

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.

Nazwy węzłów w QuickHA: W SFOS 22 nadawanie nazwy jest opcjonalne. W SFOS 23 szczegółowe instrukcje wymagają nazwy węzła, natomiast instrukcje przykładowe nadal określają ją jako opcjonalną. Dlatego poniższa lista kontrolna przewiduje nadanie obu urządzeniom różnych, łatwo rozpoznawalnych nazw. Jest to zachowawcza instrukcja, a nie dowód, że GUI odrzuca puste pole nazwy.

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. Nadać unikatową nazwę węzła, 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. Nadać nazwę węzła inną niż na Primary, 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. Pole wyboru w SFOS 22 nosi nazwę Select ports to be monitored, a w szczegółowych instrukcjach SFOS 23 — Monitored interfaces. 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.

HA działa również bez wybranych Monitored Ports. W takim przypadku sama awaria portu produkcyjnego nie wywołuje failover; utrata sygnałów Heartbeat, awaria urządzenia lub zasilania nadal mogą wywołać zmianę ról. Każdy wybrany port musi być podłączony na obu węzłach. Monitorowanie stanu portów nie wykrywa każdej awarii po stronie operatora sieci nadrzędnej.

Zaawansowane ustawienia HA, takie jak monitorowane interfejsy, administracja urządzeniem równorzędnym, preferowane urządzenie Primary i wartości Keepalive, zmienia się po utworzeniu QuickHA na aktualnym Primary. Wcześniej sprawdzić kopię zapasową, okno serwisowe i zabezpieczony dostęp administracyjny; przy zmianach administracji peera ponownie wykonać opisaną w sekcji Wymagania sieciowe weryfikację sprzecznych instrukcji adresacji i bez rozstrzygnięcia nie zmieniać adresów ani nie wybierać Initiate HA. Opisana powyżej zmiana sposobu używania adresów MAC powoduje przerwę w działaniu. Jeśli łącze HA wykorzystuje LAG, przestrzegać wymogu dotyczącego Keepalive i nie zmieniać wartości w stanie Standalone lub Faulty. Po dokonaniu wyboru przewinąć stronę z powrotem do początku i wybrać Initiate HA. Primary synchronizuje wtedy zmiany z Auxiliary. Następnie na obu węzłach sprawdzić role HA, status, synchronizację i zmienione wartości; w razie rozbieżności najpierw porównać łącze HA i logi obu urządzeń. Ten etap końcowy dotyczy również opisanej poniżej wersji Active-Active i należy go odróżnić od pierwszego dołączenia obu urządzeń do klastra.

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
• identyfikator Cluster ID ma zostać ustawiony ś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ć unikatowy identyfikator 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. Pole w SFOS 22 nosi nazwę Dedicated peer HA link IPv4 address, a w szczegółowych instrukcjach SFOS 23 — Peer IPv4 address of dedicated HA link. Oba adresy łącza HA muszą znajdować się w tej samej podsieci. Jest to adres IP łącza HA, a nie adres administracyjny peera w Peer administration settings; zasady adresacji zarządzania należy zweryfikować zgodnie z opisem powyżej.
5. Wybrać krytyczne Monitored ports; SFOS 23 pozwala na maksymalnie 24.
6. W Peer administration settings wskazać interfejs zarządzania i adres IP dla FW02 dopiero po opisanej w sekcji Wymagania sieciowe weryfikacji sprzecznych instrukcji adresacji dla zainstalowanego buildu. Jeśli zasady pozostają nierozstrzygnięte, zatrzymać się przed zmianą adresów lub Initiate HA.
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 dopuszcza interwały 250–500 ms i liczbę prób od 16 do 24; domyślne 250 ms i 16 prób dają timeout 4 sekund. SFOS 23 dopuszcza interwały 100–500 ms i liczbę prób od 3 do 24; 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.

Rozbieżność w dokumentacji API SFOS 22: Opis Keepalive attempts podaje 8–16 prób, natomiast szczegółowe ograniczenie parametru i przykład XML — 16–24. Podany zakres wynika ze szczegółowego ograniczenia; 8–16 nie jest drugim potwierdzonym zakresem. Przed zmianami udokumentować zainstalowany build SFOS i bieżące wartości Keepalive obu węzłów. Jeśli obowiązujące limity pozostają niejasne, wyjaśnić je z Sophos Support przed wprowadzeniem zmiany; nadal należy przestrzegać wymagań dotyczących LAG.

Wstępna weryfikacja API dla SFOS 22 i 23: Tabele parametrów dokumentują ClusterId jako opcjonalną liczbę całkowitą z zakresu 0–63 z wartością domyślną 0, a NodeName jako wymagany ciąg znaków o długości 1–30 znaków. Nawet przy udokumentowanej wartości domyślnej każdy klaster we wspólnej sieci Layer 2 musi używać własnego identyfikatora Cluster ID, aby uniknąć konfliktów wirtualnych adresów MAC. Te metadane API nie zmieniają opisanych powyżej wskazówek dotyczących opcjonalnego lub wymaganego nadawania nazw w GUI ani nie potwierdzają walidacji w GUI. Tabela używa zapisu ClusterId, a przykład XML — ClusterID; nie wynika z tego ani przetestowane mapowanie tagów, ani działający payload API.

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. Ta procedura jest alternatywą dla opisanego powyżej tworzenia klastra z dwóch istniejących urządzeń, zaczynając od Auxiliary: nowa maszyna wirtualna Spare nie jest wcześniej konfigurowana jako Auxiliary. Automatyczna konfiguracja portu administracyjnego nie rozstrzyga opisanych wyżej sprzecznych wymagań adresacji. Active-Active lub dwie istniejące zapory Virtual/Software nadal wymagają QuickHA albo Interactive mode na obu urządzeniach.

1. Najpierw wykonać opisaną w sekcji Wymagania sieciowe weryfikację sprzecznych instrukcji adresacji administracyjnej; bez rozstrzygnięcia nie zmieniać adresów zarządzania ani nie wybierać Initiate HA. Na istniejącym Primary zezwolić na SSH dla DMZ pod Administration > Device access i w System services > High availability wybrać Primary (active-passive) oraz Interactive mode. W SFOS 23 przed wybraniem Initiate HA wprowadzić Cluster ID i nazwę węzła; instrukcja dla SFOS 22 opisuje wprowadzenie Cluster ID i zmianę nazwy węzła jako opcjonalne. Jeśli w tej samej sieci Layer 2 działa kilka klastrów HA, dla każdego użyć innego identyfikatora Cluster ID, aby zapobiec konfliktom wirtualnych adresów MAC. Bezpiecznie udokumentować Dedicated HA Link, jego własny adres IP i maskę podsieci, zamierzony adres IP peera, Peer Administration i passphrase HA używaną na Primary. Następnie wybrać Initiate HA; w SFOS 23 w tym celu przewinąć stronę z powrotem do początku. Instrukcja Sophos dotycząca Spare dokumentuje w tym miejscu, przed dołączeniem nowej maszyny wirtualnej, komunikat HA could not be enabled oraz tymczasowy status Standalone. Na tym etapie konfiguracji żaden z nich sam w sobie nie dowodzi jeszcze niepowodzenia konfiguracji gotowego klastra.
2. Zainstalować nową zaporę wirtualną z dokładnie tym samym numerem kompilacji 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, która była wcześniej używana na Primary i została bezpiecznie udokumentowana, oraz ten sam interfejs Dedicated HA Link. Dla nowej Spare użyć własnego, wolnego adresu IP, różnego od adresu Primary, w podsieci istniejącego Dedicated HA Link na Primary, z identyczną maską podsieci; adres musi odpowiadać przygotowanemu tam adresowi IP peera. Nie zakładać, że passphrase pochodzi z Auxiliary, która miałaby być już skonfigurowana.
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ć dostęp do Internetu z klienta w sieci LAN.
• 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.

W Active-Active źródłowy adres IP jest pierwszą wskazówką, na którym węźle należy oczekiwać logów: dla kwalifikującego się ruchu TCP parzyste adresy przypadają Primary, a nieparzyste — Auxiliary. Tej wskazówki nie można stosować do wszystkich rodzajów ruchu, w szczególności do rodzajów wykluczonych powyżej z równoważenia obciążenia. Nie zastępuje ona porównania logów z obu urządzeń, szczególnie po zmianie ról.

Dla zdarzeń HA na każdym węźle osobno otwiera się Log viewer > System. Za pomocą Add filter wybrać odpowiedni filtr i wartość dla danego okresu, a następnie zastosować je przyciskiem Add filter. Do szczegółowej analizy na obu urządzeniach otworzyć Diagnostics > Tools > Troubleshooting logs > Select files i wybrać csc.log dla centralnej usługi zarządzającej pozostałymi usługami. Dodatkowo wybrać pliki HA opisane poniżej w sekcji Ważne logi i miejsca diagnostyczne i zapisać każdy pakiet oddzielnie przez Download. Aby odtworzyć przebieg zdarzeń klastra, porównać zapisy obu węzłów, zwracając uwagę na luki czasowe i logi objęte rotacją.

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

FAQ Sophos dotyczące HA dla SFOS 22 i 23 podają ogólny wymóg: wyłączyć HA przed ponowną instalacją systemu, przed wymianą węzła w parze HA oraz przed transferem licencji między węzłami. Jednorazowa passphrase tunelu SSH jest usuwana po jego zestawieniu; dlatego w przypadku nowego urządzenia trzeba wyłączyć HA i skonfigurować je ponownie. Ten wymóg nie zastępuje planowania dla konkretnego przypadku: poniższe szczegółowe opisy ponownej instalacji zawierają rozbieżność w dokumentacji, a procedury RMA zakładają, że sprawny węzeł już działa w stanie Standalone HA. Wcześniej zaplanować kopię zapasową, zapewniony dostęp administracyjny, okno serwisowe i odbudowę; przy korekcie licencji Active-Passive dodatkowo przestrzegać opisanego powyżej warunku dotyczącego numerów seryjnych i ról.

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:

Dostęp przez Fusion od SFOS 22 MR1: Sophos Known Issues, NC-186855, opisuje wyjątek od powyższego ogólnego działania: jeśli HA zostanie wyłączone w interfejsie zapory otwartym przez Sophos Fusion/Central za pośrednictwem FRP-SSO, Auxiliary może pozostać w trybie Standalone z włączonym HA, podczas gdy na Primary HA jest już wyłączone. Powoduje to ryzyko Split Brain. Po wykonaniu tej operacji należy osobno sprawdzić stan HA na obu urządzeniach. Jeżeli stany są niespójne, należy wstrzymać planowaną odbudowę i uzgodnić przywrócenie z Sophos Support przed ponownym uruchomieniem urządzeń jako pary. Sam pomyślny komunikat na Primary nie wystarcza jako kontrola. Na 24 października 2026 wpis nie wskazuje wersji z poprawką.

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 przerwane lub wymagać ponownego nawiązania połączenia.

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:

Active-Active i Bridge-VLAN: Każdy węzeł zapisuje własne logi. W SFOS 22 Active-Active tylko Primary przetwarza ruch odbierany przez interfejsy VLAN skonfigurowane na Bridge Interfaces. Opisy konfiguracji i interfejsów SFOS 23 pomijają to ograniczenie, ale pominięcie nie potwierdza równoważenia obciążenia. Dopóki Sophos Support nie potwierdzi działania dla używanego buildu SFOS 23 i topologii, planować ten ruch zachowawczo wyłącznie na Primary i nie opierać wymiarowania wydajności na jego rozdzielaniu.

Dostęp do kwarantanny: Każdy węzeł przechowuje własną kwarantannę i wysyła własny Quarantine Digest. Administrator zwalnia wiadomość na węźle, który ją przetworzył. Użytkownicy zwalniają wiadomości z kwarantanny przez User Portal. User Portal pokazuje tylko wiadomości z kwarantanny aktualnej Primary.

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

Ponowna instalacja systemu przerywa pracę i według Sophos dotyczy tylko Active-Passive. Wcześniej wykonać system diagnostics show version-info w Device Console na obu węzłach, udokumentować firmware wraz z numerem kompilacji i Initial Primary oraz zapisać aktualną kopię zapasową poza klastrem.

Zakres poniższych procedur: FW1 jest na początku zarówno aktualnym Primary, jak i Initial Primary posiadającym licencje; FW2 jest aktualnym Auxiliary. Nazwy te oznaczają te same fizyczne urządzenia przez cały przebieg procedury, również po zmianie ról. Celem jest ponowne uzyskanie FW1 jako Primary i FW2 jako Auxiliary. Jeśli aktualny Primary i Initial Primary to różne urządzenia, nie improwizować na podstawie tych procedur: najpierw ustalić przypisanie ról i posiadacza licencji na podstawie odpowiedniej instrukcji Sophos lub z pomocą Sophos Support.

Wyjaśnić rozbieżność w dokumentacji przed ponowną instalacją systemu: FAQ dotyczące HA dla SFOS 22 i 23 ogólnie wymagają wyłączenia HA przed ponowną instalacją systemu. Szczegółowe instrukcje Active-Passive opisują natomiast, przy ponownej instalacji Primary oraz obu węzłów, zmianę ról za pomocą Switch to passive device i późniejszą ponowną instalację, bez wskazania oddzielnego kroku Disable HA. Zmiana ról nie jest równoznaczna z wyłączeniem HA; pominięcie tego kroku nie potwierdza ogólnie bezpiecznego wyjątku. Dlatego poniższe szczegółowe procedury pozostają udokumentowanymi, lecz w tym punkcie sprzecznymi sekwencjami działań. Przed ich wykonaniem jednoznacznie zaplanować role, Initial Primary, zainstalowany build, kopię zapasową, przerwę w działaniu i drogę powrotu oraz ustalić właściwą kolejność z Sophos Support, jeśli konieczne jest skorzystanie z tej rozbieżnej procedury szczegółowej. Jeśli kolejność pozostaje niewyjaśniona, zatrzymać się przed zmianą ról lub ponowną instalacją; nie dodawać samowolnie kroku wyłączenia HA do tej sekwencji.

Jeśli FW1 jest zarejestrowane w Central Management, wyrejestrować je przed każdą z trzech procedur. Następnie w tym samym tenancie Sophos Central/Fusion, w My Products > Firewall Management > Firewalls, sprawdzić, czy wpis FW1 już nie istnieje. Dopiero potem przejść do tworzenia kopii zapasowej, wyłączania HA lub zmiany ról. Kontrola ta dotyczy zarejestrowanego zarządzania Firewall Management, a nie tylko Synchronized Security.

Ponowna instalacja tylko Auxiliary FW2

1. Po opisanym powyżej wyrejestrowaniu i kontroli zapisać kopię zapasową FW1 poza klastrem i wyłączyć HA na FW1, nigdy na FW2.
2. W Advanced Shell na FW1 sprawdzić za pomocą service -S | grep msync, czy msync ma stan UNTOUCHED lub STOPPED. W przeciwnym razie nie kontynuować.
3. Ponownie zainstalować FW2 z dokładnie tą samą wersją firmware, łącznie z numerem kompilacji, co FW1. Zalogować się lokalnie i skonfigurować wyłącznie WAN na potrzeby dostępu do Internetu, bez interfejsów LAN ani DMZ. Następnie przypisać FW2 do konta, jeśli nie zostało jeszcze przypisane.
4. Odbudować HA z FW1 jako Primary i FW2 jako Auxiliary.

Ponowna instalacja tylko Primary FW1

1. Po wyrejestrowaniu i kontroli zapisać kopię zapasową FW1 poza klastrem i użyć Switch to passive device, aby FW2 przejęło pracę. Tożsamość urządzeń pozostaje niezmieniona.
2. Ponownie zainstalować FW1 z dokładnie tą samą wersją firmware, łącznie z numerem kompilacji, co FW2. Zalogować się lokalnie, skonfigurować tylko WAN na potrzeby dostępu do Internetu, bez interfejsów LAN ani DMZ, i przypisać FW1 do konta, jeśli nie zostało jeszcze przypisane.
3. Na czas przywracania odłączyć od FW1 wszystkie kable poza połączeniem z komputerem administracyjnym, przywrócić kopię zapasową, ponownie podłączyć kable i skierować ruch z FW2 z powrotem na FW1.
4. Następnie przywrócić FW2 do ustawień fabrycznych. Zalogować się lokalnie, skonfigurować wyłącznie WAN na potrzeby dostępu do Internetu, bez interfejsów LAN ani DMZ, i przypisać urządzenie do konta, jeśli nie zostało jeszcze przypisane.
5. Odbudować HA z FW1 jako Primary i FW2 jako Auxiliary.

Ponowna instalacja i aktualizacja obu węzłów

1. Przeprowadzić wyrejestrowanie, kontrolę, tworzenie kopii zapasowej i zmianę ról tak jak przy ponownej instalacji Primary. Na FW1 zainstalować jednak wersję docelową wraz z docelowym numerem kompilacji. Następnie zalogować się lokalnie, skonfigurować tylko WAN na potrzeby dostępu do Internetu, bez interfejsów LAN ani DMZ, i przypisać urządzenie do konta, jeśli nie zostało jeszcze przypisane.
2. Na czas przywracania odłączyć od FW1 wszystkie kable poza połączeniem z komputerem administracyjnym, przywrócić na nim kopię zapasową, ponownie podłączyć kable i skierować ruch z FW2 z powrotem na FW1.
3. W odróżnieniu od ponownej instalacji samego Primary, na tym etapie nie poprzestawać na przywróceniu FW2 do ustawień fabrycznych: ponownie zainstalować na nim dokładnie tę samą wersję docelową wraz z numerem kompilacji co na FW1. Zalogować się lokalnie, skonfigurować wyłącznie WAN na potrzeby dostępu do Internetu, bez interfejsów LAN ani DMZ, i przypisać urządzenie do konta, jeśli nie zostało jeszcze przypisane.
4. Odbudować klaster Active-Passive z FW1 jako Primary i FW2 jako Auxiliary. Planowana przerwa obejmuje również ten drugi etap ponownej instalacji i dołączenia do klastra.

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. Oba szczegółowe warianty RMA zakładają, że pozostały sprawny węzeł już działa jako Standalone HA: przy RMA Auxiliary jest to sprawny Primary, a przy RMA Primary — sprawny Auxiliary. Tylko dla tego stanu wyjściowego źródła opisują przypisanie urządzenia zastępczego do konta i transfer licencji przed późniejszym wyłączeniem HA lub resetem sprawnego węzła. Nie stosować tej kolejności do wymiany w nadal działającej parze HA; w takim przypadku obowiązuje ogólny wymóg wcześniejszego wyłączenia HA podany w FAQ. Jeśli stan wyjściowy nie jest zgodny z tym założeniem lub jest niejasny, zatrzymać się przed wymianą lub transferem licencji i zaplanować procedurę 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. Najpierw przygotować lokalny dostęp do urządzenia zastępczego. W udokumentowanym przykładzie układu portów podłączyć komputer administracyjny obsługujący DHCP do portu 1 i otworzyć https://172.16.16.16:4444; WAN podłączyć do portu 2 i skonfigurować dostęp do Internetu w Setup Assistant. Jeśli układ portów jest inny, użyć portu administracyjnego i portu WAN zgodnie z modelem urządzenia. Nie konfigurować żadnych innych interfejsów. Dopiero potem przypisać urządzenie zastępcze do konta Sophos Fusion i przenieść licencję uszkodzonego urządzenia 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. Przed kontynuowaniem sprawdzić w tym samym tenancie Sophos Central/Fusion, w My Products > Firewall Management > Firewalls, czy wpis tej sprawnej Auxiliary już nie istnieje.
2. Zainstalować na urządzeniu zastępczym ten sam build firmware i zalogować się lokalnie. W udokumentowanym przykładzie układu portów podłączyć komputer administracyjny obsługujący DHCP do portu 1 i otworzyć https://172.16.16.16:4444; WAN na porcie 2 skonfigurować na potrzeby dostępu do Internetu w Setup Assistant. Jeśli układ portów jest inny, użyć portu administracyjnego i portu WAN zgodnie z modelem urządzenia. Nie konfigurować żadnych innych interfejsów. Dopiero potem przypisać urządzenie do konta Sophos Fusion i przenieść licencję uszkodzonego 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 i ponownie przygotować lokalny dostęp: w udokumentowanym przykładzie układu portów podłączyć komputer administracyjny obsługujący DHCP do portu 1 i otworzyć https://172.16.16.16:4444, a następnie skonfigurować WAN na porcie 2 na potrzeby dostępu do Internetu w Setup Assistant. Jeśli układ portów jest inny, użyć portu administracyjnego i portu WAN zgodnie z modelem urządzenia. Nie konfigurować żadnych innych interfejsów. Dopiero potem ponownie przypisać urządzenie 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 obsługi awarii sprzętu Sophos i procesu 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: Diagnostics > Tools > Troubleshooting logs > Select files 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: Tylko przy opisanej powyżej konfiguracji z nową wirtualną HA spare Sophos dokumentuje ten komunikat bezpośrednio po wybraniu Initiate HA na Primary, przed dołączeniem Spare; opisano tam również tymczasowy status Standalone. Nie oznacza to, że ten komunikat można ogólnie ignorować. Jeśli utrzymuje się po zakończeniu kreatora Spare oraz etapu oczekiwania i odświeżania albo występuje przy innej konfiguracji, Dedicated HA link może nie być podłączony lub drugi węzeł jest niedostępny. Upewnić się, że dedykowane interfejsy łącza HA obu urządzeń są połączone bezpośrednio kablem Ethernet lub przez przewidziany przełącznik. Na obu węzłach w Network > Interfaces sprawdzić, czy wybrany interfejs łącza HA pokazuje stan Connected. Na Primary w Diagnostics > Tools użyć narzędzia Ping do sprawdzenia dedykowanego adresu IP łącza HA Auxiliary, a nie jej adresu Peer Admin. Odpowiedzi potwierdzają podstawową osiągalność, ale nie zakończenie synchronizacji HA. Jeśli brak odpowiedzi, najpierw sprawdzić i skorygować kabel, ścieżkę przez przełącznik, stan łącza oraz adres IP i podsieć łącza HA; następnie powtórzyć Ping i ponownie sprawdzić role oraz synchronizację.

• 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: W /log/syslog.log na Primary wyszukać dokładnie ten komunikat. Sophos wiąże go z portami administracyjnymi, które nie znajdują się w tej samej podsieci; porównać adresy portów administracyjnych obu urządzeń. Dodatkowo, jako odrębny wymóg, sprawdzić, czy adresy łącza HA znajdują się w tej samej podsieci, ale nie traktować ich jako potwierdzonej przyczyny tego komunikatu. Przed skorygowaniem adresacji zarządzania wykonać opisane powyżej czynności przygotowawcze służące wyjaśnieniu sprzeczności w źródłach: udokumentować role, zainstalowany build SFOS, interfejs administracyjny i bieżące adresy IP, zabezpieczyć kopię zapasową i oddzielny dostęp administracyjny przez konsolę lub lokalną ścieżkę oraz zweryfikować obowiązujące zasady adresacji albo uzgodnić je z Sophos Support. Jeśli zachowanie pozostaje niewyjaśnione, zatrzymać się przed zmianą adresów.

• 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.

WebAdmin i VPN Portal niedostępne podczas synchronizacji certyfikatów

Informacje o wydaniu SFOS 22.0 MR3 Build 576 z 16 października 2026 r. wymieniają NC-186809 jako naprawiony: synchronizacja certyfikatów na Auxiliary mogła się nie powieść, jeśli określone nazwy plików certyfikatów zaczynały się od dwóch kolejnych kropek (..); w rezultacie WebAdmin i VPN Portal były niedostępne. Należy odróżnić te objawy od ogólnych problemów z routingiem lub Device Access oraz zapisać build, objęty węzeł, czas i dostępne logi synchronizacji. Nie zmieniać nazw certyfikatów ani nie usuwać ich na podstawie przypuszczeń. Przy uzasadnionym podejrzeniu skontaktować się ze wsparciem i zaplanować obsługiwaną zmianę firmware z zapewnionym dostępem administracyjnym; następnie ponownie sprawdzić oba portale i synchronizację HA.

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.

W tym samym wyniku show network interfaces znaleźć odpowiedni interfejs fizyczny na podstawie jego rzeczywistej nazwy i oprócz stanu łącza sprawdzić dostępne liczniki odrzuconych pakietów (Drops), błędów i kolizji. Nie każdy build pokazuje wszystkie liczniki; brak danych nie oznacza wartości zerowej. Zapisać wynik wraz z oznaczeniem węzła, interfejsu i znacznikiem czasu oraz porównać go z późniejszą obserwacją: rosnące liczniki pomagają zawęzić diagnostykę do problemów z interfejsem, kablem lub negocjacją, ale same nie dowodzą konkretnej przyczyny. Wymianę kabla lub korektę Speed/Duplex wykonywać wyłącznie w kontrolowany sposób, z zapewnionym dostępem administracyjnym i z zachowaniem opisanych powyżej środków ostrożności dotyczących HA i Split-Brain; następnie ponownie porównać liczniki, stan łącza, role i synchronizację. Te liczniki interfejsów należy odróżnić od pakietów odrzucanych przez reguły firewall i związanego z nimi Drop Capture.

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. Przed wykonaniem poleceń porównaj je z pomocą zainstalowanego buildu.

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