Tak naprawdę żadne z dostępnych na rynku rozwiązań HA nie może w pełni zagwarantować, że wszystkie sesje przechodzące przez urządzenie firewall, które uległo awarii, zostaną poprawnie przejęte i utrzymane na innym, sprawnym urządzeniu. Większość rozwiązań HA może jedynie zapewnić poprawne przyjmowanie nowych sesji na działających urządzeniach. Sesje istniejące na urządzeniu, które uległo awarii, bywają niejednokrotnie blokowane. Przede wszystkim wynika to z faktu, że stan serwisów firewall odpowiedzialnych za wykonywanie kontroli na poziomie aplikacji (tzw. firewall proxy) - będących procesami systemu operacyjnego - nie może być synchronizowany w czasie rzeczywistym. Z kolei stan mechanizmów filtracji pakietów i VPN jest synchronizowany co pewien czas, np. 100 ms. Do tego dochodzą opóźnienia powstające na interfejsach. Może więc się zdarzyć sytuacja, w której np. informacja o zaakceptowanej przez jedno urządzenie sesji TCP (SYN) nie zostanie na czas przekazana do pozostałych urządzeń klastra i w czasie jego awarii kolejny pakiet sesji (SYN/ACK) zostanie odrzucony. Nie można zagwarantować, że taka sesja TCP zostanie przez aplikację ponownie zsynchronizowana i utrzymana.

W zależności od przyjętej polityki bezpieczeństwa, wykorzystywanych aplikacji i obciążenia sieci klaster typu HA firewall może utrzymać dużą część połączeń przechodzących przez uszkodzone urządzenie. Ich liczbę można zwiększyć poprzez wyłączenie zabezpieczeń poziomu aplikacji i mechanizmu weryfikacji sekwencji TCP. W większości wdrożeń systemów zaporowych wyłączanie zabezpieczeń jest jednak nieuzasadnione, przede wszystkim dlatego że rozwiązanie firewall musi realizować funkcje zabezpieczające. Automatyczne akceptowanie sesji z założeniem, że zostały one wcześniej sprawdzone i zaakceptowane na innym urządzeniu klastra, nie jest do końca bezpieczne. Skąd bowiem wiadomo, co (a może lepiej: kto) tak naprawdę wywołało awarię? Poza tym ponowne zestawienie sesji przez użytkownika nie stanowi zwykle dużego kłopotu.

Zapas wpisany w projekt

Jednym z ważniejszych wymagań w stosunku do systemu zaporowego jest wydajność obsługi istniejących i powstających protokołów i usług sieciowych. Obserwując dotychczasowy rozwój technologii informatycznych, można z powodzeniem założyć, że wymagania w stosunku do wydajności systemów zabezpieczeń będą w przyszłości tylko rosły.

Architekturę rozwiązania zaporowego trzeba więc projektować nieco nadmiarowo, a także z uwzględnieniem konieczności modernizacji lub rozbudowy rozwiązania w przyszłości bez uszczerbku dla bezpieczeństwa sieci.

W tym kontekście mało rozsądne jest stosowanie urządzeń typu appliance, które z reguły mają ograniczone możliwości modernizacji, np. wymiany procesora na szybszy, lub też zamontowania większego dysku twardego.

Skalowalność rozwiązań zaporowych można także uzyskać z użyciem technologii HA. Dodanie kolejnego urządzenia do klastra HA funkcjonującego w trybie Active-Active spowoduje podwyższenie jego wydajności. Jedynym zastrzeżeniem jest to, aby nowe urządzenia można było włączyć do klastra bez konieczności zakłócania pracy pozostałych urządzeń.

Choć producenci rozwiązań zaporowych mogących działać w trybie wysokiej dostępności podają, że wzrost ich wydajności w klastrze Active-Active jest liniowy, w praktyce nie jest to nigdy osiągane. Rozsądnie jest założyć, że dodawanie kolejnych urządzeń do klastra będzie zwiększać wydajność całej instalacji o co najwyżej 50-75% nominalnej mocy/przepływności nowego urządzenia - i to tylko do pewnej liczby węzłów.

Wzrost liczby urządzeń oznacza kłopoty z zarządzaniem.

Z tego powodu pożądane jest, aby narzędzia administracyjne umożliwiały zarządzanie i monitorowanie całym klastrem z poziomu dowolnego jego węzła. W ten sposób zarządzanie klastrem uniezależnia się od ewentualnej niedostępności konsoli.

Papierowe obietnice

Wdrożenie pełnowartościowej konfiguracji HA wymaga poniesienia sporych kosztów. Najprostsze konfiguracje rozwiązań wysokiej dostępności można jednak z powodzeniem tworzyć samodzielnie. Wystarczą dwa urządzenia stanowiące platformę oprogramowania zaporowego, stacja zarządzająca oraz oczywiście licencje na odpowiednie oprogramowanie firewall i rozwiązanie HA. Reszta zależy od umiejętności.

W firmach, w których zapewnienie nieprzerwanej dostępności usług systemu zaporowego nie jest krytyczne, można zbudować konfigurację pseudo-HA, określaną także jako zimna rezerwa (Cold Standby). Wówczas przełączanie między uszkodzonym a poprawnie działającym urządzeniem jest wykonywane ręczenie przez administratora. W tym celu należy zainstalować oprogramowanie zaporowe na dwóch urządzeniach i identycznie je skonfigurować. Koszt wdrożenia takiego rozwiązania jest znacznie (bywa, że nawet czterokrotnie) niższy niż w przypadku rozwiązania z przełączaniem automatycznym. Nie trzeba bowiem kupować dwóch licencji oprogramowania firewall ani też, zazwyczaj drogich, modułów HA. Uciążliwość tego rozwiązania polega na tym, że na bieżąco należy aktualizować zmiany w konfiguracji zapasowego firewalla, a w razie awarii przełączyć urządzenia ręcznie.

Dostępne na rynku rozwiązania wysokiej dostępności dla systemów zaporowych znacznie różnią się jakością, zakresem funkcjonalnym i ceną. Dokonując wyboru, należy zdawać sobie sprawę, że informacje podawane przez producentów w materiałach marketingowych nie zawsze są prawdziwe. Nie zawsze też koncentrują się na istotnych zagadnieniach, co z reguły jest próbą ukrycia mankamentów. Przed dokonaniem zakupu warto zweryfikować papierowe obietnice doświadczalnie - w środowisku, pod obciążeniem, a zwłaszcza przy polityce bezpieczeństwa możliwie bliskiej rzeczywistości.

Nie warto rezygnować z kwestii tak podstawowych, jak analiza i formalny projekt rozwiązania.