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

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.

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ę.
• Po failover Auxiliary Firewall przejmuje ten sam wirtualny adres MAC.
• 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 między innymi źródłowy adres IP: połączenia TCP z parzystych adresów źródłowych zwykle obsługuje Primary, a z nieparzystych mogą trafić do Auxiliary. Rozdzielane są przekazywane lub translacjonowane połączenia TCP. 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ę.
• Preferred primary: preferowane urządzenie, które po failover ma ponownie zostać Primary, gdy będzie stabilnie dostępne.

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

Sophos Firewall używa w klastrze HA wirtualnych adresów MAC dla interfejsów produkcyjnych. 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.

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 są przesyłane przez dedykowane łącze HA. Domyślnie używane są bardzo krótkie interwały. Jeśli kilka kolejnych sygnałów nie dociera, drugi węzeł zostaje uznany za niedostępny. Następnie zapora ocenia stan i przeprowadza zmianę ról.

Po failover wiele połączeń jest kontynuowanych lub szybko zestawianych ponownie. Nie dla każdej aplikacji proces jest jednak całkowicie przejrzysty. Szczególnie stateful TCP, sesje webowe, połączenia proxy i niektóre scenariusze VPN mogą zostać na krótko przerwane lub wymagać ponownego zestawienia.

Obsługiwane i ograniczone usługi

Sophos HA obsługuje większość usług firewall, ale niektóre mają szczególne wymagania.

• Reguły firewall i NAT są synchronizowane. W Active-Active trzeba wiedzieć, który węzeł obsługuje dane połączenie.
• VPN działa w wielu scenariuszach HA, ale nie każdy typ sesji przełącza się bez przerwy. IPsec może lepiej przejąć stateless UDP/ICMP niż stateful TCP.
• Web Protection działa w klastrze. W Active-Active alerty mogą pochodzić z obu węzłów.
• Email Protection może działać zależnie od węzła przy kwarantannie i zwalnianiu wiadomości, ponieważ każde urządzenie przechowuje własne dane dla obsługiwanego ruchu pocztowego.
• Synchronized Application Control nie nadaje się do Active-Active, jeśli używana wersja SFOS nie obsługuje tej funkcji.
• NDR Essentials w środowiskach HA należy planować tylko z Active-Passive.
• sFlow w środowiskach HA działa tylko na Primary.
• Raporty są generowane lokalnie na każdym urządzeniu. Połączone raporty lepiej realizować przez Sophos Central Firewall Reporting.
• Cellular WAN musi być wyłączony dla HA.
• Modele XGS Wi-Fi nie obsługują HA.

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.

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 XGS, na przykład XGS 2100 z XGS 2100.
• Rewizja sprzętowa: różne rewizje sprzętowe są możliwe przy tym samym modelu XGS.
• Modele XGS 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ń, liczba Flexi Ports na obu urządzeniach musi być taka sama.
• 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.

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

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.

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, a urządzenia Virtual/Software muszą posiadać odpowiednią licencję.
• 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 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: przy wymianie sprzętu oraz Advance Replacement ważny jest status wsparcia. Dla sprzętu w Active-Passive Sophos wskazuje Enhanced Plus Support na Primary jako istotny warunek Advance Hardware Replacement. W Active-Active status wsparcia musi być odpowiedni na obu urządzeniach.

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.

Jeśli licencje Active-Active różnią się, równoważenie obciążenia zatrzymuje się na maksymalnie trzy dni. Jeśli rozbieżność nadal występuje, zapora wyłącza HA. Podczas konfiguracji początkowej Active-Active nie zostanie aktywowane z niezgodnymi licencjami.

Initial Primary musi synchronizować licencje 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 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 synchronizowano licencje
• 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.

Łą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. 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. Porty administracyjne obu urządzeń muszą znajdować się w tej samej podsieci, ale używać różnych adresów IP. QuickHA automatycznie przejmuje do tego interfejs, przez który działa bieżąca sesja WebAdmin. Po utworzeniu HA dostęp do Auxiliary jest możliwy tylko przez adres Peer Admin z odpowiedniej sieci.

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.

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

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.

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 Central, 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.

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

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.
6. W Peer administration settings wskazać interfejs zarządzania i oddzielny adres IP dla FW02.
7. W przypadku urządzeń wirtualnych w razie potrzeby wybrać adres MAC przypisany przez hosta lub hypervisor. Późniejsza zmiana 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. Domyślnie zapora wysyła sygnał Heartbeat co 250 milisekund i uznaje drugi węzeł za niedostępny po 16 brakujących sygnałach.

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

Urządzenie będące licencjonowanym Initial Primary sprawdza się przede wszystkim w System services > High availability. W udokumentowanym przypadku wsparcia może dodatkowo pomóc następująca wewnętrzna wartość tylko do odczytu w Advanced Shell:

nvram get "#li.master"

YES zwykle oznacza Initial Primary, a NO Auxiliary. Sophos nie dokumentuje tego wewnętrznego polecenia Advanced Shell jako standardowego interfejsu administracyjnego, dlatego widok HA pozostaje źródłem referencyjnym.

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 Central, 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.

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

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.

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 i przywracanie mają w środowisku HA szczególne właściwości:

• Kopię zapasową należy tworzyć regularnie i przed każdą większą zmianą.
• Przywracanie wykonuje się na aktualnej Primary Firewall.
• Po przywróceniu obie zapory zostają wyrejestrowane z Sophos Central i trzeba je ponownie zarejestrować.
• Przywracanie powoduje ponowne uruchomienie i przerwę w działaniu, a nie zwykły failover.
• Jeśli kopia bez konfiguracji HA zostanie przywrócona na klaster HA, HA zostanie wyłączone i trzeba je utworzyć ponownie.
• Przy włączonym LINCE kopia zapasowa i klaster docelowy muszą mieć ten sam status LINCE.

Jeśli klaster korzysta z Sophos Central 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 Central 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 Central.
2. Zainstalować na urządzeniu zastępczym ten sam build firmware, przypisać je do konta Sophos Central 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 Central 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 XGS.
• 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: Speed/Duplex lub Auto-Negotiation mogą być niezgodne. Sprawdzić Interface Advanced settings na obu urządzeniach i ustawić je identycznie albo użyć stałego portu.

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

Oficjalne źródła: Rejestracja i licencje · LINCE w środowiskach HA · RMA w klastrze Active-Passive · FAQ HA