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.

Konfigurację Gateway otrzymują tylko interfejsy w strefie WAN. Interfejsy wewnętrzne zwykle mają adresację statyczną, natomiast połączenia WAN mogą być skonfigurowane statycznie, przez DHCP albo PPPoE.

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

W Advanced settings należy dopasować Link mode, Auto-negotiation for media type, zależną od modelu funkcję Forward Error Correction (FEC), 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. SFOS nie obsługuje oznaczania DSCP dla ruchu DHCP i ARP generowanego przez system; polityka nie może zakładać priorytetowej obsługi tych pakietów.

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:

set network interface-link Port2 linkmode auto autoneg on
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.

Adres MAC nadpisuje się wyłącznie dla potwierdzonej zależności projektowej. Adres przykładowy jest administrowany lokalnie, ale w rzeczywistej sieci nadal musi być unikalny:

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

Przed override sprawdza się Port Security, bindingi DHCP, allowlisty operatora, HA i LAG. default przywraca istniejący domyślny adres MAC portu. 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 liczbę komunikatów Neighbor Solicitation wysyłanych przez zaporę podczas Duplicate Address Detection. 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ń.

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. 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. 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 w tunelu włącza się osobno dla strefy VPN.

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.

Usunięcie interfejsu wirtualnego usuwa w SFOS 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 relaye DHCP, wpisy ARP, Protected Servers, Interface Hosts i ich odwołania w grupach, a także trasy unicast i multicast. Interfejsy Alias przejmują stan Parent Interface, a interfejsami XFRM zarządza się przez połączenie IPsec.

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:

• Interface jest unbound lub disabled: samego portu fizycznego nie można usunąć. Aby usunąć tylko jego konfigurację, otworzyć port w Network > Interfaces, ustawić Network zone na None i zapisać. SFOS pokazuje następnie interfejs jako Unbound, status jako Disabled, a adres IP jako N/A. Najpierw należy sprawdzić Object Usage i administracyjną drogę odzyskiwania.
• 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