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.

Klasyfikacja: SD-RED, tunel RED i SFOS 22

W nowych projektach należy wyraźnie rozróżniać między aktualnymi lokalizacjami SD-RED a starymi konfiguracjami site-to-site RED. Konfiguracje serwera/klienta RED w wersji Legacy nie są obsługiwane w SFOS 22.0 i nowszych. Takie starsze konfiguracje powinny być sprawdzone i migrowane przed aktualizacją.

Dla aktualnych urządzeń SD-RED, RED pozostaje istotnym tematem lokalizacyjnym. W SFOS 21.5 udokumentowano również większą skalowalność dla SD-RED i tuneli site-to-site RED. Dla administratorów oznacza to, że nowe lokalizacje powinny być starannie planowane z aktualną logiką SD-RED, podczas gdy stare tunele Legacy-RED muszą być świadomie sprawdzane przed aktualizacjami do SFOS 22.

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.

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

Legacy site-to-site RED przed SFOS 22

Przed aktualizacją do SFOS 22 lub nowszej należy sprawdzić, czy są jeszcze obecne konfiguracje serwera/klienta RED w wersji Legacy. Te konfiguracje site-to-site RED w wersji Legacy nie są obsługiwane w SFOS 22.0 i nowszych.

Praktycznie oznacza to:

• Inwentaryzacja konfiguracji RED i VPN przed aktualizacją.
• Identyfikacja konfiguracji serwera/klienta RED w wersji Legacy.
• Planowanie migracji na obsługiwane warianty RED site-to-site lub VPN.
• Po migracji sprawdzenie zasad zapory, stref, routingu i DHCP.
• Przeprowadzenie aktualizacji dopiero po przetestowaniu połączeń lokalizacyjnych.

Dla większego planowania aktualizacji pasuje dodatkowo Prawidłowe planowanie aktualizacji oprogramowania układowego 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

Rozwiązywanie problemów

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.

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.
• Usuń lub zmigruj Legacy site-to-site RED przed SFOS 22.
• Sprawdź wpływ /32 na hosty systemowe RED po SFOS 21.5 MR1.
• Uwzględnij lokalizacje RED w monitoringu, kopii zapasowej i planowaniu awaryjnym.

FAQ