Konfiguracja wysokiej dostępności (HA) Sophos Firewall

Wysoka dostępność, w skrócie HA, łączy dwie zapory Sophos w klaster. Celem nie jest uczynienie pojedynczej zapory niezniszczalną, lecz kontrolowane przechwytywanie awarii urządzenia, poszczególnych krytycznych portów lub planowanych prac konserwacyjnych.

Środowisko HA nie zastępuje jednak dobrego projektowania sieci, czystych kopii zapasowych i udokumentowanych procesów konserwacyjnych. Źle zaplanowany klaster może w przypadku awarii być trudniejszy w obsłudze niż pojedyncza zapora. Dlatego ten artykuł wyjaśnia nie tylko, gdzie włączyć HA, ale także jak sensownie zaplanować, skonfigurować, obsługiwać i sprawdzać klaster HA Sophos Firewall w przypadku awarii.

Spis treści

• Podsumowanie
• Przewodniki wideo
• Co oznacza wysoka dostępność na Sophos Firewall
• Active-Passive czy Active-Active
• Role, status i architektura
• Wymagania
• Planowanie i projektowanie
• Przygotowanie do konfiguracji
• Konfiguracja Active-Passive z QuickHA
• Konfiguracja Active-Active z QuickHA
• Ręczna konfiguracja HA
• Walidacja klastra
• Działanie i utrzymanie
• Aktualizacje oprogramowania i kopie zapasowe
• Rozwiązywanie problemów
• Listy kontrolne najlepszych praktyk

Podsumowanie

W większości środowisk produkcyjnych Active-Passive jest lepszym wariantem HA. Jedna zapora przetwarza cały ruch, druga jest gotowa do przejęcia w przypadku awarii lub konserwacji. Projekt jest prostszy, licencjonowanie tańsze, a zachowanie w przypadku awarii łatwiejsze do zrozumienia.

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. Główna zapora nadal przyjmuje ruch i rozdziela określone połączenia do pomocniczej zapory. Nie każda usługa i nie każdy rodzaj ruchu jest rozdzielany.

Przewodniki wideo

Poniższe Sophos Techvids pokazują HA na Sophos Firewall w formie wizualnej. Filmy nie zastępują starannego planowania, ale pomagają lepiej zrozumieć QuickHA, role, statusy i podstawowe zachowanie klastra HA.

Co oznacza wysoka dostępność na Sophos Firewall

Klaster HA Sophos Firewall składa się z dwóch zapór. Urządzenia wymieniają się za pośrednictwem dedykowanego linku HA sygnałami Heartbeat, statusami urządzeń, informacjami o połączeniach i danymi konfiguracyjnymi. Konfiguracja jest synchronizowana z głównej zapory na pomocniczą.

HA chroni przed typowymi awariami:

• Awaria głównej zapory
• Awaria zasilania lub sprzętu
• Awaria monitorowanego interfejsu
• Problem z oprogramowaniem lub usługą, który uniemożliwia działanie urządzenia
• Planowane aktualizacje oprogramowania
• Planowana zmiana ról podczas konserwacji

HA nie rozwiązuje jednak każdego problemu:

• Błędna polityka zapory pozostaje błędna również w klastrze.
• Awaria wspólnego przełącznika może dotknąć obie zapory jednocześnie.
• Wadliwy projekt VLAN lub błędna koncepcja routingu nie zostaną automatycznie skorygowane.
• Logi i raporty nie są w pełni synchronizowane między obiema zaporami.
• Kopia zapasowa pozostaje nadal obowiązkowa.

Planowanie HA powinno poprzedzać dokładne wyjaśnienie podstaw dotyczących stref, interfejsów, VLAN-ów, LAG-ów i mostów. Do tego pasuje instrukcja Planowanie i konfiguracja stref i interfejsów Sophos Firewall.

Active-Passive czy Active-Active

Active-Passive

W trybie Active-Passive jedna zapora przetwarza cały ruch produkcyjny. Druga zapora jest pasywna i przejmuje dopiero wtedy, gdy aktywna zapora ulegnie awarii lub zostanie ręcznie lub w wyniku konserwacji wywołane przełączenie.

Typowe cechy:

• Główna zapora przetwarza ruch.
• Pomocnicza zapora pozostaje w trybie gotowości.
• Sesje są synchronizowane, o ile dana usługa to wspiera.
• Tylko urządzenie posiadające licencję wymaga subskrypcji ochronnych w przypadku urządzeń sprzętowych.
• Pomocnicza zapora przejmuje w przypadku przełączenia z tą samą wirtualną adresem MAC.
• Urządzenia sieciowe zazwyczaj nie muszą ponownie uczyć się sąsiedztw.

Active-Passive jest zazwyczaj najlepszym wyborem dla klasycznych środowisk firmowych, oddziałów, centrów danych i środowisk, w których stabilność jest ważniejsza niż potencjalny zysk wydajności.

Active-Active

W trybie Active-Active obie zapory przetwarzają ruch. Mimo to architektura pozostaje asymetryczna: Główna zapora przyjmuje ruch i decyduje, czy przetworzy połączenie samodzielnie, czy przekaże je do pomocniczej zapory.

Sophos używa do rozdzielania m.in. adresu IP źródła. Połączenia TCP z parzystymi adresami IP źródła są zazwyczaj przetwarzane na głównej zaporze, a nieparzyste adresy IP źródła mogą być przekazywane do pomocniczej. Ruch nie-TCP i niektóre usługi nie są równomiernie rozdzielane.

Typowe cechy:

• Obie zapory mogą przetwarzać ruch.
• Główna zapora pozostaje centralnym punktem wejścia.
• Obie zapory wymagają odpowiednich licencji.
• Nie wszystkie usługi są rozdzielane.
• Logi i raporty są generowane na urządzeniu, które przetwarza dany ruch.
• Rozwiązywanie problemów jest bardziej złożone, ponieważ połączenia mogą trafiać na oba węzły.

Active-Active ma sens, gdy istnieje jasny cel wydajnościowy i wcześniej przetestowano, czy odpowiedni ruch jest faktycznie rozdzielany. Dla czystej wysokiej dostępności Active-Passive jest zazwyczaj bardziej przejrzysty.

Role, status i architektura

Role w klastrze HA

Statusy w działaniu

Wirtualny adres MAC

Sophos Firewall używa w klastrze HA wirtualnych adresów MAC dla interfejsów produkcyjnych. Tylko główna zapora odpowiada na zapytania ARP dla klastra. W przypadku przełączenia pomocnicza zapora przejmuje ten wirtualny adres MAC. Dzięki temu dostępność dla przełączników, routerów i klientów jest bardziej stabilna, ponieważ przypisanie IP i MAC nie zmienia się zasadniczo.

Ważna jest ID klastra. Ta ID jest używana dla wirtualnego adresu MAC. Jeśli kilka klastrów HA działa w tym samym środowisku warstwy 2, każdy klaster musi mieć unikalną ID klastra. W przeciwnym razie mogą wystąpić konflikty MAC.

Co jest synchronizowane

Zachowanie podczas przełączenia

Przełączenie może być wywołane przez różne zdarzenia:

• brak sygnałów Heartbeat przez link HA
• awaria monitorowanego portu
• awaria zasilania
• awaria sprzętu
• problem z oprogramowaniem lub usługą
• planowana zmiana ról
• aktualizacja oprogramowania

Sygnały Heartbeat są przesyłane przez dedykowany link HA. Domyślnie używane są bardzo krótkie interwały. Jeśli kilka sygnałów Heartbeat z rzędu zostanie pominiętych, partner uznawany jest za niedostępny. Następnie zapora sprawdza stan i przeprowadza zmianę ról.

Podczas przełączenia wiele połączeń jest kontynuowanych lub szybko nawiązywanych na nowo. Przełączenie nie jest jednak całkowicie przezroczyste dla każdej aplikacji. Szczególnie połączenia TCP z zachowaniem stanu, sesje internetowe, połączenia proxy lub niektóre scenariusze VPN mogą wymagać krótkiego przerwania lub ponownego nawiązania.

Równoważenie obciążenia w Active-Active

Active-Active nie oznacza, że obie zapory stoją jak dwa równorzędne routery w sieci. Główna zapora pozostaje centralnym punktem wejścia i rozdziela określone połączenia do pomocniczej zapory.

Ważne punkty:

• Równoważenie obciążenia występuje tylko w Active-Active.
• Metoda nie może być dowolnie dostosowywana.
• Zewnętrzne równoważniki obciążenia przed klastrem HA nie są standardowym projektem według Sophos dla tej logiki HA.
• Nie każdy ruch jest rozdzielany.
• Ruch nie-TCP, SD-RED, ruch tunelowany i niektóre funkcje warstwy 7 mogą być traktowane inaczej.
• Rozwiązywanie problemów musi obejmować oba węzły.

W praktyce Active-Active powinno być stosowane tylko wtedy, gdy wcześniej wiadomo, jaki ruch powoduje wąskie gardło i czy dokładnie ten ruch jest rozdzielany.

Obsługiwane i ograniczone usługi

Sophos HA obsługuje większość usług zapory. Niektóre usługi mają jednak szczególne cechy.

Jeśli raportowanie lub przechowywanie logów jest ważne, należy wcześniej zaplanować, czy zostanie użyty zewnętrzny serwer Syslog lub Sophos Central Firewall Reporting. Więcej na ten temat w Aktywacja Central Firewall Reporting.

Wymagania

Przed wdrożeniem należy dokładnie sprawdzić wymagania HA w odniesieniu do własnego środowiska. Szczególnie zgodność modeli, wersja oprogramowania, interfejsy, Cellular WAN i platformy wirtualne to punkty, w których małe odchylenia mogą później mieć duże znaczenie.

Kompatybilność sprzętu i modeli

Wirtualne i programowe aplikacje

Wirtualne lub programowe aplikacje muszą również bardzo dokładnie do siebie pasować.

Wdrożenia w chmurze

W środowiskach chmurowych obowiązują dodatkowe wymagania platformowe. Routing, wirtualne interfejsy, adresy IP, grupy zabezpieczeń, UDR-y lub mechanizmy przełączania awaryjnego specyficzne dla chmury muszą pasować do odpowiedniego projektu chmurowego. Normalne podejście do HA dla urządzeń nie może być bez sprawdzenia przenoszone na Azure, AWS lub inne środowiska chmurowe.

Jeśli zapora Sophos jest uruchamiana w chmurze, przed planowaniem HA należy sprawdzić aktualną dokumentację Sophos dla odpowiedniej platformy i architektury sieci chmurowej.

Licencjonowanie i rejestracja

Licencjonowanie HA różni się w zależności od platformy i trybu HA. Kluczowe są trzy pytania: Czy chodzi o sprzęt czy wirtualne/programowe? Czy używany jest tryb Active-Passive czy Active-Active? I które urządzenie jest Initial Primary, czyli urządzeniem, które posiada licencję dla klastra? Te punkty powinny być sprawdzone przed wdrożeniem z licencjami, numerami seryjnymi i docelowym trybem.

Ważne: W trybie Active-Passive Initial Primary jest szczególnie ważne, ponieważ to urządzenie posiada licencję dla klastra. W widoku HA przy odpowiednim urządzeniu widnieje informacja, że posiada licencję dla klastra. W razie wątpliwości urządzenie to powinno być jednoznacznie udokumentowane w podręczniku operacyjnym.

Jeśli licencje w Active-Active nie są zgodne, według Sophos najpierw zatrzymuje się równoważenie obciążenia. Jeśli różnica utrzymuje się dłużej, HA może zostać wyłączone. Przy pierwszej konfiguracji Active-Active HA z nieodpowiednimi licencjami nie zostanie poprawnie aktywowane. Dlatego kontrola licencji jest obowiązkowa w rutynowej eksploatacji.

W przypadku wirtualnych/programowych aplikacji licencja Base Firewall jest szczególnie krytyczna. Jeśli zostanie wyłączona lub Initial Primary nie może synchronizować licencji przez dłuższy czas, HA może zostać wyłączone, a inne funkcje ochronne staną się nieaktywne. Istotna jest tutaj synchronizacja z serwerem licencji co najmniej raz na 90 dni. Dla środowisk produkcyjnych oznacza to: Klaster HA musi nie tylko działać technicznie, ale także regularnie osiągać serwer licencji.

Dla eksploatacji należy co najmniej udokumentować:

• które urządzenie jest Initial Primary
• jakie numery seryjne lub ID urządzeń należą do klastra
• jakie licencje są aktywne na którym urządzeniu
• kiedy licencje były ostatnio synchronizowane
• jaki poziom wsparcia jest dostępny dla RMA lub zaawansowanej wymiany
• kto zatwierdza zmiany licencji, odnowienia i procesy RMA

Wymagania sieciowe

Link HA nie przetwarza normalnego ruchu klienta ani serwera. Jest używany tylko do sygnałów Heartbeat, statusu, synchronizacji sesji, synchronizacji konfiguracji i rozdzielania w Active-Active. Mimo to jest niezwykle krytyczny. Jeśli link HA ulegnie awarii, obie zapory mogą uważać się za główne. Dokładnie tego scenariusza Split-Brain należy unikać.

Porty i interfejsy

Jako dedykowany link HA można używać interfejsów fizycznych, VLAN-ów lub LAG-ów. Interfejsy mostkowe i adresy IP aliasów nie mogą być używane jako dedykowany link HA. Jeśli LAG jest używany jako link HA, interfejsy nadrzędne muszą być identycznie skonfigurowane na obu urządzeniach.

Planowanie i projektowanie

Zalecana topologia dla Active-Passive

Typowy projekt Active-Passive wygląda tak:

• obie zapory znajdują się w tym samym racku lub w blisko położonych rackach
• wszystkie interfejsy produkcyjne są identycznie podłączone
• WAN jest podłączony do redundantnych przełączników lub dobrze udokumentowanych przejść dostawcy
• LAN/DMZ są podłączone do redundantnych struktur przełączników
• link HA jest połączony bezpośrednio
• przewidziany jest osobny dostęp do zarządzania lub administracji
• porty WAN i rdzeniowe/DMZ są zdefiniowane jako monitorowane porty

Najważniejszy punkt: Druga zapora musi w przypadku awarii przejąć tę samą pozycję w sieci. Dlatego VLAN-y, trunki, LAG-i, porty przełączników i połączenia dostawcy muszą być konsekwentnie zaplanowane.

Zalecana topologia dla Active-Active

Active-Active wymaga tej samej fizycznej czystości co Active-Passive, ale dodatkowo jasnego oczekiwania co do rozdzielanego ruchu.

Przed Active-Active należy odpowiedzieć:

• Jaki ruch jest wąskim gardłem?
• Czy dokładnie ten ruch jest rozdzielany w Active-Active?
• Czy obie zapory są w pełni i odpowiednio licencjonowane?
• Czy logi, raporty i procesy rozwiązywania problemów są przygotowane na oba węzły?
• Czy istnieją usługi, takie jak VPN, NDR, Synchronizowana kontrola aplikacji lub scenariusze proxy, które przemawiają przeciwko Active-Active?

Bez jasnej odpowiedzi Active-Passive jest lepszym wyborem.

LAN, WAN, DMZ i link HA

Do zabezpieczenia lokalnych usług zapory pasuje Zabezpieczenie dostępu do Sophos Firewall: Prawidłowa konfiguracja Device Access.

Wymagania dotyczące przełączników

Przełączniki są często niewidocznym czynnikiem ryzyka w HA. Klaster HA działa tylko tak dobrze, jak środowisko warstwy 2 pod nim.

Rekomendacje:

• Włączyć RSTP na zaangażowanych przełącznikach.
• Konfigurować trunki identycznie na obu zaporach.
• Konsystentnie zezwalać na VLAN-y na wszystkich zaangażowanych portach.
• Budować LAG-i identycznie.
• Nie wybierać niekompletnych lub nieużywanych monitorowanych portów.
• Link HA połączyć możliwie bezpośrednio.
• Jeśli link HA przechodzi przez przełączniki, ścieżka musi być stabilna, o niskim opóźnieniu i bez utraty pakietów.

VLAN-y, LAG-i, mosty i RED

VLAN-y i LAG-i są możliwe w HA, ale zwiększają wymagania dotyczące planowania. Klaster HA nie powinien być pierwszym miejscem, w którym testuje się projekt VLAN lub LAG.

Unikanie Split-Brain

Split-Brain oznacza, że obie zapory uważają się za aktywne lub samodzielne odpowiedzialne. Może się to zdarzyć, gdy link HA ulegnie awarii, ale urządzenia nadal znajdują się w sieci produkcyjnej.

Środki:

• Nie prowadzić linku HA przez niepewne lub niestabilne ścieżki przełączników.
• Preferować bezpośrednie połączenie dla linku HA.
• Świadomie wybierać monitorowane porty.
• Konfigurować RSTP czysto.
• Unikać asymetrycznego okablowania.
• Sprawdzać status HA po każdej zmianie przełącznika lub VLAN-u.
• Dostosowywać wartości Keepalive tylko z uzasadnieniem.

Przygotowanie do konfiguracji

Przed konfiguracją HA nie należy improwizować w sieci produkcyjnej. To przygotowanie oszczędza później dużo czasu.

Przygotowanie obu zapór

• Obie zapory na tę samą wersję SFOS, w tym kompilację.
• Sprawdzić status licencji i rejestracji.
• Wyłączyć Cellular WAN.
• Upewnić się, że modele są kompatybilne.
• Sprawdzić wyposażenie portów Flexi.
• Udokumentować interfejsy i porty przełączników.
• Określić port linku HA.
• Bezpośrednio połączyć link HA lub sprawdzić ścieżkę przełącznika.
• Zaplanować strefę DMZ i dostęp SSH dla linku HA.
• Udokumentować dostęp administracyjny do obu urządzeń.
• Utworzyć kopię zapasową istniejącej konfiguracji.

Kopie zapasowe nie są opcjonalne w HA. Przed konfiguracją, przed aktualizacjami oprogramowania i przed większymi zmianami interfejsów powinna być dostępna kopia zapasowa. Podstawy znajdują się w Tworzenie lub przywracanie kopii zapasowej Sophos Firewall.

QuickHA lub ręczna konfiguracja

QuickHA rozpoznaje partnera przez wybrane interfejsy linku HA. Gdy urządzenia się znajdą, klaster jest tworzony. Hasło jest używane do utworzenia zaszyfrowanego tunelu SSH i nie jest traktowane jako ponownie używane hasło. Jeśli urządzenie zostanie wymienione, HA musi zostać wyłączone i ponownie skonfigurowane.

Opisane tutaj kroki są oparte na oficjalnej konfiguracji HA Sophos, ale są świadomie sformułowane jako praktyczna lista kontrolna dla administratora. Dla zmian produkcyjnych nie należy tylko klikać przez kreatora, ale wcześniej udokumentować role, link HA, dostęp administracyjny, kopię zapasową, status licencji i drogę powrotną.

Konfiguracja Active-Passive z QuickHA

1. Przygotowanie głównej zapory

1. Zalogować się do WebAdmin na przyszłej głównej zaporze.
2. Przejść do System services > High availability.
3. Wybrać tryb Primary (active-passive).
4. Użyć QuickHA.
5. Opcjonalnie nadać nazwę węzła, na przykład FW01.
6. Ustawić hasło HA.
7. Bezpiecznie przechować hasło, ponieważ będzie potrzebne na pomocniczej zaporze.
8. Wybrać dedykowany link HA.
9. Rozpocząć Initiate HA.

Uwagi:

• Link HA nie może mieć zależności produkcyjnych.
• Jeśli QuickHA używa nieprzypisanego interfejsu, Sophos przypisuje temu interfejsowi strefę DMZ i ustawia specyficzne ustawienia HA.
• Link HA używa statycznych adresów IP w zakresie lokalnym, jeśli QuickHA używa wartości domyślnych.
• SSH musi być dozwolone dla strefy linku HA, ponieważ tunel HA jest przez niego tworzony.

2. Przygotowanie pomocniczej zapory

1. Zalogować się do pomocniczej zapory.
2. Przejść do System services > High availability.
3. Wybrać rolę Auxiliary.
4. Użyć QuickHA.
5. Opcjonalnie nadać nazwę węzła, na przykład FW02.
6. Wprowadzić to samo hasło HA.
7. Wybrać ten sam port linku HA co po stronie głównej.
8. Rozpocząć Initiate HA.

Po utworzeniu klastra główna zapora synchronizuje konfigurację z pomocniczą zaporą. Na pomocniczej zaporze wiele lokalnych ustawień zostanie nadpisanych. Dlatego pomocnicza zapora nie powinna być konfigurowana równolegle jako samodzielna zapora produkcyjna przed konfiguracją HA.

3. Sprawdzenie zaawansowanych ustawień

Po utworzeniu klastra nie należy po prostu klikać dalej, ale sprawdzić następujące punkty:

• Status HA obu węzłów
• Rola i status w prawym górnym rogu WebAdmin
• Dedykowany link HA
• Monitorowane porty
• Port administracyjny partnera
• Preferowane główne
• Interwał Keepalive i próby
• Posiadacz licencji w trybie Active-Passive
• Rejestracja w Sophos Central, jeśli używana

4. Ustawienie monitorowanych portów

Monitorowane porty decydują, czy awaria interfejsu wywoła przełączenie. Typowe kandydaty:

• Uplink WAN
• Uplink rdzeniowy LAN
• Ważne uplinki DMZ lub serwerowe

Nie należy monitorować portów, które czasami są świadomie offline, nie są podłączone lub są używane tylko w opcjonalnych scenariuszach. Źle ustawiony monitorowany port jest częstą przyczyną nieoczekiwanych przełączeń lub nieuruchamiającego się klastra.

Konfiguracja Active-Active z QuickHA

Active-Active jest konfigurowane podobnie, ale z innym celem. Przedtem obie zapory muszą być odpowiednio licencjonowane.

1. Wstępne sprawdzenie

• Obie zapory mają odpowiednie licencje.
• Typy licencji są zgodne.
• Oba urządzenia są zarejestrowane.
• Oba urządzenia działają na tej samej wersji SFOS, w tym kompilacji.
• Odpowiedni ruch faktycznie korzysta z Active-Active.
• Usługi z ograniczeniami Active-Active zostały sprawdzone.
• Monitorowanie i rozwiązywanie problemów są przygotowane na oba węzły.

2. Konfiguracja głównej zapory

1. Przejść do System services > High availability.
2. Wybrać Primary (active-active).
3. Użyć QuickHA.
4. Nadać nazwę węzła.
5. Ustawić hasło HA.
6. Wybrać dedykowany link HA.
7. Rozpocząć HA.

3. Konfiguracja pomocniczej zapory

1. Na drugim urządzeniu przejść do System services > High availability.
2. Wybrać Auxiliary.
3. Użyć QuickHA.
4. Wprowadzić to samo hasło.
5. Wybrać ten sam port linku HA.
6. Rozpocząć HA.

4. Testowanie po konfiguracji

W Active-Active trzeba przetestować więcej niż tylko 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 ochrona sieci Web, IPS, kontrola aplikacji i odpowiednie funkcje bezpieczeństwa działają?
• Czy są aplikacje, które wyróżniają się asymetrycznym zachowaniem?
• Czy raporty i alerty są generowane zgodnie z oczekiwaniami?

Ręczna konfiguracja HA

Ręczna konfiguracja HA jest sensowna, gdy automatyczna logika QuickHA nie zapewnia wystarczającej kontroli.

Typowe powody:

• mają być używane stałe adresy IP linku HA
• port administracyjny partnera musi być dokładnie zdefiniowany
• ID klastra ma być świadomie ustawione
• istnieje kilka klastrów HA w tym samym środowisku warstwy 2
• wirtualne aplikacje mają być używane z określonymi opcjami MAC
• konieczne jest bardzo kontrolowane wdrożenie

Podczas ręcznej konfiguracji najpierw przygotowuje się pomocniczą zaporę, a następnie konfiguruje główną zaporę. Główna zapora musi znać adres IP linku HA partnera.

Ważne pola:

Walidacja klastra

Po konfiguracji klaster HA powinien być systematycznie sprawdzany.

Sprawdzenie WebAdmin

1. Zalogować się do głównej zapory.
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 trybie Active-Passive sprawdzić, które urządzenie posiada licencję dla klastra.

Sprawdzenie CLI

W konsoli urządzenia można wyświetlić status HA:

system ha show details

Jeśli nie jest jasne, które urządzenie jest licencjonowanym Initial Primary, w powłoce zaawansowanej ten wartość może pomóc:

nvram get "#li.master"

YES oznacza urządzenie główne, NO urządzenie pomocnicze. Takie polecenia należy dokumentować i używać tylko w jasnych przypadkach konserwacji lub diagnostyki.

Jeśli dostęp do powłoki nie jest jeszcze przygotowany, pomocna jest instrukcja Łączenie z Sophos Firewall przez SSH.

Test funkcjonalny

• Testować klienta z LAN do Internetu.
• Testować dostęp do wewnętrznych serwerów.
• Testować VPN.
• Testować scenariusze DNAT lub WAF.
• Testować DNS i DHCP, jeśli zapora świadczy te usługi.
• Sprawdzać logi w Log Viewer.
• Testować przełączenie ról HA w oknie konserwacyjnym.
• Następnie dokumentować role, status i zachowanie sesji.

Działanie i utrzymanie

Ciągłe monitorowanie

Klaster HA powinien być aktywnie monitorowany. Tylko dlatego, że dwie zapory stoją w racku, środowisko nie jest automatycznie wysokodostępne.

Należy monitorować:

• Status HA
• Status ról Primary/Auxiliary
• Link HA
• Monitorowane porty
• Status licencji i subskrypcji
• Wersje oprogramowania
• Zasoby, takie jak CPU, RAM, dysk
• Centralne usługi, takie jak IPS, Web, VPN, DNS, DHCP
• Logi w Log Viewer
• Alerty w Sophos Central lub przez e-mail

Dla tematów związanych z dyskiem i sprzętem należy rozpatrywać oba węzły osobno. Lokalne raporty, pliki logów i stan SSD mogą się różnić. Do tego pasują artykuły Sprawdzanie miejsca na dysku i zarządzanie raportami Sophos Firewall i Sprawdzanie zdrowia SSD Sophos Firewall za pomocą SMART.

Logi i raporty

Logi i raporty nie są po prostu łączone w jeden wspólny lokalny zbiór danych. Każde urządzenie zapisuje logi dla ruchu, który przetwarza. W Active-Active jest to szczególnie ważne, ponieważ ruch może pojawiać się na obu węzłach.

Sophos Central Firewall Reporting jest pomocne w środowiskach HA, ponieważ może centralnie analizować dane z kilku zapór. Lokalne logi do rozwiązywania problemów można znaleźć na samej zaporze. Artykuł Rozwiązywanie problemów z usługami i logami Sophos Firewall wyjaśnia, które usługi i pliki logów są istotne dla analiz.

Runbook dla działania HA

Klaster HA potrzebuje krótkiego runbooka operacyjnego. Powinno w nim być zapisane, które urządzenie jest Initial Primary, które porty są monitorowane, jak uzyskać dostęp do pomocniczej, kto zatwierdza aktualizacje oprogramowania i kiedy HA jest wyłączane dla wymiany lub ponownego obrazu.

Należy co najmniej udokumentować:

• Numer seryjny, lokalizację, pozycję w racku i rolę obu urządzeń.
• Dedykowany link HA, port administracyjny partnera, ID klastra i monitorowane porty.
• Preferowane główne i oczekiwane zachowanie po przełączeniu.
• Posiadacza licencji, status wsparcia i kontakt do RMA.
• Procedurę aktualizacji oprogramowania, kopii zapasowej, ponownego obrazu i wymiany sprzętu.
• Osobę odpowiedzialną za logi, Central Reporting, Syslog i przypadki wsparcia.

Jeśli tylko WebAdmin na jednym węźle nie działa, nie oznacza to automatycznie, że cały klaster HA jest uszkodzony. Wtedy należy celowo sprawdzić, czy Ponowne uruchomienie GUI WebAdmin lub kontrolowane ponowne uruchomienie usługi wystarczy, zanim wywoła się przełączenie lub ponowne uruchomienie.

Zmiany w klastrze

Zmiany konfiguracyjne są dokonywane na głównej zaporze. Pomocnicza zapora nie jest miejscem dla normalnych zmian zasad, interfejsów czy polityk.

Przed większymi zmianami:

• Utworzyć kopię zapasową.
• Zdefiniować okno konserwacyjne.
• Sprawdzić status HA.
• Zaktualizować dokumentację.
• Określić drogę powrotu.
• Po zmianie przetestować synchronizację i ruch.

Dotyczy to szczególnie:

• Interfejsów
• VLAN-ów
• LAG-ów
• Stref
• Routingu
• NAT
• VPN
• Dostępu do urządzeń
• SD-WAN

Aktualizacje oprogramowania i kopie zapasowe

Aktualizacje oprogramowania w środowiskach HA

Aktualizacje oprogramowania są uruchamiane na głównej zaporze. Urządzenia są aktualizowane kolejno, a klaster może podczas tego procesu zmieniać role.

Typowy przebieg:

1. Rozpocząć aktualizację na głównej zaporze.
2. Pomocnicza zapora jest aktualizowana.
3. Pomocnicza zapora uruchamia się ponownie i tymczasowo przejmuje.
4. Dotychczasowa główna zapora jest aktualizowana.
5. Dotychczasowa główna zapora uruchamia się ponownie.
6. Jeśli preferowane główne jest aktywne, może nastąpić powrót do preferowanego urządzenia.

Mimo to: Aktualizacje oprogramowania należą do okna konserwacyjnego. Nawet jeśli proces jest zaprojektowany na minimalne przestoje, niektóre sesje, połączenia VPN lub specjalne aplikacje mogą krótko reagować.

Do przygotowania pasuje Aktualizacja oprogramowania Sophos Firewall - Przygotowanie i najlepsze praktyki.

Aktualizacje wzorców

Aktualizacje wzorców są instalowane na głównej zaporze i synchronizowane z pomocniczą zaporą. Dotyczy to również środowisk, w których aktualizacje są kontrolowane lub wgrywane offline.

Jeśli klaster HA jest uruchamiany w izolowanym środowisku, przed każdą ręczną aktualizacją wzorców lub licencji powinno być jasne, który węzeł jest Initial Primary i który węzeł jest aktualnie główny. Przebieg Air-Gap jest opisany w Obsługa licencjonowania i aktualizacji wzorców Sophos Firewall Air-Gap.

Kopia zapasowa i przywracanie

Kopia zapasowa i przywracanie mają w środowiskach HA szczególne cechy:

• Kopie zapasowe powinny być tworzone regularnie i przed każdą większą zmianą.
• Przywracanie odbywa się na aktualną główną zaporę.
• Po przywróceniu obie zapory są wyrejestrowane z Sophos Central i muszą być ponownie zarejestrowane.
• Przywracanie powoduje ponowne uruchomienie i przestój, a nie normalne przełączenie.
• Jeśli kopia zapasowa bez konfiguracji HA zostanie przywrócona na klaster HA, HA zostanie wyłączone i musi być ponownie skonfigurowane.

Wymiana węzła klastra

Podczas wymiany lub ponownego obrazu węzła HA nie powinno być po prostu kontynuowane z starym partnerem.

Ważne punkty:

• Przed ponownym obrazem lub wymianą wyłączyć HA.
• Udokumentować wersję oprogramowania i kompilację.
• Utworzyć kopię zapasową.
• Zidentyfikować posiadacza licencji.
• Usunąć urządzenie z zarządzania Sophos Central, jeśli ma być zwrócone lub wymienione.
• Zarejestrować nowe urządzenie.
• Ponownie skonfigurować HA, ponieważ stare hasło HA nie może być ponownie używane dla nowego urządzenia.

Jeśli wymieniany jest Auxiliary, zdrowy Primary zwykle działa najpierw dalej jako standalone HA device. Jeśli wymieniany jest Primary, trzeba szczególnie dokładnie ustalić, które urządzenie było Initial Primary, który backup zostanie użyty i kiedy kable zostaną przełączone na urządzenie zastępcze. W obu przypadkach należy udokumentować model, hardware revision, firmware version, build, transfer licencji, status Sophos Central i status msync. Usługa i właściwy plik logu są omówione w artykule Sophos Firewall Troubleshooting: Services i logi.

Do technicznej nowej instalacji pasuje Ponowna instalacja systemu operacyjnego Sophos Firewall: Ponowne obrazowanie za pomocą pamięci USB. Jeśli istnieje problem sprzętowy lub proces RMA, należy dodatkowo zaplanować Przygotowanie do awarii sprzętu i RMA Sophos.

Rozwiązywanie problemów

W przypadku głębokich problemów należy zachować strukturę: najpierw sprawdzić status, link HA, monitorowane porty, wersję oprogramowania i status licencji, a dopiero potem sięgnąć po przypadki specjalne lub wskazówki producenta. Dzięki temu jest jasne, czy istnieje prawdziwy problem HA, czy też błąd jest spowodowany licencją, interfejsem, wersją oprogramowania lub monitorowaniem.

Ważne logi i miejsca diagnostyczne

W przypadku głębszych analiz często pomocny jest artykuł Rozwiązywanie problemów z CLI Sophos Firewall: ważne polecenia.

Tabela rozwiązywania problemów

Postępowanie w przypadku awarii linku HA

Jeśli dedykowany link HA ulegnie awarii, należy zachować ostrożność. Obie zapory mogą się wzajemnie nie widzieć. W niekorzystnym przypadku oba urządzenia wysyłają ARP/GARP i próbują przejąć adres MAC klastra dla siebie.

Bezpieczne postępowanie:

1. Ustabilizować stan sieci.
2. Zdecydować, które urządzenie ma pozostać aktywne.
3. Kontrolowane wyłączenie drugiego urządzenia lub odłączenie od sieci produkcyjnej.
4. Naprawa kabla linku HA, portu przełącznika, VLAN-u lub LAG-u.
5. Ponowne uruchomienie urządzenia.
6. Sprawdzenie statusu HA.
7. Kontrola logów i ról.

Istotne polecenia CLI

system ha show details

Wyświetla szczegóły HA w konsoli urządzenia.

show network interfaces

Pomaga w statusie interfejsu i informacjach o linku.

nvram get "#li.master"

Wyświetla w powłoce zaawansowanej, czy urządzenie jest licencjonowanym Initial Primary.

dmesg | grep PortE

Może w przypadku określonych problemów sprzętowych/interfejsowych dostarczyć wskazówek na temat fluktuacji linku.

Nie każde polecenie pasuje do każdej sytuacji. Dla systemów produkcyjnych obowiązuje: Najpierw dokumentować stan, potem celowo sprawdzać.

Listy kontrolne najlepszych praktyk

Planowanie

• Sprawdzić Active-Passive jako standardowy wariant.
• Używać Active-Active tylko z jasnym celem wydajnościowym.
• Sprawdzić oba urządzenia pod kątem modelu, oprogramowania, portów Flexi i licencjonowania.
• Dedykowany link HA połączyć bezpośrednio i możliwie bezpośrednio.
• Świadomie wybierać monitorowane porty.
• Planować dostęp do zarządzania dla głównej i pomocniczej.
• Jednoznacznie dokumentować ID klastra.
• Dokumentować projekt przełączników, VLAN-ów i LAG-ów.
• Zaplanować RSTP na odpowiednich przełącznikach.
• Przemyśleć scenariusz Split-Brain.
• Dokumentować proces kopii zapasowej i przywracania.

Wdrożenie

• Przedtem utworzyć kopię zapasową.
• Doprowadzić obie zapory do tej samej wersji SFOS.
• Wyłączyć Cellular WAN.
• Przygotować link HA z adresacją statyczną i strefą DMZ.
• Zezwolić na SSH dla strefy linku HA.
• Czysto nazwać główną i pomocniczą.
• Używać hasła tylko do konfiguracji i nie traktować go jako trwałego hasła administratora.
• Po QuickHA sprawdzić zaawansowane ustawienia.
• Ustawiać monitorowane porty dopiero wtedy, gdy jest jasne, które linki są stabilne i krytyczne.
• Testować przełączenie w oknie konserwacyjnym.

Działanie

• Regularnie sprawdzać status HA.
• Monitorować licencje i synchronizację.
• Przeprowadzać aktualizacje oprogramowania tylko przygotowane i z oknem konserwacyjnym.
• Regularnie testować kopie zapasowe.
• Dokonywać zmian konfiguracyjnych tylko na głównej zaporze.
• Po zmianach przełączników, VLAN-ów lub interfejsów sprawdzać status HA.
• Uwzględniać logi obu węzłów.
• Używać Sophos Central Firewall Reporting lub Syslog do dłuższych analiz.
• Wymianę lub ponowne obrazowanie węzła przeprowadzać tylko z zaplanowanym wyłączeniem HA i ponowną konfiguracją.

Don’ts

• Nie klastrować różnych modeli.
• Nie planować modeli Wi-Fi XGS dla HA.
• Nie pozostawiać Cellular WAN aktywnego w HA.
• Nie ustawiać niepodłączonych portów jako monitorowanych portów.
• Nie używać niestabilnego VLAN-u lub ścieżki przełącznika jako linku HA.
• Nie prowadzić przez link HA usług produkcyjnych.
• Nie traktować Active-Active jako prostego podwojenia wydajności.
• Nie oczekiwać ani nie planować zmian na pomocniczej zaporze.
• Nie przeprowadzać przywracania bez okna konserwacyjnego.

FAQ