Konfiguracja i test failover WAN w Sophos Firewall

Drugie łącze internetowe nie staje się automatycznie łączem zapasowym w Sophos Firewall. Nowo utworzona brama WAN ma domyślnie typ Active, a więc uczestniczy w Load Balancing. W klasycznym układzie Primary/Backup drugą bramę należy zatem przestawić na Backup w WAN link manager.

Szybka procedura dla łącza głównego i zapasowego:

1. W pełni skonfigurować oba interfejsy WAN w Network > Interfaces i przetestować każdy z osobna.
2. W Network > WAN link manager ustawić bramę główną jako Active, a zapasową jako Backup.
3. Dla bramy zapasowej wybrać Activate this gateway: If active gateway fails: ANY.
4. Skonfigurować niezawodne Failover rules dla obu bram.
5. Przetestować failover i failback, czyli powrót do łącza głównego, za pomocą rzeczywistego ruchu DNS, HTTPS i aplikacyjnego.

Ten prosty failover domyślnego dostępu do Internetu nie wymaga osobnej trasy SD-WAN. SD-WAN jest potrzebny, gdy określony ruch ma korzystać z wybranych ścieżek albo wybór ścieżki ma zależeć od opóźnienia, jittera i utraty pakietów.

Prawidłowe rozumienie Active, Backup i Load Balancing

Typ bramy określa, czy dane łącze normalnie uczestniczy w ruchu internetowym:

• Active: gdy dostępnych jest kilka aktywnych bram, zapora rozdziela nowe sesje zgodnie ze skonfigurowanymi wagami.
• Backup: brama przejmuje ruch dopiero po spełnieniu warunku aktywacji.

Co najmniej jedna brama WAN musi pozostać Active. Jeśli wszystkie bramy mają wyłącznie typ Backup, nie ma normalnej domyślnej ścieżki WAN; w szczególności ruch generowany przez samą zaporę nie może być wtedy przekazywany.

Wartość Weight nie oznacza przepustowości. W trybie weighted round-robin stosunek 2 do 1 oznacza, że zapora przypisuje dwie nowe sesje do pierwszej bramy, a następną do drugiej. Pojedyncze pobieranie nie jest przez to dzielone między oba łącza, a ilość przesłanych danych może znacznie odbiegać od tego stosunku.

Sophos Firewall używa domyślnie Session Persistence. W takim przypadku nie tylko pojedyncze istniejące połączenie pozostaje na tym samym łączu WAN: zależnie od Persistence Factor także kolejne sesje z tego samego Source IP mogą ponownie zostać przypisane do tego łącza. Bieżącą metodę można sprawdzić po zalogowaniu do Option 4: Device Console za pomocą polecenia tylko do odczytu:

show routing wan-load-balancing

Polecenie niczego nie zmienia. Pokazuje, czy aktywne jest Session Persistence, czy weighted round-robin, i pomaga wyjaśnić nieoczekiwany rozkład ruchu między ścieżkami. W czystym układzie Active/Backup metoda ma zwykle drugorzędne znaczenie, ponieważ zarówno w normalnym stanie, jak i podczas awarii dostępna jest tylko jedna przewidziana ścieżka.

Failover WAN nie jest tym samym co failover HA. WAN link manager zmienia ścieżkę internetową na tej samej zaporze. Klaster HA Sophos Firewall przejmuje natomiast pracę po awarii urządzenia lub monitorowanego portu.

Przygotowanie failover WAN

Oba łącza operatorów muszą najpierw działać niezależnie. Podstawy strefy WAN, przypisywania adresów IP i bram opisano w artykule Planowanie stref i interfejsów Sophos Firewall.

Prosty przykład:

• WAN1 Fiber: łącze główne, brama gw-fiber, Type: Active, Weight: 1
• WAN2 DSL: łącze zapasowe, brama gw-dsl, Type: Backup
• aktywacja łącza zapasowego: If active gateway fails: ANY
• działanie podczas aktywacji: Inherit weight of the failed active gateway
• działanie po przywróceniu: Serve new connections through restored gateway

Nazwy można wybrać dowolnie, ale powinny jednoznacznie opisywać dane łącze. Typ bramy i działania są natomiast ustawieniami funkcjonalnymi. Przed przełączeniem brama zapasowa powinna mieć już zielony stan, a rzeczywisty ruch z klienta testowego przez to łącze powinien zostać pomyślnie przetestowany.

Potrzebna jest również bezpieczna alternatywna droga administracyjna. Jeśli konfiguracja zapory jest zmieniana zdalnie, WebAdmin nie powinien być dostępny wyłącznie przez łącze, które zostanie odłączone podczas testu. Aktualna kopia zapasowa konfiguracji, okno serwisowe oraz osoba na miejscu albo niezależna ścieżka zarządzania zapobiegają przekształceniu prostego testu failover w dłuższą awarię.

Należy wcześniej zanotować również wszystkie usługi powiązane z publicznym adresem IP. Dotyczy to publikacji DNAT, peerów IPsec, Remote Access, list dozwolonych adresów operatora, serwerów pocztowych i zewnętrznych systemów monitoringu. Wychodzący dostęp do Internetu może już działać, podczas gdy usługi te nadal nie są osiągalne ani dozwolone pod nowym adresem publicznym.

Konfiguracja Primary/Backup

Kontrola interfejsów WAN i stanu bram

W Network > Interfaces należy skonfigurować oba porty WAN zgodnie z wymaganiami operatora, używając adresacji statycznej, DHCP albo PPPoE. Podczas zapisywania odpowiednia fizyczna brama WAN jest automatycznie tworzona w WAN link manager.

Nowa brama ma początkowo typ Active. Po dodaniu czystego łącza zapasowego należy więc od razu zmienić jej typ, zanim ruch produkcyjny zacznie niezamierzenie korzystać z obu operatorów.

Custom Gateways utworzone w Routing > Gateways, na przykład dla XFRM, RED lub MPLS, nie pojawiają się w WAN link manager. Należą do innego projektu routingu i w tym prostym scenariuszu nie są traktowane jako fizyczne bramy ISP.

Konfiguracja bramy zapasowej

W Network > WAN link manager należy edytować bramę łącza zapasowego i ustawić następujące wartości:

1. Type: Backup
2. Activate this gateway: If active gateway fails
3. Przy jednym łączu głównym: ANY
4. Action on activation: Inherit weight of the failed active gateway
5. Action on failback: Serve new connections through restored gateway
6. Zapisać i sprawdzić stan bramy.

Przy dokładnie jednej aktywnej bramie ANY i ALL działają w praktyce tak samo. Różnica staje się istotna przy kilku aktywnych łączach:

• ANY: brama zapasowa zostaje aktywowana, gdy tylko jedna z aktywnych bram ulegnie awarii. To właściwy wybór, gdy utraconą przepustowość należy natychmiast zastąpić.
• ALL: brama zapasowa zostaje aktywowana dopiero po awarii wszystkich aktywnych bram. Ten wariant lepiej pasuje do wolnego lub kosztownego łącza awaryjnego.

Action on activation określa wagę bramy zapasowej, gdy zostanie aktywowana obok innych dostępnych bram. Inherit weight of the failed active gateway jest zrozumiałym wyborem w prostym scenariuszu zastępczym. Use configured weight ma sens, jeśli łącze zapasowe ma świadomie mniejszą lub większą przepustowość i działa razem z pozostałymi aktywnymi łączami.

Przy failback ustawienie Serve new connections through restored gateway jest bezpieczniejsze operacyjnie. Nowe sesje ponownie korzystają z łącza głównego, natomiast istniejące pozostają na ścieżce zapasowej do czasu wygaśnięcia lub rozłączenia. Serve all connections through restored gateway zestawia istniejące połączenia ponownie i może je przerwać. W przypadku tras SD-WAN działanie to obowiązuje tylko wtedy, gdy jako Primary Gateway wybrano WAN link load balance. Przy pojedynczym aktywnym łączu WAN jako Primary tylko nowe połączenia są kierowane przez przywróconą bramę.

Rozsądny wybór Failover rules

Failover rules określają, kiedy brama jest uznawana za nieosiągalną. Dostępne są:

• Testing method: Ping albo TCP
• IP address
• w przypadku TCP dodatkowo Port
• łączenie kilku warunków błędu za pomocą AND albo OR

Fizyczne odłączenie kabla jest wykrywane już na interfejsie. Domyślnie utworzony test Ping do adresu IP bramy sprawdza dodatkowo, czy osiągalne jest bezpośrednio podłączone urządzenie operatora lub jego pierwszy hop. Test może jednak pozostać zielony, mimo że za osiągalnym routerem operatora nie działa dostęp do Internetu. Sophos zaleca dlatego dla bram WAN/ISP użycie znanego publicznego adresu IP, na przykład 8.8.8.8 lub 8.8.4.4.

Dla IPv6 Sophos podaje jako publiczny przykład 2001:4860:4860::8888. Aby sprawdzić urządzenie upstream, należy użyć adresu IPv6 bramy, a nie jej adresu link-local.

Pojedynczy cel również nie zapewnia pełnej kontroli stanu. Dobrym punktem wyjścia są dwa stale osiągalne i dozwolone w danej organizacji publiczne adresy IP:

• AND: failover jest wywoływany dopiero po niepowodzeniu wszystkich połączonych testów. Ogranicza to błędne przełączenia spowodowane niedostępnością pojedynczego celu.
• OR: już jeden nieudany test może wywołać failover. Zapewnia to większą czułość, ale zwiększa ryzyko zbędnych przełączeń.

Adresy 8.8.8.8 i 8.8.4.4 są konkretnymi przykładami Sophos, lecz należą do tego samego operatora i nie reprezentują w pełni niezależnych domen awarii. W ważnym środowisku lepiej użyć dwóch dozwolonych celów należących do różnych operatorów. Cel Ping musi niezawodnie odpowiadać na ICMP; dla TCP potrzebna jest stabilna usługa z portem, którego testowanie jest dozwolone.

Ustawienia ANY/ALL bramy zapasowej oraz AND/OR reguł testowych odpowiadają na różne pytania. ANY/ALL określa, ile aktywnych bram musi ulec awarii. AND/OR określa, jak kilka testów ocenia awarię pojedynczej bramy.

Globalna wartość Gateway failover timeout w WAN link manager określa, kiedy zapora uznaje nieodpowiadające łącze za uszkodzone. Nie ma jednej uniwersalnie właściwej wartości. Krótki timeout reaguje szybciej, ale przy utracie pakietów lub krótkiej niedostępności celu może powodować zbędne przełączenia. Wartość ta jest między innymi używana także jako interwał Health Check dla grup failover IPsec i dlatego nie należy jej zmieniać w oderwaniu od pozostałych połączeń tylko z myślą o jednym łączu WAN. Należy udokumentować wartość początkową, przeprowadzić kontrolowany test i dopiero potem dostosować ją na podstawie zmierzonego czasu przełączania.

Kontrolowany test failover i failback

Test odłączenia kabla sprawdza wyłącznie lokalną awarię łącza. Awaria operatora za nadal osiągalnym routerem jest widoczna dopiero wtedy, gdy skonfigurowane publiczne cele testowe także przestają odpowiadać. Najlepiej przetestować oba przypadki osobno.

1. Potwierdzić okno serwisowe, plan wycofania zmiany i alternatywny dostęp administracyjny.
2. W Network > WAN link manager udokumentować stan bramy głównej i zapasowej.
3. Z klienta testowego sprawdzić DNS, HTTPS oraz ważną aplikację. Zanotować także używany obecnie publiczny adres wyjściowy.
4. W celu przetestowania łącza odłączyć w kontrolowany sposób główny kabel WAN. W celu sprawdzenia samego monitorowania pozostawić aktywne połączenie z zaporą i przerwać ścieżkę upstream za urządzeniem operatora, o ile można to zrobić bezpiecznie.
5. Poczekać dłużej niż skonfigurowany Gateway failover timeout.
6. Sprawdzić, czy brama główna jest wyświetlana jako niedostępna, a zapasowa jako aktywna.
7. Uruchomić nowe sesje DNS, HTTPS, VPN i aplikacyjne. Sprawdzić regułę zapory, NAT, osiągalność celu i nowy publiczny adres wyjściowy.
8. Sprawdzić zdarzenia Gateway Up/Down w Log viewer. Do głębszej analizy dgd.log zawiera zdarzenia dotyczące zarządzania bramami WAN i failover łączy.
9. Przywrócić łącze główne i osobno sprawdzić sesje istniejące oraz nowe. Pozwala to potwierdzić, czy skonfigurowane zachowanie failback rzeczywiście działa.
10. Udokumentować stan końcowy, działanie aplikacji i dostępność zewnętrzną.

Udany Ping potwierdza jedynie, że cel testowy odpowiada. Nie potwierdza działania DNS, NAT, VPN, publikowanych usług ani aplikacji biznesowej. W sprawdzeniu rzeczywistej ścieżki pakietów pomaga Packet Capture w WebAdmin Sophos Firewall; zastosowanie dgd.log i innych plików opisano w artykule Service Logs Sophos Firewall.

Typowe błędy i ograniczenia

• Łącze zapasowe już przenosi ruch produkcyjny: nowa brama nadal ma typ Active. Dla czystego łącza zapasowego należy ustawić Backup.
• Brama zapasowa nie staje się aktywna po awarii: sprawdzić stan bramy, typ, ANY/ALL, Failover rules i Gateway failover timeout. Przy kilku aktywnych bramach ustawienie ALL może celowo blokować aktywację, dopóki dostępna jest jeszcze jedna aktywna ścieżka.
• Brama ma zielony stan, ale Internet nie działa: cel testowy jest osiągalny, natomiast DNS, routing, reguła zapory, NAT lub aplikacja nie działa. Należy sprawdzić rzeczywisty ruch, Log Viewer i Packet Capture.
• Zapora przełącza łącze bez rzeczywistej awarii operatora: pojedynczy cel testowy nie odpowiada, OR jest zbyt czułe albo timeout jest zbyt krótki dla jakości łącza. Należy sprawdzić cele testowe i zmierzoną utratę pakietów.
• Istniejące sesje są zrywane podczas przełączenia: zmienia się publiczny Source Address lub stan NAT. Zdalne systemy mogą dlatego odrzucić połączenie. Failover WAN nie zapewnia automatycznie Zero Downtime.
• Ruch wychodzący działa, ale usługi przychodzące nie: drugie łącze wymaga odpowiedniej dostępności publicznej, DNS lub Dynamic DNS, DNAT, reguł zapory i ewentualnie certyfikatów. Artykuły DNAT dla publikowanych serwerów oraz Podstawy NAT pomagają rozgraniczyć przyczynę.
• VPN działa tylko przez łącze główne: Remote Gateway, lokalny Listening Address, FQDN, tożsamości, konfiguracja tunelu i trasa powrotna muszą pasować również do ścieżki zapasowej. Prosty failover WAN nie tworzy drugiego połączenia VPN.

Jeśli aplikacje, grupy użytkowników lub sieci docelowe mają korzystać z różnych łączy albo wybór ścieżki ma zależeć od opóźnienia, jittera i utraty pakietów, decyzję należy zrealizować w trasach i profilach SD-WAN Sophos Firewall. W przypadku komórkowego łącza zapasowego trzeba dodatkowo uwzględnić SIM, APN, limit danych, CGNAT i jakość sygnału; kwestie te opisano w artykule Cellular WAN i failover 4G/5G.

Eksploatacja

• W razie potrzeby powiadamiać o zmianach stanu bramy przez e-mail. Najpierw skonfigurować serwer pocztowy, nadawcę i odbiorcę w Administration > Notification settings. Następnie w System services > Notification list włączyć globalny przełącznik Email notifications i wybrać zdarzenie Gateway status w sekcji System. Samo zaznaczenie wiersza zdarzenia nie powoduje jeszcze wysłania wiadomości e-mail.
• Po nieplanowanych przełączeniach sprawdzać stan bram i dgd.log.
• Testować failover i failback co najmniej raz na kwartał oraz po zmianach operatora, interfejsu, NAT, routingu lub firmware.
• Dokumentować zależności od publicznych adresów IP, zdalne punkty końcowe VPN, listy dozwolonych adresów i usługi przychodzące.
• Wyznaczyć osoby odpowiedzialne za awarię operatora, eskalację i powrót do normalnej pracy.
• Regularnie kontrolować cele testowe; trwała zmiana lub brak osiągalności celu nie może niezauważenie wpływać na logikę przełączania.
• Przy kilku aktywnych łączach sprawdzać wagi i Session Persistence na podstawie rzeczywistego wykorzystania, a nie wyłącznie nominalnej przepustowości.