Konfiguracja i rozwiązywanie problemów z Sophos SD-RED

Sophos SD-RED umożliwia połączenie oddziałów, filii lub mniejszych lokalizacji domowych z zaporą Sophos. RED tworzy zaszyfrowany tunel do zapory i zapewnia sieć w zdalnej lokalizacji, która jest centralnie zarządzana przez zaporę.

Praktyczna zaleta: na miejscu zazwyczaj nie jest potrzebna skomplikowana konfiguracja VPN. SD-RED łączy się z Internetem, pobiera swoją konfigurację za pośrednictwem usługi Sophos RED Provisioning Service i następnie tworzy tunel do zapory Sophos. Sam tunel nie rozwiązuje jednak wszystkich problemów. Strefy, zasady zapory, DHCP, VLAN-y, routing, DNS i wersja oprogramowania muszą również być odpowiednie.

Tryb pracy trzeba wybrać jeszcze przed właściwą konfiguracją. Określa on DHCP, bramę, ścieżkę internetową, centralną kontrolę i zachowanie podczas awarii tunelu. Wybór właściwego trybu pracy Sophos RED wyjaśnia różnice i kryteria decyzji.

Planowanie i wymagania

Klasyfikacja: SD-RED i RED między zaporami

RED ma dwa aktualne zastosowania, które trzeba rozdzielić. Ten artykuł dotyczy fizycznego urządzenia SD-RED 20 lub SD-RED 60 w oddziale. SFOS 22 nadal obsługuje również tunel Site-to-Site RED między dwiema Sophos Firewall, gdzie jedna zapora działa jako Firewall RED server, a druga jako Firewall RED client.

Drugi przypadek nie wymaga sprzętu RED. Konfiguracja Site-to-Site RED między dwiema Sophos Firewall opisuje plik provisioningu, trasy statyczne bez wybranego interfejsu, reguły po obu stronach i usługę RED. Tryby pracy SD-RED nie dotyczą tej architektury.

Wymagania w głównej lokalizacji

Przed podłączeniem RED, na zaporze Sophos powinny być jasne następujące punkty:

• Usługa RED jest aktywowana na zaporze.
• Publiczny adres IP lub nazwa DNS/DynDNS zapory jest osiągalna.
• Połączenia RED z zaporą są dozwolone po stronie WAN.
• RED jest dozwolone w Administration > Device access dla odpowiedniej strefy WAN lub jest celowo odblokowane przez Local Service ACL.
• Interfejs RED, strefa i konfiguracja IP są zaplanowane.
• Zasady zapory z sieci RED do sieci docelowych są przewidziane.
• DHCP, DHCP Relay lub statyczne adresowanie dla klientów za RED jest wyjaśnione.
• Pakiet oprogramowania układowego RED (RED Firmware Pattern) na zaporze jest aktualny.
• Kopia zapasowa i wersja oprogramowania zapory są udokumentowane przed większymi zmianami.

Dla komunikacji RED szczególnie istotne są TCP 3400, UDP 3410 i NTP 123. Te połączenia nie mogą być blokowane przez routery dostawcy, zapory lub bramy bezpieczeństwa.

Wymagania w zdalnej lokalizacji

W zdalnej lokalizacji SD-RED potrzebuje stabilnego połączenia z Internetem. Decydująca jest nie tylko przepustowość, ale przede wszystkim stabilność, opóźnienie, utrata pakietów i czy dostawca pozwala na wymagane połączenia.

Należy sprawdzić:

• Połączenie internetowe jest stabilne.
• Port WAN RED otrzymuje adres przez DHCP lub ma poprawną statyczną konfigurację.
• Brama domyślna jest osiągalna.
• DNS działa.
• NTP jest osiągalne.
• TCP 3400, UDP 3410 i NTP 123 nie są blokowane.
• Router dostawcy lub zapora nie wykonuje nieoczekiwanego filtrowania.
• W przypadku VLAN-ów jest jasne, który port działa jako tagged, untagged lub hybrid.

Dla prostych lokalizacji często wystarcza małe łącze. W praktyce jednak częściej przyczyną są utrata pakietów, niestabilne routery konsumenckie, CGNAT, problemy z DNS lub restrykcyjne zapory dostawcy niż sama przepustowość.

Provisioning i uruchomienie

Automatyczny provisioning przez Sophos Provisioning Service

Do standardowego provisioningu online firewall i SD-RED potrzebują dostępu do internetu. Podczas pierwszego uruchomienia SD-RED musi otrzymać adres WAN przez DHCP, aby pobrać konfigurację. Statyczna konfiguracja WAN wymaga więc ręcznego provisioningu przez USB. Na firewallu w System services > RED włącza się usługę provisioningu RED, podaje dane kontaktowe i akceptuje warunki użytkowania Sophos.

Następnie w Network > Interfaces > Add interface > Add RED tworzy się interfejs. Dla lokalizacji ustawia się Branch name, typ urządzenia, Automatically via provisioning service, adres firewalla, uplink, tryb pracy, sieć RED, strefę i DHCP. Dla RED używanego po raz pierwszy pole Unlock code pozostaje puste. Po zapisaniu firewall przesyła konfigurację do usługi provisioningu. SD-RED pobiera ją, otwiera kanał sterujący na TCP 3400, a następnie zestawia tunel warstwy 2 na UDP 3410.

Dla własnej strefy RED w Network > Zones > Add wprowadź nazwę, np. RED-Branch, ustaw Type na LAN lub DMZ, a w Device access wybierz tylko rzeczywiście potrzebne usługi. Zapisz za pomocą Save i wybierz tę strefę w RED network settings na interfejsie RED. Natomiast w Administration > Device access włącz usługę RED dla strefy, z której RED dociera do zapory, zwykle WAN; zastosuj za pomocą Apply. Strefa klientów za RED i strefa wejściowa tunelu RED nie są tym samym.

Przy pierwszym zapisaniu usługa provisioningu generuje kod odblokowujący właściwy dla urządzenia. Kod jest widoczny w WebAdmin i zostaje wysłany na adres e-mail skonfigurowany w System services > RED. Trzeba go bezpiecznie zachować, ponieważ jest wymagany podczas przenoszenia RED na inny firewall. WebAdmin wyświetla go ponownie podczas usuwania interfejsu. Jeśli kod nie jest dostępny, należy skontaktować się z Sophos Support.

Świadomie ustawić globalne zabezpieczenia RED

Podczas pierwszej aktywacji w System services > RED SFOS tworzy certyfikat do komunikacji RED na podstawie pól Organization name, City, Country i Email. Dlatego Organization name i City nie mogą zawierać umlautów ani znaków specjalnych. Adres e-mail musi pozostać dostępny, ponieważ Sophos wysyła na niego nowe kody odblokowujące.

Dla aktualnych urządzeń SD-RED 20 i 60 rozsądnym punktem wyjścia jest TLS v1.2 (strict) and later. Ten wybór używa wyłącznie szyfrów TLS 1.2 zalecanych przez Sophos. TLS v1.2 and later obejmuje dodatkowo szyfry, których Sophos nie zaleca, i nie powinien być wybierany bez potwierdzonej potrzeby zgodności. Po zmianie należy w kontrolowany sposób ponownie połączyć i przetestować wszystkie produkcyjne tunele RED.

Automatic device deauthorization zapobiega bezterminowemu utrzymywaniu autoryzacji RED, który był odłączony przez długi czas. Okres musi pasować do własnego procesu obsługi awarii i wymiany: po jego upływie urządzenie nie jest usuwane, ale interfejs RED trzeba wyraźnie ponownie włączyć w Network > Interfaces. Dlatego monitorowanie i dokumentacja kodu odblokowującego są częścią tego zabezpieczenia.

Dla SD-RED 20 i 60 pozostaw RED unified firmware włączone. Nowy pakiet firmware RED instaluje się świadomie w Backup & firmware > Pattern updates i nie jest on wdrażany automatycznie. Należy zaplanować okno serwisowe, a następnie przetestować tunel i klienta.

Aby skonfigurować tę funkcję, włącz Automatic device deauthorization, określ czas pozostawania bez połączenia, po którego upływie autoryzacja zostanie cofnięta, i wybierz Apply. Urządzenie RED, którego autoryzacja została cofnięta po upływie tego czasu, włącz ponownie w sekcji Network > Interfaces za pomocą Menu po prawej stronie danego urządzenia. Funkcja ochrony dotyczy również Firewall RED Client. RED unified firmware jest domyślnie zaznaczone; jednak podczas migracji zapory zachowywane jest istniejące ustawienie. Po przywróceniu ustawień fabrycznych opcja jest ponownie zaznaczona. Dlatego po migracji lub resecie sprawdź rzeczywistą wartość, zamiast zakładać wartość domyślną.

Podłączanie SD-RED

Typowy przebieg:

1. Podłącz port WAN SD-RED do routera dostawcy lub modemu.
2. Podłącz port LAN do klienta testowego, przełącznika lub lokalnej sieci.
3. Podłącz SD-RED do zasilania.
4. Poczekaj, aż RED się uruchomi, sprawdzi bramę i Internet, załaduje konfigurację i zbuduje tunel.
5. Sprawdź na zaporze Sophos, czy interfejs RED jest aktywny.
6. Podłącz klienta testowego za RED i sprawdź IP, DNS, bramę i dostęp do celu.

Jeśli wszystkie odpowiednie LED-y są zielone, tunel techniczny jest gotowy. Następnie zaczyna się właściwe sprawdzanie sieci: strefa, DHCP, zasady zapory, routing zwrotny, DNS i w razie potrzeby VLAN-y.

Ręczny provisioning przez pamięć USB

Zwykle SD-RED jest provisionowany przez Sophos RED Provisioning Service. Ręczny provisioning przez pamięć USB ma sens, gdy urządzenie znajduje się w prywatnej albo mocno ograniczonej sieci, potrzebuje statycznej konfiguracji WAN albo automatyczna ścieżka provisioningu nie działa niezawodnie.

Źródło czasu zapory i dostarczanie czasu do RED to nie to samo: Instrukcja ręcznej konfiguracji RED dla SFOS 22 i 23 opisuje wybór Use custom NTP server w Administration > Time, własny adres IP zapory w Search/Add oraz Add i Apply jako konfigurację serwera NTP dla RED. Dokumentacja ustawień czasu opisuje natomiast to pole jako nadrzędne źródło czasu dla zegara zapory. Role nie są zatem jednoznacznie zgodne; ta procedura nie jest bezwarunkowym wymogiem ani dowodem, że zapora udostępnia NTP dla RED. Bez potwierdzonej ścieżki synchronizacji czasu obsługiwanej w zainstalowanej wersji działająca konfiguracja NTP pozostaje bez zmian. Każdą potwierdzoną zmianę najpierw zaplanować w odniesieniu do udokumentowanego stanu początkowego: zmiana serwerów NTP powoduje ponowne zestawienie wszystkich połączeń IPsec. Jeśli dotyczy to połączeń produkcyjnych, zapewnić okno serwisowe i lokalny lub alternatywny dostęp administracyjny.

Przebieg jest dokładniejszy niż samo skopiowanie pliku provisioningu na USB:

1. Przed ręcznym provisioningiem ustalić ścieżkę synchronizacji czasu obsługiwaną w zainstalowanej wersji i udokumentować działające ustawienia NTP oraz czas i stan synchronizacji zapory. Nie zmieniać globalnego źródła czasu na własny adres IP zapory wyłącznie z powodu tej konfiguracji RED; ograniczenie i kontrolę NTP/HTTPS opisano poniżej.
2. W Network > Zones utworzyć dla lokalizacji RED osobną strefę typu LAN lub DMZ. Oddzielna strefa zapobiega niezamierzonemu stosowaniu ogólnych reguł LAN do zdalnej lokalizacji. Jeśli zamiast niej używana jest strefa VPN, firewall nie odpowiada sam na zapytania DNS klientów RED; DHCP musi wtedy przydzielać inny osiągalny serwer DNS.
3. Pod System services > RED aktywować RED Provisioning Service.
4. Pod Network > Interfaces > Add interface > Add RED utworzyć interfejs RED.
5. Przy Device deployment wybrać Manually via USB stick.
6. Wpisać RED ID, Unlock Code, uplink, RED network settings, strefę, DHCP i VLANy zgodnie z lokalizacją.
7. W Network > Interfaces otwórz Menu interfejsu RED i pobierz przypisany do tego interfejsu plik aprowizacji, wygenerowany po Save.
8. Skopiować plik do katalogu głównego pamięci USB.
9. Wyłączyć RED, włożyć pamięć USB i ponownie włączyć RED.
10. Po starcie sprawdzić interfejs, LEDy, IP klienta, DNS, regułę firewall i dostęp do celów.

Po potwierdzonej zmianie czasu odświeżyć WebAdmin i sprawdzić zegar zapory w Administration > Time, stan synchronizacji oraz połączenia IPsec. Dodatkowo sprawdzić ścieżkę synchronizacji czasu RED, handshake TLS i zestawianie tunelu. W przypadku nieudanej synchronizacji czasu lub regresji przywrócić poprzednie działające źródła czasu i ustawienia w Administration > Time oraz powtórzyć te same kontrole; również ten powrót może spowodować ponowne zestawienie połączeń IPsec.

Jeżeli strona WAN RED używa DHCP, w zdalnej lokalizacji musi faktycznie odpowiadać serwer DHCP. Jeśli RED nie otrzyma adresu, może wpaść w pętlę restartów. Przy statycznej konfiguracji WAN trzeba szczególnie dokładnie sprawdzić IP, gateway, DNS i NTP.

Także RED skonfigurowana przez provisioning offline wymaga prawidłowego czasu mieszczącego się w okresie ważności certyfikatu na potrzeby handshake TLS. Aby bezpośrednio synchronizować czas, musi móc rozwiązywać nazwy od 0.sophos.pool.ntp.org do 3.sophos.pool.ntp.org i łączyć się z nimi przez UDP 123. Jeśli się to nie uda, próbuje synchronizować czas z zaporą przez HTTPS na TCP 4444. Jeśli usługa administracyjna HTTPS nie jest dozwolona dla WAN w Administration > Device access, ten mechanizm awaryjny może nie zadziałać bez ukierunkowanego wyjątku. Nie włączać w tym celu HTTPS ogólnie dla całej strefy WAN: wyjątek zezwala również na usługę administracyjną HTTPS i musi być ściśle ograniczony.

Przed zmianą udokumentować istniejące ustawienia Device Access i ACL oraz sprawdzić, czy odpowiedni wyjątek już istnieje. Za pomocą Diagnostics > Packet capture ustalić adres źródłowy połączenia RED faktycznie obserwowany na zaporze. Za routerem NAT jest to zazwyczaj publiczny adres wyjściowy NAT oddziału, a nie prywatny adres WAN urządzenia RED. Używać wyłącznie jednoznacznie znanego i możliwie stabilnego hosta IP; w przypadku współdzielonego adresu NAT zezwolenie obejmuje także inne urządzenia za tym adresem. Nie zastępować zmiennego lub nieznanego źródła zezwoleniem Any.

1. Otworzyć Administration > Device access > Local service ACL exception rule > Add i nadać unikatową nazwę.
2. Ustawić Source zone na WAN. W Source network or host wybrać host IP dla faktycznie obserwowanego adresu źródłowego; w razie potrzeby utworzyć odpowiedni host IP za pomocą Add.
3. Ustawić Destination host na przewidziany port WAN zapory, Services na HTTPS, a Action na Accept. Zapisać za pomocą Save.
4. Sprawdzić zapisane ograniczenie źródła i host docelowy. Następnie przetestować synchronizację czasu RED, handshake TLS i zestawianie tunelu oraz sprawdzić, czy nie zezwolono na HTTPS dla dodatkowych źródeł WAN.

Jeśli nowo utworzony wyjątek jest potrzebny tylko tymczasowo, usunąć go po teście lub po przywróceniu bezpośredniej ścieżki NTP. Usunąć go także wtedy, gdy jest nieskuteczny lub powoduje niepożądane zezwolenie na dostęp; w przypadku zmiany istniejącego wyjątku przywrócić jego udokumentowany stan początkowy. Następnie ponownie sprawdzić ograniczenie źródła, osiągalność HTTPS i tunel RED. Udokumentować wyjątek wymagany na stałe wraz z adresem źródłowym NAT i regularnie go weryfikować.

Status, aktualizacje i migracja

Zrozumienie statusu LED

Wskaźniki LED są często najszybszym punktem wyjścia przy rozwiązywaniu problemów z RED, ponieważ pokazują, na którym etapie proces uruchamiania się zatrzymuje.

Legenda:

• ⚫ wyłączone
• 🟢 świeci zielono
• 🟢 miga zielono
• 🔴 świeci czerwono
• 🔴 miga czerwono

W zależności od kąta widzenia, zdjęcia lub oświetlenia otoczenia, LED może wyglądać na żółtą lub pomarańczową. Dla diagnozy liczy się przede wszystkim, która LED świeci lub miga i czy jest zielona czy czerwona.

Normalny proces uruchamiania

Jeśli wszystkie cztery LED-y świecą na zielono, ale ruch nie działa, problem zazwyczaj nie leży już w budowie tunelu. Wtedy bardziej prawdopodobne są zasady zapory, DHCP, VLAN-y, DNS, NAT lub routing.

Kody błędów

Failover 3G/4G

W modelach SD-RED z failoverem 3G/4G lub odpowiednim modułem mogą wystąpić dodatkowe wzorce.

Kontrola aktualizacji oprogramowania układowego

Jeśli diody LED migają razem, RED może właśnie instalować firmware. W tej fazie nie należy wyłączać urządzenia ani odłączać go od Internetu. Aktualizacja może potrwać kilka minut. Interpretacja musi pasować do konkretnego wzorca LED i modelu; samo jednoczesne miganie nie jest jednoznaczną diagnozą dotyczącą firmware, co pokazują także wzorce failover.

Na zaporze Sophos należy dodatkowo sprawdzić:

Backup & firmware > Pattern updates

Tam pakiet oprogramowania układowego RED musi być aktualny. Według Sophos pobieranie i instalacja trwają od pięciu do dziesięciu minut. Jeśli RED utknie w pętli lub po aktualizacji zapory nie uruchamia się poprawnie, warto sprawdzić, czy pakiet oprogramowania układowego RED nie jest przestarzały. Współdziałanie stanów, automatycznego pobierania i świadomej instalacji wyjaśnia artykuł Konfiguracja i sprawdzanie aktualizacji pakietów Pattern Updates Sophos Firewall.

Powiązane życzenie operacyjne opisano w Sophos Firewall Feature Request 2024: Przy aktualizacjach oprogramowania układowego RED i punktów dostępowych często brakuje bezpośrednio widocznych notatek o wydaniu w backendzie. Dla środowisk produkcyjnych aktualizacje powinny być zatem świadomie planowane i nie instalowane niekoordynowanie podczas krytycznych godzin pracy.

Sprawdzanie interfejsu RED, strefy i zasad

Po pomyślnym utworzeniu tunelu RED wymaga prawidłowej konfiguracji zapory.

Typowe punkty kontrolne:

• Interfejs RED jest aktywny w Network > Interfaces.
• Interfejs znajduje się w odpowiedniej strefie.
• Serwer DHCP lub DHCP Relay jest poprawnie skonfigurowany.
• Klienci otrzymują adres IP, bramę i DNS.
• Zasady zapory pozwalają tylko na potrzebne cele.
• Routing zwrotny do sieci RED działa.
• NAT jest używany tylko wtedy, gdy jest świadomie zaplanowany.
• Konfiguracja VLAN pasuje do trybu RED i portu przełącznika.

Do pierwszego testu funkcjonalnego wystarczy ściśle ograniczona reguła w Rules and policies > Firewall rules: ustawić Source zone na osobną strefę RED-Branch, w Source networks and devices wskazać sieć klientów RED, a jako cel dopuścić wyłącznie potrzebną wewnętrzną sieć testową. Dostęp do internetu wymaga osobnej reguły ze strefą WAN jako celem i zaplanowaną obsługą NAT. Następnie należy ograniczyć cele i usługi do potrzeb produkcyjnych. Pozwala to sprawdzić właściwą ścieżkę bez udostępniania oddziałowi wszystkich sieci wewnętrznych.

Dla podstaw zasad pasuje Zrozumienie i prawidłowa konfiguracja zasad zapory Sophos. Jeśli tunel jest gotowy, ale ruch nie płynie, należy połączyć Log Viewer i Packet Capture.

Opcjonalne ustawienie MAC filtering type może zastosować w sieci RED listę dozwolonych lub blokowanych adresów o limicie zależnym od urządzenia, ale nie zastępuje reguły firewall. Remote IP assignment również nie jest ustawieniem domyślnym: przypisuje przez DHCP lub statycznie adres do bridge’a z tunelem RED po stronie WAN i jest rozważane tylko wtedy, gdy urządzenia za RED nie odpowiadają na żądania ARP. Żadnej z tych opcji nie należy włączać jako ogólnej poprawki wydajności lub łączności.

Pułapki aktualizacji i migracji

Nie mylić Site-to-Site RED z SD-RED

Tunel RED między zaporami pozostaje w SFOS 22 obsługiwaną, odrębną architekturą. Nie korzysta z żadnego z czterech trybów pracy SD-RED i nie jest definiowany przez DHCP ani porty LAN urządzenia SD-RED. Podczas aktualizacji inwentaryzuje się oba typy RED, a następnie sprawdza każdy z nich odpowiednim testem funkcjonalnym.

W szerszym planowaniu aktualizacji pomaga Prawidłowe planowanie aktualizacji oprogramowania układowego Sophos Firewall. Pełny proces między zaporami opisuje Konfiguracja Site-to-Site RED między dwiema Sophos Firewall.

Usunąć starsze interfejsy Firewall RED i stare urządzenia RED przed SFOS 22

SFOS 22.0 i nowsze wersje nie obsługują już Firewall RED Server Legacy ani Firewall RED Client Legacy. Dopóki istnieje taka konfiguracja UTM-SFOS, aktualizacja, przywracanie i import konfiguracji do SFOS 22 są zablokowane. Nie dotyczy to obecnych typów Firewall RED server i Firewall RED client. Przed aktualizacją należy zastąpić wszystkie zależności starszych interfejsów, usunąć interfejsy, a następnie utworzyć nową kopię zapasową konfiguracji.

Urządzenia RED 15, RED 15w i RED 50 również osiągnęły koniec okresu eksploatacji. Ich tunele nie łączą się od SFOS 20.0 MR1. Po aktualizacji lub przywróceniu do SFOS 22 stara konfiguracja pozostaje widoczna, ale nie jest stosowana i można ją tylko usunąć. Nie można jej zaimportować. Przed aktualizacją należy przenieść te lokalizacje na SD-RED 20 lub SD-RED 60 i przetestować rzeczywistą ścieżkę danych.

Poprawiona maska /32 dla hostów systemowych RED

Sophos poprawił maskę podsieci automatycznie generowanych obiektów hostów systemowych RED na /32 w SFOS 21.0 MR2 i 21.5 MR1. Jeśli wcześniej obiekty te były używane w regułach lub innych konfiguracjach dla wielu adresów hostów, po aktualizacji ruch może być dopasowywany inaczej.

Sprawdź zależności w Hosts and services > IP host już przed aktualizacją: Otwórz Usage dla każdego hosta systemowego RED i zastąp hosta systemowego odpowiednim hostem IP lub Network w wymienionych regułach zapory, trasach i pozostałych konfiguracjach. Przykład: Dla adresu RED 192.168.1.1/24 host systemowy miał wcześniej wartość 192.168.1.1/24, a teraz ma 192.168.1.1/32. Reguła lub trasa dla całej sieci musi zatem używać jawnie zdefiniowanego hosta Network; host systemowy obejmuje teraz tylko skonfigurowany adres IP interfejsu. Po aktualizacji ponownie przetestuj dopasowania reguł i ścieżkę danych.

Po aktualizacji należy zatem sprawdzić:

• Czy hosty systemowe RED są używane w zasadach zapory?
• Czy zasada nieoczekiwanie oczekuje sieci zamiast pojedynczego hosta?
• Czy trzeba zastąpić obiekty IP Host lub Network Host?
• Czy dopasowania zasad w Log Viewer są nadal poprawne?

RED i failover HA

W środowiskach HA lokalizacje RED należy świadomie testować po failoverze. Sophos wskazuje, że tunele RED po failoverze HA nie zawsze od razu łączą się ponownie z urządzeniem auxiliary. Czas zależy między innymi od liczby interfejsów i konfiguracji.

Dla krytycznych lokalizacji nie wystarczy sprawdzić status HA firewalla. Należy sprawdzić także:

• status interfejsu RED po failoverze
• dostęp klientów za RED
• istotne dopasowania reguł firewall
• DNS i DHCP za RED
• alerty monitoringu przy dłuższej przerwie tunelu

Sprawdzanie przepustowości i wydajności RED

Sophos podaje maksymalną przepustowość tunelu 250 Mbit/s dla SD-RED 20 oraz 850 Mbit/s dla SD-RED 60. Są to maksymalne wartości platformy, a nie gwarancja dla pojedynczego transferu SMB, testu prędkości w przeglądarce czy jednego strumienia TCP. Na wynik wpływają również endpointy, pamięć masowa, okno TCP, rzeczywiste opóźnienie między lokalizacjami, utrata pakietów, trasa operatora, obciążenie zapory i profile bezpieczeństwa.

Ping wynoszący na przykład 8 ms do publicznego serwera testu prędkości nie musi odzwierciedlać opóźnienia między dwiema lokalizacjami RED. Test prędkości na każdym łączu internetowym również nie sprawdza szyfrowanej ścieżki end-to-end przez tunel RED. Do tej oceny potrzebny jest serwer testowy w jednej sieci LAN i klient testowy w sieci LAN drugiej lokalizacji.

Testowanie tunelu RED za pomocą iPerf3 w obu kierunkach

Przed testem tunelu należy utworzyć lokalną wartość odniesienia z tymi samymi przewodowymi endpointami. Następnie uruchamia się iPerf3 przez tunel RED, najpierw z jednym strumieniem TCP, potem w kierunku odwrotnym, a na końcu z czterema strumieniami równoległymi:

iperf3 -c 10.10.10.50 -t 30
iperf3 -c 10.10.10.50 -t 30 -R
iperf3 -c 10.10.10.50 -t 30 -P 4

10.10.10.50 jest tylko przykładowym adresem i trzeba go zastąpić adresem IP serwera iPerf3 w zdalnej sieci LAN. Test celowo generuje obciążenie i powinien być wykonywany w odpowiednim oknie serwisowym. Artykuł Prawidłowe testowanie wydajności Sophos Firewall za pomocą iPerf3 opisuje instalację, tymczasową regułę zapory, testy UDP i pełną analizę wyników.

Trzy wyniki odpowiadają na różne pytania:

• Jeśli lokalna wartość odniesienia jest już niska, najpierw sprawdzić endpointy, karty sieciowe, sterowniki, kable, switche i pamięć masową.
• Jeśli jeden strumień jest znacznie wolniejszy niż -P 4, ograniczeniem jest raczej opóźnienie, okno TCP albo pojedynczy przepływ aplikacji. Nie stanowi to jeszcze dowodu na limit RED.
• Jeśli jeden i cztery strumienie zatrzymują się na tej samej granicy w obu kierunkach, zbadać fizyczne łącza, trasę operatora, utratę pakietów, konfigurację RED i obciążenie zapory.
• Jeśli wolny jest tylko jeden kierunek, porównać odpowiednie prędkości wysyłania, liczniki interfejsów, błędy, dropy i trasę powrotną.

Przykładowy wynik z praktyki mógłby wynosić około 400 Mbit/s z jednym strumieniem i od 700 Mbit/s do 800 Mbit/s z -P 4. Wskazuje to, że ścieżka może przenosić znacznie większą łączną przepustowość, mimo że pojedynczy przepływ TCP lub SMB nie wykorzystuje jej w pełni. Nie gwarantuje to, że każda aplikacja osiągnie taki sam wynik wielostrumieniowy.

Podczas każdego przebiegu należy dokumentować rzeczywisty round-trip time i utratę pakietów między lokalizacjami, retransmisje iPerf, Firewall Rule ID, profile bezpieczeństwa, użycie CPU zapory oraz liczniki uczestniczących portów. Łącza WAN i LAN muszą rzeczywiście pracować z prędkością 1 Gbit/s, w trybie Full Duplex i bez rosnących liczników błędów lub dropów. Prędkość i duplex należy pozostawić w trybie auto-negotiation po obu stronach, zamiast wymuszać gigabit tylko po jednej stronie.

Nie należy ogólnie wyłączać IPS ani innych profili bezpieczeństwa. Do testu A/B można użyć co najwyżej wąskiej reguły tymczasowej dla konkretnego źródła testu, celu i usługi iPerf3, a następnie natychmiast ją usunąć. Jeśli wynik nie zmienia się bez IPS, IPS jest mniej prawdopodobną przyczyną dla tej konkretnej ścieżki testowej.

Faktyczne wyłączenie 802.3az lub EEE

Dla optymalnej wydajności Sophos zaleca wyłączenie 802.3az na switchach połączonych z urządzeniem SD-RED 20 lub SD-RED 60. Chodzi o Energy Efficient Ethernet, w skrócie EEE. Przy niskim wykorzystaniu łącza EEE przełącza część układu Ethernet PHY w stan Lower Power Idle, oszczędzając energię. Nie jest to to samo co PoE ani 802.3x Flow Control.

Ustawienie nie znajduje się w WebAdmin ani w CLI Sophos Firewall, ani w udokumentowanym ekranie SD-RED. Zmienia się je na bezpośrednio podłączonym porcie switcha. Dotyczy to używanych połączeń LAN z RED, a jeśli uczestniczy w nim zarządzalny switch lub router, także fizycznego łącza WAN. Na urządzeniach innych producentów opcja może nazywać się EEE, Energy Efficient Ethernet, Green Ethernet, 802.3az lub Power Saving. Nie istnieje uniwersalna CLI.

Na Sophos Switch używa się strony Port settings:

1. Wybrać port bezpośrednio połączony z SD-RED.
2. Otworzyć Edit.
3. Ustawić EEE status na Off.
4. Zapisać przyciskiem Apply.
5. Sprawdzić status łącza, wynegocjowaną prędkość, duplex i liczniki błędów, a następnie powtórzyć ten sam test iPerf3.

Na aktualnym Sophos Switch stan można wyświetlić w CLI w trybie read-only:

show eee

Dla przykładowego portu 0/1 EEE wyłącza się następująco:

configure terminal
interface gigabitethernet 0/1
no eee
exit
exit
save
show eee

0/1 trzeba zastąpić portem rzeczywiście połączonym z RED. no eee zmienia konfigurację portu. Jeśli switch jest dostępny tylko przez tę ścieżkę RED, potrzebne są okno serwisowe oraz lokalny lub alternatywny dostęp administracyjny. W zależności od switcha i firmware zmiana może wywołać ponowną negocjację łącza.

Aby przywrócić poprzedni stan na Sophos Switch, w tym samym Interface Configuration Mode używa się eee zamiast no eee:

configure terminal
interface gigabitethernet 0/1
eee
exit
exit
save
show eee

Wyłączenie EEE nie wyłącza Ethernetu ani gigabitu. Wadą jest to, że układ PHY nie oszczędza już takiej samej ilości energii w okresach bezczynności, dlatego port zużywa nieco więcej energii i może generować więcej ciepła. Nie ma gwarancji konkretnego wzrostu przepustowości. Decydujący jest powtarzalny test przed zmianą i po niej. Na niezarządzalnym switchu bez opcji EEE nie można niezawodnie zmienić tego ustawienia; do testu trzeba ominąć urządzenie albo tymczasowo użyć zarządzalnego switcha.

Zmiana Tunnel compression i MTU tylko w kontrolowanym teście

Interfejs RED edytuje się w Network > Interfaces. Dostępne są tam ustawienia Tunnel compression i MTU. Sophos opisuje Tunnel compression jako sposób kompresji ruchu RED i zwiększenia przepustowości, zwłaszcza na wolnych łączach. Danych już skompresowanych lub zaszyfrowanych praktycznie nie da się dalej zmniejszyć, natomiast kompresja powoduje dodatkowe obciążenie obliczeniowe. Dlatego jedno ustawienie nie jest właściwe dla każdej lokalizacji.

W teście A/B najpierw dokumentuje się stan początkowy i pomiary. Następnie zmienia się tylko Tunnel compression, zapisuje konfigurację i powtarza dokładnie tę samą serię iPerf3. Potem należy przywrócić stan początkowy albo świadomie udokumentować wariant, którego przewaga została potwierdzona. Zapis może na krótko przerwać tunel RED, dlatego wskazane są okno serwisowe i alternatywny dostęp.

MTU nie jest ogólnym regulatorem prędkości. Należy je badać tylko wtedy, gdy małe pakiety działają, ale większe transfery zatrzymują się, widoczna jest fragmentacja albo iPerf3 pokazuje wiele retransmisji. Artykuł Sprawdzanie MTU i MSS Sophos Firewall przy problemach z VPN opisuje bezpieczny test DF, rozmiary pakietów i przywracanie stanu. Bez powtarzalnego wyniku wskazującego na MTU pozostawia się udokumentowaną wartość początkową.

Rozwiązywanie problemów

Nie można utworzyć ani edytować interfejsu RED

Jeśli już utworzenie lub zapisanie interfejsu RED kończy się niepowodzeniem, najpierw sprawdź uprawnienia administratora, sprzeczne konfiguracje, identyfikator RED i Unlock Code. Sama zapora musi mieć dostęp do Provisioning Server; test wyłącznie w sieci WAN urządzenia RED nie wystarcza do ustalenia tego. Nawiązywanie połączenia można sprawdzić w 5. Device Management > 3. Advanced Shell na zaporze:

telnet red.astaro.com 3400

Pomyślne nawiązanie połączenia potwierdza jedynie rozwiązywanie nazw DNS i TCP 3400 z tej zapory. Nie potwierdza ani rejestracji, ani Unlock Code. W razie niepowodzenia sprawdź ścieżkę wychodzącą zapory; jeśli test się powiedzie, kontynuuj badanie uprawnień i konkretnej konfiguracji. Nie usuwaj pochopnie istniejącego interfejsu.

Nie można zmienić adresu IP RED w SFOS 22.0 MR2

W SFOS 22.0 MR2 Build 546 podczas zmiany adresu IP istniejącego interfejsu RED może pojawić się komunikat Failed to update RED interface. Problem polega na tym, że WebAdmin może już wyświetlać nowy adres IP, mimo że zapora wewnętrznie nadal używa starego adresu. Sam adres IP widoczny w interfejsie nie potwierdza więc jeszcze powodzenia zmiany.

Udokumentowane przez Sophos obejście polega również na zmianie nazwy oddziału i ponownym zapisaniu interfejsu:

1. Udokumentuj aktualny adres IP RED, maskę sieci, Branch Name oraz istniejący zakres DHCP dla RED.
2. W Network > Interfaces otwórz odpowiedni interfejs RED i wprowadź żądany adres IP.
3. Jeśli pojawi się Failed to update RED interface, ponownie otwórz interfejs.
4. Faktycznie zmień Branch Name, na przykład z Branch-Zurich na Branch-Zurich-01, i ponownie zapisz za pomocą Save.
5. W 5. Device Management > 3. Advanced Shell sprawdź za pomocą polecenia tylko do odczytu ifconfig, czy nowy adres jest aktywny na interfejsie RED:

ifconfig

Nazwa interfejsu zależy od konfiguracji i można ją ustalić w Network > Interfaces. Ponowne uruchomienie urządzenia, restart usługi ani usunięcie interfejsu RED nie są częścią tego obejścia.

Jeśli nowy adres IP RED znajduje się w innej sieci niż dotychczasowy zakres DHCP dla RED, SFOS wyłącza serwer DHCP RED. Jest to normalne zachowanie produktu, niezależne od komunikatu o błędzie. W Network > DHCP należy wtedy dostosować istniejący serwer do nowej sieci lub utworzyć nowy serwer DHCP. Zakres dzierżaw, statyczne przypisania MAC, brama i DNS muszą odpowiadać nowej adresacji.

Na koniec odnów dzierżawę DHCP na kliencie za RED i sprawdź adres IP, bramę, DNS, status tunelu oraz przewidziany dostęp. W Log Viewer ruch powinien ponownie trafiać do oczekiwanej zasady zapory. Jeśli adres IP w backendzie pozostaje stary mimo ponownego zapisania, dla NC-184971 nie udokumentowano obecnie opublikowanej poprawki produkcyjnej. Nie należy usuwać zależnych zasad ani interfejsów na próbę; zamiast tego trzeba zabezpieczyć konfigurację i skontaktować się ze wsparciem Sophos.

RED nie otrzymuje adresu IP

Jeśli RED utknie na etapie routera lub kod błędu wskazuje na DHCP lub bramę, przyczyna zazwyczaj leży w zdalnej lokalizacji.

Sprawdź:

• Czy router dostawcy przydziela adres IP przez DHCP?
• Czy kabel sieciowy jest poprawnie podłączony do portu WAN?
• Czy brama domyślna jest osiągalna?
• Czy statyczny adres IP został w pełni wprowadzony?
• Czy adres IP, maska podsieci, brama i DNS są poprawne?
• Czy jakieś urządzenie pośrednie blokuje ruch?

Jeśli DHCP w zdalnej lokalizacji nie działa, RED może utknąć w pętli restartu.

RED nie osiąga Internetu

Jeśli router lub brama są osiągalne, ale dioda LED Internetu nie świeci się na stałe na zielono, problem zazwyczaj leży za lokalnym routerem.

Sprawdź:

• Czy połączenie internetowe działa z normalnym klientem?
• Czy DNS działa?
• Czy NTP jest osiągalne?
• Czy TCP 3400, UDP 3410 lub NTP 123 są blokowane?
• Czy istnieje proxy lub zapora między RED a Internetem?
• Czy połączenie dostawcy jest wystarczająco stabilne?
• Czy usługa provisioningu jest osiągalna przez HTTPS na TCP 443?

W przypadku provisioningu RED urządzenie musi osiągać Sophos Provisioning Service. Sophos dokumentuje w tym celu *.astaro.com przez TCP 3400 i UDP 3410; pozostałe cele producenta i granice weryfikacji opisuje artykuł Sprawdzanie usług i portów wychodzących Sophos Firewall.

Klient w tej samej sieci co port WAN urządzenia RED może poleceniem telnet red.astaro.com 3400 sprawdzić rozwiązywanie DNS i nawiązanie połączenia TCP. Udane połączenie potwierdza jedynie osiągalność TCP 3400; nie mówi nic o UDP 3410, provisioningu, uwierzytelnianiu ani tunelu RED.

Jeśli połączenie TCP jest nawiązywane pomyślnie, ale rejestracja nadal się nie udaje, Sophos wymienia również duże obciążenie sieci jako możliwą przyczynę. Po sprawdzeniu dostępu do Internetu, DNS i wychodzącego HTTPS na TCP 443 można ponowić próbę rejestracji później. Pomyślny test TCP nie dowodzi ani obciążenia sieci, ani pomyślnej rejestracji; jeśli błędy nadal występują, kontynuuj badanie pozostałych przyczyn.

RED nie osiąga zapory Sophos

Jeśli Internet jest osiągalny, ale tunel nie jest tworzony, należy sprawdzić stronę zapory.

Sprawdź:

• Czy usługa RED jest aktywowana na zaporze Sophos?
• Czy RED jest poprawnie skonfigurowany?
• Czy ID RED i kod odblokowujący są poprawne?
• Czy publiczny IP lub FQDN zapory jest osiągalny?
• Czy Administration > Device access dla RED jest dozwolone w odpowiedniej strefie WAN?
• Czy Local Service ACL pozwala na dostęp z zdalnej lokalizacji?
• Czy TCP 3400 i UDP 3410 docierają do zapory?
• Czy podczas ręcznego provisioningu czas RED umożliwia TLS handshake?
• Czy RED offline osiąga NTP lub zaplanowany wyjątek Local Service ACL?

W Advanced Shell można sprawdzić, czy ruch RED dociera:

tcpdump -ni any port 3400 or port 3410

Jeśli nic nie dociera, problem zazwyczaj leży przed zaporą: router dostawcy, NAT, zapora, błędny publiczny IP, FQDN lub blokada portu.

RED ciągle się restartuje

Pętla restartu może mieć kilka przyczyn:

• niestabilne zasilanie
• uszkodzony zasilacz
• brak adresu IP przez DHCP
• błędna statyczna konfiguracja IP
• zablokowane porty
• przestarzały pakiet oprogramowania układowego RED
• błędny kod odblokowujący
• uszkodzona lub błędna konfiguracja RED

Najpierw sprawdź zasilanie, kable i DHCP, a następnie pakiet oprogramowania układowego RED, osiągalność portów oraz konfigurację. Factory Reset należy rozważyć dopiero wtedy, gdy wcześniejsze kontrole nie wskażą przyczyny. Przedtem trzeba zabezpieczyć ID RED, kod odblokowujący i konfigurację interfejsu. Jeśli tych danych brakuje, ponowna autoryzacja może wymagać pomocy Sophos Support.

Tunel jest zielony, ale ruch nie płynie

Ten przypadek jest szczególnie częsty. RED jest połączony, ale klienci nie osiągają systemów wewnętrznych ani Internetu.

Możliwe przyczyny:

• Brak zasady zapory lub jest zbyt nisko.
• Interfejs RED znajduje się w niewłaściwej strefie.
• DHCP przydziela błędną bramę lub serwery DNS.
• Brak routingu zwrotnego do sieci RED.
• NAT nieoczekiwanie tłumaczy ruch.
• Tagowanie VLAN nie pasuje.
• Funkcja bezpieczeństwa blokuje ruch.

Kolejność sprawdzania:

1. Sprawdź IP klienta, bramę i DNS.
2. Filtruj Log Viewer według IP źródłowego klienta RED.
3. Sprawdź dopasowanie zasady zapory.
4. Wykonaj Packet Capture na interfejsie RED i interfejsie docelowym.
5. Sprawdź drogę powrotną z systemu docelowego lub sieci docelowej.
6. Kontroluj NAT i routing.

W przypadku niejasnych dopasowań zasad pomocne jest Testowanie zasady zapory za pomocą Log Viewer, Policy Test i Packet Capture.

Jeśli awaria wystąpi bezpośrednio po resecie i ponownym provisioningu, należy dodatkowo uwzględnić NC-181808. Według informacji o wydaniu SFOS 22.0 MR3 Build 576 z 16 października 2026 r. naprawia blokadę ruchu spowodowaną pozostałymi wpisami RED_DEVICE_DROP. Nie wyjaśnia to każdego przypadku zielonego tunelu bez ruchu użytkowego. Należy zabezpieczyć czas resetu i provisioningu, build SFOS oraz logi RED i pakietów odpowiadające testowi, a przy pasujących objawach skonsultować je z Sophos Support. Nie usuwać samodzielnie wpisów wewnętrznych ani nie powtarzać resetów; po kontrolowanej korekcie ponownie przetestować tę samą ścieżkę w obu kierunkach.

Zielone diody LED nie wykluczają blokady ścieżki danych UDP. W takim przypadku sprawdź konkretnie ruch tunelu w 5. Device Management > 3. Advanced Shell:

tcpdump -ni any port 3410

Podczas kontrolowanego testu klienta użyj dodatkowo Diagnostics > Packet capture i ustal, czy operator lub urządzenie pośredniczące blokuje UDP 3410. Widoczny pakiet w jednym kierunku nie potwierdza jeszcze działania ścieżki w obu kierunkach; sam brak pakietów nie wskazuje miejsca blokady.

Ruch VLAN nie działa

W SD-RED 60 możliwe są scenariusze VLAN, ale tryb portu, ID VLAN i tryb RED muszą pasować do siebie.

Pomoc Sophos dotycząca rozwiązywania problemów w SFOS 22 i 23 wyraźnie ogranicza ruch VLAN do standard/unified. Ponadto sieci VLAN muszą być utworzone również na urządzeniu RED, a tryby portów LAN urządzenia RED muszą być odpowiednio ustawione. Dlatego nie sprawdzaj przypisania VLAN wyłącznie na zaporze lub przełączniku. Nie wnioskuj o możliwościach VLAN innych trybów pracy na podstawie pomyślnego testu untagged; sprawdź konkretny tryb pracy i projekt portów na podstawie trybów pracy RED.

Sprawdź:

• ID VLAN pasują na zaporze, RED i przełączniku.
• Port RED jest odpowiednio skonfigurowany jako Access, Hybrid lub Tagged Trunk.
• Port przełącznika w zdalnej lokalizacji jest poprawnie tagged lub untagged.
• DHCP i DNS są zaplanowane dla każdego VLAN.
• Zasady zapory istnieją dla odpowiednich sieci VLAN.
• Wybrany tryb RED obsługuje pożądany scenariusz VLAN.

Dla rozwiązywania problemów pomocna jest prosta nieoznaczona sieć testowa. Jeśli działa, przyczyna zazwyczaj leży w ID VLAN, tagowaniu, trybie portu lub konfiguracji przełącznika.

Punkty dostępowe RED pozostają nieaktywne

Jeśli punkty dostępowe RED lub funkcje Wi-Fi w scenariuszach VLAN pozostają nieaktywne, może być istotna opcja DHCP 234. Dotyczy to zwłaszcza przypadków, w których komunikacja RED lub punktu dostępowego odbywa się przez interfejsy VLAN. Sophos wymienia SD-RED 20 i SD-RED 60 dla tego scenariusza punktu dostępowego.

Ustaw tę opcję tylko wtedy, gdy pasuje do scenariusza i znany jest adres IP interfejsu zapory, z którym mają łączyć się urządzenia. Prawidłowy wybór trybu pracy Sophos RED wyjaśnia pełne powiązanie strefy Wi-Fi, sieci VLAN i opcji DHCP 234. Opcja 234 nie jest pierwszym krokiem przy ogólnych problemach z połączeniem RED.

Dla tego konkretnego błędu VLAN Sophos opisuje również opóźnione przywrócenie działania: Po 30 ponowieniach RED może otrzymać adres IP sieci LAN z serwera DHCP i ponownie pojawić się jako Active. Nie jest to dowód, że oczekiwana ścieżka VLAN działa. Dlatego nie czekaj jedynie na Active, lecz sprawdź adres IP na interfejsie VLAN i zapisaną opcję 234.

Rozwiązanie w SFOS 23: Poniższe kroki dotyczą punktów dostępowych RED skonfigurowanych w sieci VLAN, które po ponownym uruchomieniu mają stan Inactive, a w ich sieci VLAN brakuje opcji DHCP 234:

1. Otwórz Network > DHCP i edytuj serwer DHCP skonfigurowany dla sieci VLAN punktu dostępowego RED.
2. W DHCP options najpierw wyszukać kod 234 i udokumentować dotychczasową wartość lub brak opcji. Nie nadpisywać bez sprawdzenia istniejącej działającej opcji ani nie tworzyć drugiej konkurencyjnej opcji. Jeśli wartość istnieje, najpierw ustalić przypisanie VLAN-u i interfejsu; poniższe kroki dodawania dotyczą wyłącznie sytuacji, gdy brakuje opcji.
3. W sekcji DHCP options ustaw Options na Custom i wpisz 234 w polu Code.
4. W polu Value wpisz adres IP skonfigurowany dla interfejsu punktu dostępowego RED połączonego z tą siecią VLAN. Wartość ta zależy od konfiguracji interfejsów w danym środowisku; nie jest to IP przydzielone urządzeniu lub klientowi ani dowolny publiczny adres zapory.
5. Zapisz zmiany.

Następnie sprawdź zapisaną opcję na serwerze DHCP, w tym kod i adres IP interfejsu. Punkt dostępowy RED powinien w krótkim czasie otrzymać adres IP na swoim interfejsie VLAN. Sprawdź przydzielenie adresu, a następnie ponownie sprawdź stan punktu dostępowego RED. Jeśli nadal ma stan Inactive, najpierw sprawdź zgodność serwera DHCP, sieci VLAN i adresu IP interfejsu.

Rozwiązanie w SFOS 22: Instrukcja Sophos dla tej wersji używa w przypadku tego samego błędu VLAN konsoli Device Console zamiast opisanego powyżej wprowadzania danych w WebAdmin. W CLI wybrać 4. Device Console i przed każdą zmianą sprawdzić powiązania właściwego serwera DHCP VLAN w trybie tylko do odczytu:

system dhcp dhcp-options binding show dhcpname <dhcp server name>

Zastąpić <dhcp server name> nazwą serwera DHCP w VLAN-ie punktu dostępowego RED. Udokumentować istniejące powiązanie opcji 234 wraz z wartością lub jego brak. Nie nadpisywać bez sprawdzenia działającego powiązania ani nie dodawać konkurencyjnego powiązania. Jeśli wartość istnieje, najpierw ustalić przypisanie VLAN-u i interfejsu. Przed utworzeniem nowego powiązania ustalić także udokumentowaną procedurę administracyjną zmiany lub usuwania powiązań opcji DHCP dla zainstalowanej wersji. Jeśli ta procedura wycofania jest niejasna, nie wprowadzać zmian, lecz skorzystać z Sophos Support. Dodać powiązanie w sposób ukierunkowany tylko wtedy, gdy brakuje opcji:

system dhcp dhcp-options binding add dhcpname <dhcp server name> optionname dhcp_magic_ip(234) value <interface ip address>

Zastąpić <dhcp server name> jak powyżej, a <interface ip address> skonfigurowanym adresem IP interfejsu punktu dostępowego RED połączonego z VLAN-em. Nie używać adresu IP klienta. Po zmianie ponownie wykonać to samo polecenie tylko do odczytu system dhcp dhcp-options binding show dhcpname <dhcp server name> i sprawdzić zapisane powiązanie wraz z wartością. Następnie sprawdzić adres IP na interfejsie VLAN i stan. Nie stosować równolegle bez kontroli powiązania przez CLI w SFOS 22 i procedury WebAdmin w SFOS 23; wybrać wariant odpowiedni dla zainstalowanej wersji i zweryfikować zapisaną opcję.

Wycofanie dla obu wariantów: Jeśli rozwiązanie pozostaje nieskuteczne lub pogarsza się przydzielanie adresów VLAN albo stan, przywrócić udokumentowany stan początkowy. W SFOS 23 na tym samym serwerze DHCP w Network > DHCP > DHCP options przywrócić poprzednią wartość lub usunąć wyłącznie nowo dodaną opcję 234 i zapisać. W SFOS 22 użyć w tym celu wcześniej ustalonej procedury administracyjnej dotyczącej powiązań opcji DHCP, udokumentowanej dla zainstalowanej wersji: przywrócić zapisane powiązanie lub usunąć wyłącznie nowo utworzone powiązanie. Nie usuwać żadnej innej opcji ani żadnego serwera DHCP; nie wypróbowywać niepotwierdzonej składni usuwania. Następnie ponownie sprawdzić zapisane opcje lub powiązania, adres IP na interfejsie VLAN i stan punktu dostępowego RED.

Offline Provisioning jest nadpisywane

Jeśli RED najpierw został skonfigurowany online, a później offline za pomocą USB, stara konfiguracja online może pozostać na serwerze Sophos Provisioning. Jeśli RED nie osiąga zapory, może ponownie skonfigurować się online i nadpisać konfigurację USB.

Wtedy RED musi być ponownie skonfigurowany offline. Dodatkowo stara konfiguracja online powinna być usunięta przez wsparcie Sophos.

Diagnostyka i kontrola operacyjna

Punkty diagnostyczne na zaporze Sophos

Dla problemów z RED pomocne są te miejsca:

• Network > Interfaces dla interfejsu RED i statusu
• Administration > Device access dla odblokowań usługi RED
• Rules and policies > Firewall rules dla ruchu z sieci RED
• Diagnostics > Packet capture dla sprawdzania ścieżki
• Log viewer z wydarzeniami RED, zapory i systemu
• Backup & firmware > Pattern updates dla pakietu oprogramowania układowego RED
• Advanced Shell z tcpdump

Udane zestawienie połączenia można również potwierdzić w logach właściwych dla urządzenia. W /log/red.log pojawia się komunikat taki jak New connection from ... with ID <RED ID>. W /log/red-<RED ID>.log występują następnie connected OK, pushing config, a po ponownym połączeniu is now re-connected. Te wpisy potwierdzają połączenie i przekazanie konfiguracji, ale jeszcze nie działający ruch produkcyjny. Pełny log urządzenia może zawierać dane provisioningu i konfiguracji, dlatego przed udostępnieniem trzeba go oczyścić.

Dla plików dziennika i przypisania usług pasuje Rozwiązywanie problemów z Sophos Firewall: Usługi i dzienniki.

Jeżeli natomiast cały firewall uruchamia się w trybie Failsafe z komunikatem Failed to start Red server service, nie jest to zwykły błąd tunelu RED. Runbook trybu Failsafe wyjaśnia rozróżnienie Buildów oraz zabezpieczenie materiału dowodowego przed recovery.

Lista kontrolna operacji

Przed wdrożeniem:

• ID RED i kod odblokowujący udokumentowane.
• Publiczny adres zapory lub FQDN sprawdzony.
• TCP 3400, UDP 3410 i NTP 123 sprawdzone.
• Usługa RED i Device Access na zaporze zaplanowane.
• Strefa, DHCP, routing i zasady zapory zdefiniowane.
• Tryb VLAN w razie potrzeby przetestowany wcześniej.

Po podłączeniu:

• LED-y pokazują pomyślne utworzenie tunelu.
• Interfejs RED jest aktywny.
• Klient otrzymuje IP, bramę i DNS.
• Log Viewer pokazuje oczekiwaną zasadę zapory.
• Systemy docelowe wewnętrzne i ścieżka internetowa działają zgodnie z planem.
• Pakiet oprogramowania układowego jest aktualny.

W trakcie działania:

• Regularnie sprawdzaj pakiet oprogramowania układowego RED.
• Testuj połączenia lokalizacyjne po aktualizacjach zapory.
• Testuj tunele RED między zaporami oddzielnie od fizycznych lokalizacji SD-RED.
• Sprawdź wpływ poprawionej maski /32 na hosty systemowe RED po aktualizacji do SFOS 21.0 MR2 lub 21.5 MR1.
• Porównaj przepustowość RED z lokalną wartością odniesienia, jednym i czterema strumieniami iPerf3 oraz w obu kierunkach.
• Utrzymuj 802.3az lub EEE wyłączone na bezpośrednio podłączonych portach switcha i sprawdzaj je ponownie po wymianie switcha.
• Zmieniaj Tunnel compression i MTU tylko z udokumentowanym testem przed zmianą i po niej.
• Uwzględnij lokalizacje RED w monitoringu, kopii zapasowej i planowaniu awaryjnym.

FAQ