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.

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.
• Wzorzec oprogramowania układowego RED 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ść.

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.

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

1. Na firewallu pod Administration > Time sprawdzić, czy firewall nadaje się jako serwer NTP dla scenariusza RED. Przy ręcznym setupie RED musi dostać prawidłowy czas, aby TLS handshake z firewallem działał.
2. Pod Network > Zones utworzyć osobną strefę dla lokalizacji RED albo użyć istniejącej strefy, takiej jak VPN lub WiFi. Strefy LAN należy dla RED unikać, aby reguły LAN nie obowiązywały niezamierzenie dla zdalnej lokalizacji.
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. Pobrać wygenerowany plik provisioningu z interfejsu RED.
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.

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.

Offline RED nadal potrzebuje prawidłowego czasu. Albo RED może osiągnąć serwery NTP Sophos, albo planuje się celowaną Local service ACL exception rule, aby RED mógł komunikować się ze strefy WAN do firewalla. Jako source powinno być użyte tylko znane IP RED, destination to port WAN firewalla, service w tym scenariuszu to HTTPS, action Accept. Ten wyjątek nie zastępuje szerokiego otwierania RED przez WAN.

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 LED-y migają razem, RED właśnie instaluje oprogramowanie układowe. W tej fazie nie należy wyłączać urządzenia ani odłączać go od Internetu. Aktualizacja może potrwać kilka minut.

Na zaporze Sophos należy dodatkowo sprawdzić:

Backup & firmware > Pattern updates

Tam wzorzec oprogramowania układowego RED musi być aktualny. Jeśli RED utknie w pętli lub po aktualizacji zapory nie uruchamia się poprawnie, przestarzały wzorzec oprogramowania układowego RED jest sensownym krokiem do sprawdzenia. Współdziałanie stanów, automatycznego pobierania i świadomej instalacji wyjaśnia artykuł Konfiguracja i sprawdzanie aktualizacji wzorców 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 potrzebuje czystej 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.

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.

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.

Hosty systemowe RED po SFOS 21.5 MR1

Od SFOS 21.5 MR1 hosty systemowe RED otrzymują poprawną maskę podsieci /32. Jeśli takie automatycznie generowane obiekty systemowe RED były wcześniej używane w zasadach lub innych konfiguracjach dla więcej niż jednego hosta IP, po aktualizacji ruch może być inaczej dopasowywany.

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ą.

Typowy przykład praktyczny to 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 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?

Dla provisioning RED musi osiągnąć usługę Sophos Provisioning Service. W wielu środowiskach red.astaro.com na TCP 3400 jest istotne.

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?

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 wzorzec oprogramowania układowego RED
• błędny kod odblokowujący
• uszkodzona lub błędna konfiguracja RED

Najpierw sprawdź zasilanie, kable i DHCP. Następnie kontroluj wzorzec oprogramowania układowego RED, dostępność portów i konfigurację. Jeśli RED zostanie ponownie skonfigurowany lub zresetowany, ID RED i kod odblokowujący muszą być wcześniej udokumentowane.

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.

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.

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.

Tę opcję należy ustawić tylko wtedy, gdy scenariusz jest odpowiedni i jest jasne, który IP interfejsu zapory urządzenia powinny osiągnąć. W przypadku ogólnych problemów z połączeniem RED opcja DHCP 234 nie jest pierwszym krokiem.

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.

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 wzorca oprogramowania układowego RED
• Advanced Shell z tcpdump

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.
• Wzorzec oprogramowania układowego jest aktualny.

W trakcie działania:

• Regularnie sprawdzaj wzorzec 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 /32 na hosty systemowe RED po SFOS 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