Prawidłowe planowanie stref i interfejsów Sophos Firewall

Strefa grupuje interfejsy o podobnym poziomie zaufania. Interfejs jest połączeniem fizycznym lub wirtualnym, na przykład Port1, VLAN, LAG albo interfejsem RED lub XFRM. Każdy powiązany interfejs należy dokładnie do jednej strefy; porty fizyczne mogą też pozostać niepowiązane.

Ważne: strefa nie zezwala automatycznie na ruch. Także między dwoma interfejsami w strefie LAN potrzebna jest odpowiednia reguła zapory LAN-to-LAN. Dostęp do samej zapory, na przykład do WebAdmin, SSH lub DNS, jest dodatkowo kontrolowany przez Device Access.

Bezpośrednia konfiguracja stref i interfejsów

Tworzenie strefy

Własną strefę tworzy się w czterech krokach w Network > Zones > Add:

1. Nadać jednoznaczną nazwę, na przykład Server, Management, Guest lub IoT.
2. Jako Type wybrać LAN albo DMZ.
3. W sekcji Device Access zezwolić tylko na te lokalne usługi zapory, które rzeczywiście muszą być dostępne z tej strefy.
4. Zapisać konfigurację.

Następnie strefa powinna być widoczna w Network > Zones i dostępna w regule zapory jako Source zone lub Destination zone. Ruch produkcyjny może przez nią przechodzić dopiero po przypisaniu do niej co najmniej jednego interfejsu.

Własne strefy można tworzyć wyłącznie jako LAN albo DMZ. Nie można tworzyć dodatkowych stref WAN ani VPN. SFOS automatycznie przypisuje interfejsy VPN do strefy VPN. Maksymalna liczba stref zależy od wersji: SFOS 22.0 pozwala na utworzenie do 100 stref, a SFOS 23.0 do 248 stref.

Konfiguracja interfejsu fizycznego

Liczba dostępnych portów fizycznych zależy od modelu urządzenia. Dlatego podczas planowania należy najpierw sprawdzić, jakie złącza udostępnia konkretne urządzenie; interfejsy wirtualne nie zastępują dodatkowych wymaganych portów fizycznych.

Istniejący port edytuje się przez Edit interface w Network > Interfaces:

1. Nadać czytelną wartość Name o długości do 58 znaków, na przykład Core Switch Trunk lub MPLS Provider.
2. Wybrać właściwą Network zone.
3. Skonfigurować IPv4 i w razie potrzeby IPv6.
4. Dla interfejsów WAN sprawdzić Gateway, a w razie potrzeby także MTU i MSS.
5. Zapisać, a następnie sprawdzić stan łącza, stan bramy i Log Viewer.

Strefa WAN jest przeznaczona dla połączeń z Default Gateway. Interfejsy wewnętrzne zwykle mają adresację statyczną; interfejsy fizyczne oferują dla IPv4 metody Static, DHCP i PPPoE. Poniższe procedury wypełniania pól rozróżniają te metody. Wymienione w nich pola bramy nie są powodem, aby tylko z tego względu przypisywać interfejs wewnętrzny do strefy WAN: strefa, adresacja i routing muszą odpowiadać projektowi sieci oraz faktycznie wyświetlanemu formularzowi.

Jeżeli interfejs fizyczny ma już sieć VLAN, SFOS nie pozwala zmienić przypisania IPv4 z Static na DHCP lub PPPoE. Dla IPv6 zablokowana jest również zmiana z Static na DHCP lub Delegated. Przed taką zmianą należy zapisać zależności VLAN w Object usage. Następnie trzeba przenieść odpowiednie interfejsy VLAN na inny Parent Interface albo usunąć je w oknie serwisowym. Dopiero potem można zmienić sposób przypisania, odtworzyć konfigurację VLAN i przetestować łączność.

IPv4 na porcie fizycznym: Static lub DHCP

⚠️ Przed zmianą adresu lub metody przypisania wykonać Object usage > Refresh, udokumentować dotychczasowy adres, maskę, strefę i bramę oraz przygotować kopię zapasową, okno serwisowe i niezależny dostęp administracyjny. Zmiana może przerwać bieżące ścieżki zarządzania i danych. Istniejące zależności VLAN należy najpierw obsłużyć zgodnie z opisem powyżej. Opisana niżej ścieżka recovery przez konsolę nie zastępuje normalnej konfiguracji w WebAdmin.

Static: wprowadzanie stałych wartości IPv4

1. W Network > Interfaces otworzyć właściwy port fizyczny przez Menu > Edit interface i sprawdzić Hardware. Tego złącza fizycznego nie można tutaj zmienić.
2. Zaznaczyć IPv4 configuration i wybrać metodę przypisania Static.
3. Wprowadzić adres IPv4 przewidziany dla tego interfejsu. W razie potrzeby dopasować maskę podsieci do planowanej sieci.
4. Wypełnić Gateway name i Gateway IP address zgodnie z wyświetlanym formularzem oraz zatwierdzonymi parametrami sieci lub operatora. Nazwa służy do jednoznacznej identyfikacji; adres IP bramy jest adresem przewidzianego urządzenia po drugiej stronie, a nie kolejnym adresem zapory.
5. Ponownie porównać wartości i identyfikator portu, a następnie zapisać za pomocą Save. Po zapisie sprawdzić zapisany adres IP i maskę, łącze, w razie potrzeby stan bramy, a także routing, DNS, Device Access oraz rzeczywiste ścieżki danych i zarządzania.

Wyłącznie ilustracyjny przykład statycznego połączenia WAN wykorzystuje adres IPv4 192.0.2.2, maskę 255.255.255.0, Gateway name ISP-Static i Gateway IP address 192.0.2.1. Adresy te należą do sieci przeznaczonej do dokumentacji i nie są produkcyjnymi parametrami operatora. Adres, maskę i bramę należy zastąpić spójnym zestawem parametrów własnego operatora; nazwę dobrać tak, aby można było rozpoznać łącze podczas eksploatacji.

DHCP: rozróżnienie dynamicznego pobierania adresu i udokumentowanych pól

1. Otworzyć port fizyczny w Network > Interfaces > Menu > Edit interface, sprawdzić Hardware i strefę oraz zaznaczyć IPv4 configuration.
2. Wybrać DHCP. Ta metoda pobiera adres interfejsu z serwera DHCP; nie konfiguruje serwera DHCP dla klientów.
3. Udokumentowana procedura wypełniania pól DHCP wymienia dodatkowo wprowadzenie adresu IPv4, opcjonalną zmianę maski podsieci oraz Gateway name i Gateway IP address. Opis nie wyjaśnia jednak, jak te dane współdziałają z adresem pobranym z serwera DHCP. Nie należy na tej podstawie zakładać ręcznego adresu zastępczego, mechanizmu fallback ani nadpisywania dzierżawy DHCP.
4. Przed zapisem sprawdzić pola faktycznie widoczne lub edytowalne w zainstalowanym buildzie i porównać je z zatwierdzoną konfiguracją DHCP lub operatora. Nie przenosić statycznych wartości przykładowych do pól DHCP. Jeżeli rola wymaganego pola jest niejasna, nie zapisywać zmiany, lecz wyjaśnić tę kwestię z operatorem lub pomocą techniczną.
5. Po wyjaśnieniu konfiguracji zapisać za pomocą Save i sprawdzić, czy pobierany jest odpowiedni adres. Connecting oznacza, że trwa jeszcze pobieranie dzierżawy; jeżeli ten stan się utrzymuje, najpierw sprawdzić łącze, dostępność DHCP i wymagania operatora. Następnie skontrolować adres IP, maskę, bramę, DNS, routing oraz rzeczywiste ścieżki zarządzania i danych.

Jeżeli po którejś z tych zmian oczekiwana ścieżka nie działa, przez niezależny dostęp przywrócić udokumentowaną pierwotną metodę i jej wartości, a następnie ponownie przetestować połączenie. PPPoE korzysta natomiast z danych dostępowych operatora; pełną procedurę zawiera artykuł Konfiguracja i sprawdzanie WAN PPPoE.

IPv6 na porcie fizycznym: metoda i tryb odbioru

W IPv6 configuration interfejsy WAN oferują Static lub DHCP, a interfejsy wewnętrzne — Static, DHCP lub Delegated. Delegated wykorzystuje prefiks delegowany przez operatora dla interfejsów wewnętrznych. Pełną procedurę obejmującą DHCP na WAN, Upstream Interface i dystrybucję wewnętrzną opisuje artykuł IPv6 Prefix Delegation w Sophos Firewall. Jest to osobne zadanie, które nie zastępuje konfiguracji statycznej ani opisanego niżej wyboru trybu odbioru.

Static: adres IPv6, prefiks i pola bramy

1. W Network > Interfaces > Menu > Edit interface otworzyć port fizyczny i zaznaczyć IPv6 configuration.
2. Wybrać Static. Statyczne adresy IPv6 są przewidziane zarówno dla interfejsów WAN, jak i wewnętrznych.
3. Wprowadzić planowany adres IPv6 i w razie potrzeby dopasować prefiks do przydzielonej sieci.
4. Wypełnić wymienione w procedurze Static pola Gateway name i Gateway IP address zgodnie z faktycznie wyświetlanym formularzem i projektem sieci. Ogólne instrukcje Static wymieniają te pola również w sekcji dotyczącej interfejsów WAN i wewnętrznych; nie należy z tego wywodzić ani obowiązku stosowania wewnętrznej Default Gateway, ani ogólnej zasady, że pola te dotyczą wyłącznie WAN. Niejasne lub nieoczekiwane pola obowiązkowe należy wyjaśnić przed zmianą produkcyjną.
5. Zapisać za pomocą Save i sprawdzić zapisany adres IPv6 i prefiks, w razie potrzeby bramę, routing IPv6, DNS oraz dozwolone połączenia. Zachować przy tym niezależny dostęp administracyjny; jeżeli ścieżka jest błędna, przywrócić wcześniej udokumentowane wartości IPv6.

Środki zabezpieczające opisane przed procedurą IPv4 obowiązują również dla IPv6: udokumentować poprzednią metodę i wartości, sprawdzić zależności VLAN i nie traktować bieżącej ścieżki zarządzania jako jedynej drogi powrotu.

DHCPv6: Auto, Manual i Stateless

Po wybraniu DHCP w IPv6 configuration ustawienie Mode określa, w jaki sposób sama zapora otrzymuje adres swojego interfejsu. Nie jest to to samo ustawienie co serwer Router Advertisement dla klientów wewnętrznych:

• Auto: adres interfejsu jest przypisywany automatycznie zgodnie z używaną metodą konfiguracji; może to być DHCP only lub Stateless. Nie należy z tego wywodzić stałej reguły wyboru, której tutaj nie udokumentowano.
• Manual > DHCP only: zapora przypisuje interfejsowi adres i pozostałe parametry dostarczone przez serwer DHCPv6.
• Manual > Stateless: zapora tworzy adres interfejsu za pomocą Stateless Address Auto-Configuration (SLAAC), zgodnie z flagami Managed i Other (M/O) ogłaszanymi w komunikatach Router Advertisement. Opcja Accept other configuration from DHCP umożliwia pobranie dodatkowych parametrów z serwera DHCPv6. Nie zmienia to trybu odbioru na DHCP only.

Opcjonalna funkcja DHCP rapid commit wykorzystuje wymianę dwóch komunikatów (solicit i reply) zamiast czterech (solicit, advertise, request i reply). Włącz ją tylko wtedy, gdy Rapid Commit jest również włączony na serwerze DHCPv6 i jest zgodny z zatwierdzoną konfiguracją. Nie jest to ogólne rozwiązanie problemów ani gwarancja poprawy szybkości.

Procedura DHCPv6 wymienia Gateway name i Gateway IP address. Jednak przy Mode ustawionym na Manual i Stateless nie można ustawić Gateway IP address. To ograniczenie dotyczy trybu Stateless i nie wolno przenosić go na Manual > DHCP only. Przed zapisem porównać tryb odbioru i pola bramy z planowanym projektem RA/DHCPv6 oraz widocznym formularzem; nie wymuszać adresu IP bramy, jeśli wybrany tryb na niego nie pozwala.

Po Save sprawdzić faktycznie przypisany adres IPv6, prefiks i pozostałe parametry, a także routing, DNS i dozwoloną ścieżkę danych IPv6. Jeżeli adres jest błędny lub go brakuje, najpierw porównać z urządzeniem po drugiej stronie wybrany tryb, odebrane flagi RA i dostępność DHCPv6; nie przełączać trybów bez wcześniejszej weryfikacji. W razie przerwania ścieżki zarządzania przywrócić poprzednią konfigurację przez niezależny dostęp.

Dopasowanie ustawień portu i łącza

W Advanced settings należy dopasować Link mode, Auto-negotiation for media type, zależną od modelu funkcję Forward Error Correction (FEC) oraz MTU i MSS do urządzenia po drugiej stronie. W przypadku portów 25, 50 i 100 Gbit/s najpierw zapisuje się Link mode, ponownie otwiera interfejs, a następnie wczytuje zalecaną konfigurację. W modelach XGS 2100, 2300, 3100 i 3300 wszystkie porty SFP+ w modułach FleXi Port muszą używać tej samej prędkości. Pełną procedurę z Show recommended settings, Load recommended configuration, oboma krokami zapisu oraz odmiennym sposobem wyświetlania dla pozostałych portów, w tym 40 Gbit/s, przedstawia artykuł Konfiguracja interfejsów breakout i ustawień portów.

SFOS nie obsługuje oznaczania DSCP dla samodzielnie generowanego ruchu DHCP i ARP, również wtedy, gdy zapora działa jako klient, przekaźnik lub serwer DHCP. Polityka nie może więc polegać na priorytetyzacji tych pakietów na podstawie DSCP. Ograniczenie to dotyczy DSCP; nie oznacza, że wykluczony jest każdy inny możliwy sposób priorytetyzacji.

W Advanced settings > Interface settings opcja Use default MAC address wykorzystuje domyślny adres MAC interfejsu. W przypadku interfejsu z portami członkowskimi ten domyślny adres MAC pochodzi z portu dodanego jako pierwszy. Override default MAC address pozwala użyć innego adresu MAC; Factory Reset przywraca domyślny adres MAC. Nie jest to zalecenie resetowania ani warunek korzystania z samodzielnego fizycznego portu PPPoE. Przed uzasadnionym nadpisaniem adresu sprawdzić opisane niżej zależności i drogę powrotu.

Prędkości portów zapory i urządzenia po drugiej stronie muszą być zgodne. Na przykład portu 25 Gbit/s nie można połączyć z portem 40 Gbit/s za pomocą kabla breakout bez odpowiedniej konwersji. Obsługiwane porty zapory o prędkościach 40 i 100 Gbit/s można rozdzielić za pomocą odpowiednich kabli breakout na dwa lub cztery porty. Nie oznacza to, że jest to możliwe w każdym modelu urządzenia lub przy każdej kombinacji kabli; przed planowaniem należy sprawdzić obsługę konkretnych portów, transceiverów i urządzenia po drugiej stronie.

Ustawienie adresu IPv4 w interaktywnym menu recovery

W 1. Network Configuration > Interface Configuration CLI pokazuje adres IPv4 i maskę, adres IPv6 i prefiks, strefę, gatewaye oraz skonfigurowane aliasy portów fizycznych. Interfejsy VLAN i WLAN nie są tu widoczne.

y rozpoczyna zmianę IPv4. SFOS kolejno pokazuje dla każdego portu bieżący adres, maskę i strefę; Enter bez nowej wartości zachowuje pole. Ta ścieżka dotyczy tylko Gateway mode i statycznych wartości IPv4. Nie konfiguruje VLAN, DHCP, PPPoE, WLAN ani WWAN, a dialog IPv6 jest inny.

Przed zmianą należy zapisać wszystkie wartości, ID portu, strefę, gateway, aliasy i niezależną ścieżkę zarządzania. Po zapisie sprawdzić link, nowy IP i maskę, gateway, Device Access, routing, DNS i rzeczywistą ścieżkę zarządzania. Jeśli dostęp zostanie przerwany lub ścieżka danych jest błędna, przywrócić wartości początkowe przez konsolę lub niezależny dostęp.

Korekta wartości linku i MAC w Device Console

WebAdmin pozostaje normalną ścieżką konfiguracji. Device Console służy do udokumentowanej korekty lub recovery, ponieważ błędna wartość linku może natychmiast przerwać jedyną ścieżkę zarządzania. Najpierw zapisuje się Port ID, peer, aktualny Link mode, autonegotiation, FEC, niezależny dostęp administracyjny i rollback.

Oficjalna składnia SFOS 22 dopuszcza 1000fd, 100fd, 100hd, 10fd, 10hd lub auto dla wymienionych wartości portów miedzianych:

Poniższe przykłady są alternatywami, a nie sekwencją poleceń. Zastąpić Port2 zweryfikowanym portem fizycznym i wybrać dokładnie jeden wariant zgodny z zatwierdzoną konfiguracją portu oraz urządzenia po drugiej stronie; nie wykonywać obu kolejno. Najpierw po obu stronach zapisać pierwotne wartości Link mode, autonegotiation i, jeśli dotyczy, FEC, a także stan łącza, rzeczywistą prędkość i duplex. Zapewnić niezależny dostęp i ustalić sposób dokładnego przywrócenia wartości przez WebAdmin albo procedurę potwierdzoną przez pomoc techniczną dla zainstalowanego buildu. Jeśli pierwotne wartości lub ścieżka recovery są nieznane, zatrzymać się przed zmianą CLI i skontaktować z pomocą techniczną.

Alternatywa 1: automatyczna prędkość i duplex, z włączoną dodatkową autonegotiation:

set network interface-link Port2 linkmode auto autoneg on

Alternatywa 2: 1000 Mbps full-duplex, z wyłączoną dodatkową autonegotiation:

set network interface-link Port2 linkmode 1000fd autoneg off

autoneg steruje dodatkowymi parametrami linku poza prędkością i duplex. Tryby FEC zależą od modelu, a Sophos nie podaje w tym poleceniu CLI uniwersalnej listy. Dla portów 25, 50 lub 100 Gbit/s stosuje się zalecaną konfigurację konkretnego appliance i transceivera, a nie wartość skopiowaną z innego modelu.

Bezpośrednio po wybranej zmianie porównać zapisane wartości Link mode, autonegotiation i, jeśli dotyczy, FEC w WebAdmin oraz na urządzeniu po drugiej stronie z zatwierdzonymi wartościami docelowymi. Po obu stronach sprawdzić stan łącza, rzeczywistą prędkość i duplex, a także normalny dostęp do zarządzania i wymagane rzeczywiste ścieżki danych. Jeśli ścieżka nie działa, jest niestabilna lub pogorszyła się, przez niezależny dostęp przywrócić dokładnie zapisane pierwotne wartości portu oraz wszystkie ustawienia urządzenia po drugiej stronie dostosowane na potrzeby zmiany, w tym FEC, jeśli zostało zmienione. Użyć wcześniej ustalonej ścieżki przywracania i powtórzyć te same kontrole; konfiguracja każdej strony musi ponownie odpowiadać jej własnemu stanowi początkowemu. Żaden z przykładów, także auto z autoneg on, nie jest uniwersalnym sposobem wycofania zmiany.

Adres MAC nadpisuje się wyłącznie dla potwierdzonej zależności projektowej. Przed każdą zmianą zapisać jako stan początkowy faktycznie używany adres MAC i skonfigurowany tryb (default lub override, w tym ewentualny istniejący adres niestandardowy). Sprawdzić Port Security, bindingi DHCP, allowlisty operatora, HA, LAG i powiązania MAC/ARP urządzenia po drugiej stronie. Zapewnić niezależny dostęp administracyjny i okno serwisowe.

Opisy CLI dla SFOS 22.0 i 23.0 wskazują, że default zachowuje istniejący adres MAC. Nie potwierdza to interpretacji, że po override przywraca domyślny MAC. default nie jest potwierdzonym poleceniem odwrotnym ani uniwersalną drogą wycofania zmiany. Przed override zweryfikować sposób dokładnego przywrócenia zarówno adresu, jak i trybu w zainstalowanym buildzie. Jeśli nie można zweryfikować stanu początkowego lub procedury przywracania, nie wykonywać zmiany i wyjaśnić kwestię z Sophos Support.

Poniższy przykład zmienia MAC i może przerwać połączenia administracyjne i danych. Zastąpić Port2 sprawdzonym portem, a lokalnie administrowany adres przykładowy — zatwierdzonym adresem docelowym, unikalnym we własnej sieci. Nie jest to wartość do przywracania:

set network macaddr Port2 override 02:00:5e:10:00:02

Dla zweryfikowanej procedury przywracania:

• Jeśli wcześniej skonfigurowano override z niestandardowym MAC, ponownie ustawić dokładnie zapisany adres za pomocą udokumentowanej gałęzi override, a nie adres przykładowy. Procedura musi być potwierdzona dla zainstalowanego buildu.
• Jeśli wcześniej skonfigurowano default, użyć Use default MAC address w Network > Interfaces > Edit interface > Advanced settings > Interface settings tylko wtedy, gdy ten element i przywrócenie zapisanego stanu początkowego są potwierdzone w zainstalowanym buildzie. W przeciwnym razie uzyskać procedurę właściwą dla buildu, potwierdzoną przez Sophos Support; nie próbować CLI default ani resetu fabrycznego jako zamienników.

Po zmianie i po przywróceniu porównać skonfigurowany tryb i faktycznie używany adres z wartościami oczekiwanymi; przy wycofaniu oba muszą odpowiadać zapisanemu stanowi początkowemu. Sprawdzić też zwykły dostęp administracyjny, uczenie MAC/ARP urządzenia po drugiej stronie i rzeczywisty przepływ danych objęty zmianą. W razie rozbieżności przerwać procedurę przez niezależny dostęp i wyjaśnić je z pomocą techniczną, zamiast eksperymentować z kolejnymi wartościami MAC.

Sophos dokumentuje MTU 1500 i MSS 1460 jako wartości domyślne; zmienia się je tylko według kontrolowanej procedury Sprawdzanie MTU i MSS przy problemach VPN.

Dla IPv6 parametr DAD attempts określa, ile kolejnych komunikatów Neighbor Solicitation zapora wysyła podczas Duplicate Address Detection dla adresu w stanie wstępnym (tentative). W Allowed RA servers wpisuje się adresy MAC lub IPv6 serwerów Router Advertisement, od których ten interfejs może przyjmować konfigurację stateless. IPv6 Prefix Delegation w Sophos Firewall opisuje prefiks operatora i jego dystrybucję wewnętrzną, a Konfiguracja IPv6 Router Advertisement wyjaśnia flagi klientów i ogłaszane prefiksy.

W konkretnych zadaniach pomagają bardziej szczegółowe instrukcje:

• Konfiguracja i test interfejsu VLAN
• Konfiguracja i test sieci Wi-Fi zarządzanej przez SFOS
• Połączenie istniejących APX przez Wireless Mesh
• Konfiguracja interfejsu LAG
• Konfiguracja i testowanie tunelu GRE
• Przenoszenie IPv6 przez IPv4 lub IPv4 przez IPv6 za pomocą tunelu IP
• Konfiguracja i sprawdzanie WAN PPPoE
• Konfiguracja failover WAN z drugim łączem internetowym
• Konfiguracja Sophos SD-RED
• Zabezpieczenie Device Access
• Przekazywanie Multicast między interfejsami przy użyciu statycznej trasy Multicast
• Planowanie i weryfikacja dynamicznego routingu Multicast z PIM-SM
• Konfiguracja Site-to-Site IPsec VPN

Planowanie modelu stref

Rozróżnienie strefy, interfejsu i obiektu sieciowego

Te trzy elementy pełnią różne funkcje:

• Strefa: opisuje obszar bezpieczeństwa, z którego pochodzi ruch lub do którego jest kierowany.
• Interfejs: fizycznie albo wirtualnie łączy zaporę z siecią.
• Obiekt sieciowy: określa konkretny adres IP lub podsieć w regule.

Reguła jest precyzyjna dopiero wtedy, gdy zgadzają się zarówno strefa, jak i obiekt sieciowy. Połączenie Source zone: LAN z Source networks: Any jest często niepotrzebnie szerokie. Z drugiej strony poprawny obiekt sieciowy nie pomoże, jeżeli pakiet dociera przez inną strefę niż określona w regule.

Strefy standardowe mają ustalone zadania:

• LAN dla sieci wewnętrznych
• WAN dla połączeń z operatorem i internetem
• DMZ dla wystawionych lub szczególnie odizolowanych systemów
• WiFi dla środowisk WLAN
• VPN dla tuneli Remote Access i Site-to-Site

Strefa WiFi dotyczy sieci bezprzewodowych korzystających z osobnej strefy. W trybach Bridge to AP LAN i Bridge to VLAN nie jest jednak tworzony dedykowany interfejs WiFi; ścieżka ruchu wynika z wybranego przypisania bridge.

Sieć bezprzewodowa określa wspólne ustawienia dla klientów WLAN: SSID, tryb zabezpieczeń oraz sposób obsługi ruchu klientów. Przy ustawieniu Traffic Mode na Separate zone zapora tworzy powiązany tunel VXLAN. Wybór Traffic Mode określa więc również sposób połączenia sieci WLAN z zaporą; nie jest to jedynie nazwa sieci.

Własne strefy LAN nadają się na przykład dla segmentów Client, Server, Management, Guest, IoT, VoIP, Backup lub OT. Własna strefa DMZ pasuje do publikowanych serwerów, Reverse Proxy i innych systemów, których dostęp do sieci wewnętrznej powinien być ściśle ograniczony.

Nie każdy VLAN wymaga osobnej strefy. Kilka sieci VLAN można połączyć, jeśli mają ten sam poziom zaufania, reguły zapory i ustawienia Device Access. Jeżeli różnią się dozwolonymi celami, dostępem administracyjnym albo funkcjami ochronnymi, osobna strefa jest zwykle bardziej przejrzysta.

Dla użytkowników VPN lub tuneli między lokalizacjami nie tworzy się własnych typów stref VPN. Separację w strefie VPN realizuje się za pomocą precyzyjnych obiektów sieciowych, użytkowników i reguł zapory.

Określenie kierunków dostępu przed utworzeniem reguł

Przed konfiguracją wystarczy krótka lista dozwolonych kierunków. Na przykład:

• Client do WAN: wymagane usługi WWW, DNS, NTP i aplikacyjne
• Client do Server: tylko zdefiniowane porty aplikacji
• Guest do WAN: dostęp do internetu bez dostępu do sieci wewnętrznych
• IoT do Server: tylko niezbędne cele, takie jak DNS, NTP lub platforma zarządzająca
• Management do stref wewnętrznych: ściśle ograniczone i rejestrowane usługi administracyjne
• DMZ do LAN: domyślnie zablokowane, dozwolone tylko jawnie wymagane połączenia
• VPN do Server: tylko zatwierdzone cele i usługi

Dla każdego dozwolonego kierunku powinny być znane cel, usługi, potrzeba NAT, sposób rejestrowania oraz osoba odpowiedzialna. Na tej podstawie powstają właściwe reguły. Strukturę, kolejność i dopasowanie wyjaśnia artykuł Prawidłowa konfiguracja reguł Sophos Firewall.

Kontrola przed zmianą

Przed utworzeniem lub przeniesieniem interfejsu należy wyjaśnić co najmniej następujące kwestie:

• strefa i poziom zaufania sieci
• adres IP, podsieć i Default Gateway
• źródło DHCP i serwery DNS
• wymagane lokalne usługi zapory
• reguły zapory i NAT
• routing i SD-WAN
• klient testowy, oczekiwany dostęp i oczekiwany wpis w logu

Zmiany produkcyjne wymagają aktualnej kopii zapasowej, przygotowanej drogi powrotu oraz kontroli w Object usage.

Tworzenie i odbiór VLAN

VLAN tworzy odizolowaną domenę rozgłoszeniową: ruch rozgłoszeniowy pozostaje w obrębie tego VLAN-u. Przypisanie kilku sieci VLAN do tej samej strefy bezpieczeństwa nie znosi tej separacji w warstwie 2; strefa określa kontekst reguł zapory i Device Access.

VLAN tworzy się w Network > Interfaces > Add interface > Add VLAN. Kluczowe są następujące pola:

• Interface: interfejs fizyczny, RED, Bridge albo LAG, na którym dociera tagowany VLAN
• Network zone: obszar bezpieczeństwa sieci VLAN
• VLAN ID: musi być zgodny z konfiguracją przełącznika i ewentualnie Access Point
• IPv4/IPv6 configuration: w wewnętrznych sieciach VLAN zwykle statyczny adres bramy

Przykładowy VLAN dla gości może działać na Port3 z VLAN ID 20, strefą Guest i adresem bramy 192.168.20.1/24. Na przełączniku VLAN 20 musi być tagowany na uplinku do Port3, a port kliencki lub SSID dla gości przypisuje urządzenia końcowe do tego VLAN-u.

Zapora może poprawnie wyświetlać interfejs, mimo że przełącznik wysyła VLAN przez niewłaściwy port, bez tagu albo z innym VLAN ID. VLAN jest więc gotowy dopiero po sprawdzeniu całej ścieżki:

1. Sprawdzić na zaporze VLAN ID, Parent Interface, strefę, adres IP i maskę.
2. Skonfigurować uplink do zapory jako Trunk z tagowanym VLAN-em.
3. Przypisać Access Port lub SSID do właściwego VLAN-u.
4. Na kliencie testowym sprawdzić DHCP, Gateway i DNS.
5. Przetestować dozwolony dostęp wewnętrzny oraz celowo zabronione połączenie.
6. Sprawdzić dostęp do internetu i potwierdzić oczekiwany Firewall Rule ID w Log Viewer.

Dla ruchu wewnętrznego NAT zwykle nie jest potrzebny. Jeśli klient otrzymuje adres, ale nie może korzystać z zapory jako serwera DNS ani jej pingować, najpierw należy sprawdzić Device Access. Pełną procedurę z tagowaniem na przełączniku i DHCP zawiera artykuł Konfiguracja i test VLAN w Sophos Firewall.

Sophos nie podaje dla XGS Appliances stałego limitu liczby sieci VLAN na fizyczny Parent Port. Przy dużym obciążeniu, wielu sieciach VLAN lub środowiskach HA kilka uplinków albo LAG może jednak ułatwić eksploatację i diagnostykę.

Wybór właściwego typu interfejsu

Interfejsy wirtualne i aliasy tworzy się w Network > Interfaces za pomocą Add interface. Należy tam wybrać odpowiedni typ i otworzyć jego konfigurację. Poniższe sekcje pomagają w wyborze typu; alias uzupełnia istniejący interfejs, natomiast na przykład VLAN, Bridge i LAG odwzorowują różne połączenia logiczne.

Alias

Alias dodaje kolejny adres IP do istniejącego interfejsu. Jest to szczególnie przydatne, gdy operator udostępnia kilka publicznych adresów IP w tej samej podsieci.

Konfiguracja i testowanie aliasu IP na Sophos Firewall opisuje, jak powiązać dodatkowy adres, użyć go jako obiektu hosta w regułach i NAT oraz sprawdzić ARP i ruch systemowy.

Kilka oddzielnych interfejsów WAN w tej samej podsieci może powodować problemy z ARP i niedostępne bramy. W takim przypadku Alias na istniejącym interfejsie WAN albo odpowiednio zaplanowany LAG jest zwykle lepszym rozwiązaniem. Alias przejmuje stan swojego Parent Interface i nie można go wyłączyć niezależnie.

Bridge

Bridge łączy kilka interfejsów w warstwie 2. Może działać z adresem IP dla ruchu routowanego albo transparentnie, bez adresu IP. Dla nowych segmentowanych sieci VLAN-y są zwykle bardziej przejrzyste; Bridge sprawdza się raczej podczas migracji lub w świadomie zaplanowanych środowiskach transparentnych.

Pełną procedurę obejmującą Members, STP, filtry VLAN i EtherType, reguły oraz weryfikację opisuje artykuł Konfiguracja interfejsu Bridge w Sophos Firewall.

Obowiązują przy tym istotne ograniczenia:

• Bridge nie obsługuje Dynamic DNS, DHCP Client, PPPoE ani IPsec VPN.
• Ruch między Bridge Members może nadal wymagać reguł zapory, na przykład LAN-to-LAN.
• Nie można aktywować HA, dopóki na Bridge działa STP.
• Jeśli VLAN Filter jest włączony, ale nie zezwolono na żaden VLAN, zapora odrzuca wszystkie tagowane ramki; nie wpływa to na ruch nieotagowany.
• Ruch przez Bridge bez adresu IP może zostać odrzucony bez wpisu w logu, jeśli pasuje do reguły Web Proxy albo NAT.

W przypadku transparentnego Bridge należy więc sprawdzić, czy Web Proxy Filtering lub Source Translation są rzeczywiście potrzebne.

Sophos dokumentuje NC-177630 dla SFOS 22.0.0 GA-Respin Build 411. Błąd może wystąpić, gdy ruch routowany przez Bridge jest tłumaczony za pomocą SNAT lub MASQ, a ruch przychodzący i wychodzący korzysta z tego samego fizycznego Bridge Member. Pakiety odpowiedzi są wtedy odrzucane przez Hairpin Filter bez pojawienia się w drppkt. Dotyczy to również sytuacji, gdy aktywny jest tylko jeden Bridge Member. Problem nie występuje przy ruchu przez różne fizyczne Bridge Members ani bez SNAT/MASQ.

Sophos wskazuje SFOS 22.0.1 MR1 Build 490 jako wersję zawierającą poprawkę. W GA-Respin Build 411 SNAT lub MASQ dla danego przepływu można usunąć tylko wtedy, gdy translacja nie jest potrzebna i istnieje trasa powrotna do pierwotnego adresu IP klienta. Alternatywnie ruch należy poprowadzić przez dedykowany interfejs fizyczny zamiast przez Bridge. Jeśli brakuje któregoś z opisanych warunków lub problem występuje w MR1 Build 490 albo nowszej wersji, należy szukać innej przyczyny. Osobny przypadek ruchu VLAN do zapory w SFOS 22 opisuje artykuł Kontrola Bridge VLAN po aktualizacji do SFOS 22.

Bridge przez RED może rozszerzyć sieć warstwy 2 między lokalizacjami, ale powinien pozostać uzasadnionym wyjątkiem.

Broadcast, ARP i nieznany ruch Unicast przechodzą wtedy przez połączenie WAN. Projekt routowany z osobnymi podsieciami lokalizacji i precyzyjnymi regułami zapory jest stabilniejszy, lepiej się skaluje i łatwiej go diagnozować.

LAG

Link Aggregation Group łączy od dwóch do czterech interfejsów fizycznych w jeden logiczny uplink. Na nim można następnie tworzyć sieci VLAN.

Typowe tryby pracy to:

• Active-Backup: jedno łącze jest aktywne, a drugie przejmuje ruch w razie awarii.
• LACP (802.3ad): kilka łączy może działać równolegle; zapora i przełącznik muszą mieć identyczną konfigurację.

Członkami mogą być niepowiązane interfejsy fizyczne ze statyczną konfiguracją. Interfejsy PPPoE, Cellular WAN i WLAN są wykluczone. W LACP porty muszą mieć ten sam typ i tę samą prędkość.

xmit-hash-policy rozdziela połączenia między łącza. Pojedyncze połączenie TCP zwykle nie staje się przez to szybsze, ponieważ pozostaje na jednym łączu. LAG zapewnia przede wszystkim nadmiarowość i większą łączną przepustowość dla wielu równoległych połączeń.

LAG i failover WAN pełnią różne funkcje: LAG łączy fizyczne łącza w jedno połączenie logiczne. Niezależne łącza internetowe są natomiast wykorzystywane przez ich bramy WAN w Network > WAN link manager. Kilka aktywnych bram umożliwia rozłożenie obciążenia między dostępne łącza; brama zapasowa może przejąć ruch po wykryciu awarii. Nie gwarantuje to ani nieprzerwanego działania istniejących sesji, ani większej przepustowości pojedynczego połączenia. Artykuł Konfiguracja failover WAN z drugim łączem internetowym opisuje procedurę i sposób sprawdzenia jej działania.

Komórkowe połączenie WAN i WWAN1

Po włączeniu Cellular WAN SFOS tworzy interfejs WWAN1. Należy on do połączenia komórkowego i nie jest odpowiednikiem dowolnie utworzonego VLAN-u ani aliasu. Nadal należy uwzględniać opisane poniżej ograniczenia dotyczące HA oraz wykluczenie z członkostwa w LAG.

W SFOS 23.0 w Network > Interfaces, w Menu interfejsu WWAN, dostępne są akcje Connect i Disconnect, które umożliwiają połączenie lub rozłączenie modemu Cellular WAN. Reset uruchamia modem ponownie i jest dostępny wyłącznie dla modeli 5G firm Quectel i Sierra Wireless, a nie dla innych modeli ani modemów USB. Nie należy zakładać, że te akcje opisane dla SFOS 23.0 są dostępne w SFOS 22.0 pod identyczną ścieżką kliknięć.

Przed użyciem Disconnect lub Reset należy zapewnić niezależny dostęp administracyjny i okno serwisowe, jeśli połączenie komórkowe przenosi ruch produkcyjny lub zapewnia dostęp do zarządzania. Sprzętowe ponowne uruchomienie modemu wymagające wyłączenia zapory przerywa cały ruch przechodzący przez zaporę; również w tym przypadku należy zaplanować niezależny dostęp administracyjny i okno serwisowe. Aby sprzętowo uruchomić ponownie nieobsługiwany model, należy najpierw wyłączyć zaporę, następnie odłączyć i ponownie podłączyć modem, a potem uruchomić zaporę; nie wolno dokonywać fizycznych zmian sprzętu WWAN przy działającej zaporze. Następnie należy sprawdzić stan interfejsu oraz wymagane ścieżki danych i zarządzania. Ponowne uruchomienie modemu nie jest gwarantowanym rozwiązaniem problemu z połączeniem, którego przyczyna nie została ustalona.

TAP / Discover Mode

Fizyczny port w Discover Mode odbiera kopię ruchu przesyłaną przez przełącznik. Nie pracuje inline i nie może blokować obserwowanego ruchu ani sterować nim za pomocą polityk bezpieczeństwa. Jest to przydatne do inwentaryzacji lub proof of concept, ale nie stanowi produkcyjnej ścieżki ochrony.

W widoku interfejsów ten port jest oznaczony jako Discover, physical (TAP). Pozwala to odróżnić go od zwykłego interfejsu w produkcyjnej ścieżce danych.

Artykuł Konfiguracja Discover Mode z TAP i SPAN opisuje pełną konfigurację z portem SPAN, poleceniami Device Console, Packet Capture, Security Audit Report i granicami HA.

XFRM dla route-based IPsec

W przypadku route-based IPsec rozróżnia się połączenia Any-to-any oraz połączenia z konkretnymi Traffic Selectors. Gdy obie podsieci są ustawione na Any, SFOS automatycznie tworzy interfejs XFRM w strefie VPN:

• Any-to-any: automatycznie utworzonemu XFRM trzeba przypisać adres IP w Network > Interfaces. Następnie trasy statyczne, SD-WAN albo dynamiczne określają ruch kierowany do tunelu.
• Traffic Selectors: SFOS automatycznie tworzy trasę statyczną podczas zestawiania tunelu. Jeśli interfejs XFRM jest widoczny, nie należy przypisywać mu adresu IP ani ręcznych tras.

Oficjalna dokumentacja SFOS 22 i SFOS 23 zawiera sprzeczne informacje o tworzeniu XFRM dla konkretnych podsieci: „Configure an XFRM interface” wskazuje, że XFRM nie powstaje, natomiast „Route-based VPN” opisuje tworzenie jednego XFRM dla każdej konfiguracji. Nie należy więc zakładać, że interfejs zawsze istnieje albo zawsze jest nieobecny. Rozwinąć Listening interface w Network > Interfaces i sprawdzić rzeczywistą widoczność w zainstalowanym buildzie. Sekcja Traffic Selectors w artykule Konfiguracja Site-to-Site IPsec VPN opisuje istniejące kontrole widoczności i ruchu.

W obu przypadkach ruch VPN wymaga odpowiednich reguł zapory. W Administration > Device access usługa IPsec dla strefy WAN zezwala na przychodzące żądania połączeń IPsec. Ping do lokalnego adresu zapory ze strefy VPN włącza się osobno przez Ping/Ping6 w Administration > Device access. Ping między hostami przez tunel VPN jest natomiast ruchem przechodzącym przez zaporę i wymaga odpowiednich tras oraz reguł zapory; zezwolenie w Device Access nie dopuszcza tego ruchu.

XFRM nie wyłącza się bezpośrednio w Network > Interfaces, lecz przez powiązane połączenie w Site-to-site VPN > IPsec. Jeśli SSL/TLS Decryption obejmuje ruch IPsec, Sophos wymaga, aby MTU interfejsu XFRM było co najmniej o 113 bajtów mniejsze od MTU Listening Interface. Dla MTU 1400 na Listening Interface maksymalne MTU XFRM wynosi więc 1287. Ten limit produktu dotyczy FastPath Offload i nie jest wartością ogólną dla każdego tunelu. Pełną procedurę kontroli zawiera artykuł Sprawdzanie MTU i MSS przy problemach z VPN.

RED

Interfejs RED łączy zdalną lokalizację przez szyfrowany tunel. Tryb pracy określa, jaka część ruchu przechodzi przez centralę:

• Standard/Unified: centralna zapora zarządza i filtruje cały ruch lokalizacji. Awaria tunelu może również odciąć dostęp do internetu.
• Standard/Split: przez tunel przechodzą tylko zdefiniowane sieci docelowe; ruch internetowy wychodzi lokalnie i nie jest centralnie filtrowany.
• Transparent/Split: RED działa transparentnie w istniejącej sieci. Jest to elastyczne, ale trudniejsze do zaplanowania i diagnozowania.
• Manual/Split: konfiguracja sieci jest w większym stopniu wykonywana ręcznie i może zapewnić lokalną niezależność.

Usługa RED musi być aktywna w System services > RED. Połączenie zwykle wymaga TCP 3400, UDP 3410 oraz NTP przez UDP 123. Muszą również działać DNS, prawidłowy czas systemowy i wychodzący dostęp do internetu.

Zachowanie VLAN zależy od modelu RED, trybu pracy, trybu portów LAN oraz konfiguracji WLAN. Sophos zaleca Standard/Unified, gdy za RED używane są sieci VLAN; w SD-RED 60 tagowanie VLAN jest możliwe tylko w tym trybie. WLAN z Bridge to VLAN podlega odrębnym regułom. Wybór właściwego trybu pracy Sophos RED wyjaśnia DHCP, bramę, ścieżkę internetową i zachowanie podczas awarii we wszystkich czterech trybach. Provisioning, stany LED i diagnostykę opisuje artykuł Konfiguracja Sophos SD-RED.

Kontrola stanu i Device Access

Stan interfejsu

W Network > Interfaces wartości stanu wskazują, czy najpierw należy sprawdzić łącze, czy politykę:

• Not configured: nie przypisano strefy
• Connected: skonfigurowany i połączony
• Connecting: właśnie pobiera adres, na przykład przez DHCP
• Disconnected: adres został zwolniony
• Disconnecting: adres jest właśnie zwalniany
• Unplugged: brak połączenia fizycznego; w przypadku WiFi może brakować Access Point albo Wireless Network
• Not available: skonfigurowany FleXi Port bez zainstalowanego modułu FleXi Port

Przy stanie Not configured albo Unplugged reguły zapory nie są pierwszym miejscem diagnostyki. Najpierw należy sprawdzić Zone Binding, kabel, SFP, prędkość portu, port przełącznika oraz DHCP lub PPPoE.

Lokalne usługi zapory

W Administration > Device access dla każdej strefy określa się dostępność lokalnych usług, takich jak HTTPS, SSH, User Portal, VPN Portal, DNS, Ping/Ping6, Captive Portal, RADIUS SSO czy Wireless Protection.

Zezwolenia te dotyczą samej zapory. Ruch przechodzący między sieciami kontrolują reguły zapory. HTTPS i SSH powinny być dozwolone wyłącznie z sieci zarządzającej albo przez precyzyjną Local service ACL exception rule. Usługa DNS jest wymagana, jeżeli klienci używają zapory jako serwera DNS.

⚠️ Jeśli klienci mogą używać Web Proxy zapory, SFOS traktuje żądania HTTP i HTTPS jako wewnętrzne żądania Proxy. W rezultacie WebAdmin, Captive Portal, VPN Portal lub User Portal mogą być dostępne, mimo że odpowiednia usługa jest wyłączona dla strefy klienta. W takim projekcie trzeba osobno sprawdzić dostęp do Proxy i lokalnych portali.

Bezpieczna obsługa zależności i zmian

Object Usage przed edycją lub usunięciem

Zone Binding, DNS, Gateways, SD-WAN, Interface Hosts, VLAN, Dynamic DNS, DHCP, reguły zapory, NAT i VPN mogą zależeć od tego samego interfejsu. Object usage pokazuje te odwołania.

Wyświetlany licznik jest automatycznie aktualizowany tylko raz dziennie. Przed zmianą lub usunięciem należy więc kliknąć Refresh i udokumentować ważne zależności. Nie każde odwołanie można edytować w oknie podręcznym. Bramy WAN i konfiguracje CLI trzeba zmieniać na odpowiedniej stronie konfiguracji albo w CLI.

W przypadku edytowalnych odwołań w regułach lub politykach licznik prowadzi do konkretnej konfiguracji:

1. W kolumnie Usage kliknąć liczbę użyć danego obiektu. Okno podręczne pokazuje, które konfiguracje go używają.
2. Rozwinąć odpowiednią kategorię za pomocą ikony plusa, aby wyświetlić należące do niej reguły lub polityki.
3. Kliknąć daną regułę lub politykę, aby ją edytować. Usunąć w niej odwołanie do obiektu albo zastąpić je odwołaniem do wybranego obiektu zastępczego.

Po sprawdzeniu zależności interfejs włącza się lub wyłącza w Network > Interfaces, w Menu danego interfejsu, za pomocą odpowiednio on lub off. Przed użyciem off należy zapewnić niezależny dostęp administracyjny i drogę powrotu; ta czynność może przerwać aktualnie używaną ścieżkę danych. Aliasów i interfejsów XFRM nie można tutaj wyłączyć niezależnie.

Po wyłączeniu interfejsu jego konfiguracja pozostaje zachowana. Tunele IPsec, dla których zapora jest inicjatorem, są rozłączane natychmiast. Tunele, w których zapora odpowiada, oraz połączenia Remote Access kończą się najpóźniej z powodu bezczynności albo Dead Peer Detection.

Interfejs wirtualny usuwa się w Network > Interfaces za pomocą Menu > Delete interface. Tę czynność należy wykonać dopiero po użyciu Refresh w Object usage, udokumentowanym sprawdzeniu zależności oraz przygotowaniu kopii zapasowej i drogi powrotu; usuwa ona nie tylko widoczny wpis interfejsu.

Podczas usuwania interfejsu wirtualnego SFOS usuwa wszystkie reguły zapory, które go używają, nawet jeśli reguła zawiera inne interfejsy. Usuwane są również zależne Zone Bindings, serwery lub przekaźniki DHCP, statyczne wpisy ARP i wpisy proxy ARP, Protected Servers i oparte na nich reguły zapory, Interface Hosts i ich odwołania w grupach, a także trasy unicast i multicast. Interfejsy Alias podążają za swoim interfejsem nadrzędnym; interfejsami XFRM zarządza się przez połączenie IPsec.

Nawet sama edycja może wpływać na Zone Binding, DNS, bramy, trasy i profile SD-WAN, Interface Hosts, sieci VLAN oraz Dynamic DNS. Po edycji lub usunięciu połączenia mogą tymczasowo nie odpowiadać lub przestać działać. Dlatego po każdej zmianie należy sprawdzić rzeczywiste ścieżki danych i zarządzania, a nie tylko zapisany wpis interfejsu.

Celowe usuwanie konfiguracji portu fizycznego

Port fizyczny pozostaje na urządzeniu; można usunąć tylko jego konfigurację. off i Network zone None nie są równoważne: off zachowuje konfigurację, natomiast None usuwa konfigurację IP. Ta czynność służy do celowego zwolnienia portu, który nie jest już potrzebny, a nie jako pierwszy krok naprawczy w przypadku Unplugged lub nieosiągalnej bramy.

⚠️ Przed usunięciem wykonać Object usage > Refresh, udokumentować i przenieść zależności oraz przetestować kopię zapasową i niezależny dostęp administratora. Zapisać adresy IP, maski lub prefiksy, strefę, bramy i aliasy na potrzeby wycofania zmiany. Nie resetować portu przez jedyną ścieżkę dostępu do zarządzania.

1. W Network > Interfaces otworzyć odpowiedni port fizyczny.
2. Ustawić Network zone na None. Konfiguracja IP znika już w formularzu; przed następnym krokiem ponownie sprawdzić identyfikator portu.
3. Zapisać za pomocą Save.
4. W widoku ogólnym muszą pojawić się Unbound, status Disabled i adres IP N/A. Następnie przez niezależny dostęp sprawdzić, czy pozostałe wymagane ścieżki danych i zarządzania nadal działają.

Jeśli zresetowano niewłaściwy port, przywrócić jego poprzednią strefę i konfigurację IP przez niezależny dostęp lub konsolę. Przywrócić usunięte konfiguracje zależne na podstawie wcześniejszej inwentaryzacji lub kopii zapasowej; ponowne przypisanie strefy nie zastępuje tego działania. Na koniec ponownie przetestować łącze, bramę, DHCP, DNS, routing, reguły i Device Access.

HA i zmiany zdalne

Dedykowane interfejsy HA Link należą do strefy DMZ. Inne interfejsy monitorowane lub używane do administracji mogą znajdować się w innych strefach.

Active-Active HA wymaga interfejsów skonfigurowanych statycznie. Cellular WAN jest wyłączany w HA. Active-Passive może korzystać z dynamicznie adresowanych interfejsów WAN, ale połączenia takie jak PPPoE nie zawsze są przejmowane wraz z sesją podczas Failover.

Przed zmianą produkcyjną należy:

1. Udokumentować konfigurację i zależności.
2. Przygotować okno serwisowe, moment wycofania zmiany, kopię zapasową i konkretną drogę powrotu.
3. Przetestować niezależny dostęp administracyjny, na przykład Sophos Fusion (dawniej Sophos Central), drugie łącze WAN, osobną sieć zarządzającą albo pomoc osoby na miejscu.
4. Przygotować klienta testowego lub jednoznaczny ruch testowy, a następnie dodać i sprawdzić nową strefę lub nową ścieżkę.
5. Skontrolować łącze, IP, Gateway, DHCP, DNS, reguły zapory, NAT i Device Access.
6. Usunąć stare obiekty dopiero wtedy, gdy nowa ścieżka działa stabilnie.

Dla VLAN Trunk droga powrotu powinna uwzględniać poprzednie VLAN ID, Native VLAN i profil portu przełącznika. Przy zmianach WAN ważne są wartości operatora i trasy SD-WAN, a przy XFRM dodatkowo tunel, routing i oba kierunki reguł zapory.

Systematyczna diagnostyka

Przyczynę zwykle można szybciej zawęzić, zaczynając od objawu:

• Interfejs jest unbound lub disabled: Najpierw sprawdzić, czy celowo nie przypisano portowi strefy lub czy interfejs został wyłączony. Jeśli port był wcześniej używany produkcyjnie, porównać oczekiwaną strefę i konfigurację IP z udokumentowaną konfiguracją i przywrócić je przez niezależny dostęp. None nie jest naprawą, lecz usuwa konfigurację IP; celową procedurę opisano powyżej w sekcji Celowe usuwanie konfiguracji portu fizycznego.
• VLAN nie działa: porównać VLAN ID, Parent Interface, Trunk, Tagged/Untagged i Native VLAN.
• Zapora nie odpowiada na Ping, HTTPS lub DNS: sprawdzić Device Access i Local Service ACL, a nie najpierw zwykłą regułę zapory.
• Ruch wewnętrzny jest blokowany: sprawdzić Source zone, Destination zone, obiekty sieciowe, routing, Services i kolejność reguł.
• WAN Gateway pozostaje nieaktywny: sprawdzić łącze, IP, Gateway, dane dostępowe PPPoE i WAN Link Manager.
• Kilka portów WAN znajduje się w tej samej podsieci: unikać problemów z ARP i rozważyć Alias albo LAG.
• SFP lub Port Speed nie pasuje: artykuł Systematyczna diagnostyka SFP i SFP+ pokazuje, jak porównać Transceiver, kabel, Breakout i prędkość po obu stronach.
• VPN lub PPPoE działa niestabilnie: sprawdzić MTU i MSS.

Właściwą diagnostykę najlepiej prowadzić w następującej kolejności:

1. Network > Interfaces: łącze, IP, Zone i Gateway
2. Network > Zones: typ strefy i Device Access
3. Hosts and services: obiekty sieciowe i Service Objects
4. Firewall rules: kierunek, kolejność, Services i Logging
5. NAT rules: Original i Translation
6. Log viewer: Rule ID albo przyczyna odrzucenia
7. Diagnostics > Tools > Packet capture: wejście pakietu i jego dalsze przekazanie

Jeśli reguła wygląda poprawnie, ale nie jest dopasowywana, pomaga artykuł Reguła zapory nie działa. Przepływ pakietów wyjaśnia artykuł Korzystanie z Packet Capture w WebAdmin.

Lista kontrolna eksploatacji

• strefy zaplanowane i udokumentowane według poziomu zaufania
• brak pomylenia strefy, interfejsu i obiektu sieciowego
• sprawdzone VLAN ID, Parent, Trunk i Gateway
• ograniczony Device Access, zwłaszcza dla HTTPS, SSH, DNS, Ping i portali
• utworzone reguły zapory z konkretnymi strefami, sieciami, usługami i Logging
• sprawdzony Alias dla dodatkowych adresów IP operatora w tej samej podsieci
• przetestowane DHCP, DNS, NTP, routing i w razie potrzeby NAT
• zaktualizowane i sprawdzone Object Usage przed zmianami
• przygotowany niezależny dostęp administracyjny i droga powrotu
• sprawdzone po zmianie stan łącza, Log Viewer i Packet Capture

FAQ