Konfiguracja Site-to-Site RED między dwiema Sophos Firewall

Tunel Site-to-Site RED łączy bezpośrednio dwie Sophos Firewall bez urządzenia SD-RED w którejkolwiek lokalizacji. Jedna zapora działa jako Firewall RED server i przyjmuje połączenie. Druga działa jako Firewall RED client i zestawia tunel do serwera.

Tego aktualnego procesu w SFOS 22 nie należy mylić z trybem pracy RED, takim jak Standard/Unified lub Standard/Split. Tryby te dotyczą fizycznego urządzenia SD-RED. W architekturze firewall-to-firewall na obu zaporach konfiguruje się natomiast interfejsy RED, trasy statyczne i odpowiednie reguły firewall.

⚠️ Przed zmianą potrzebne są aktualne kopie zapasowe obu zapór, niezależny dostęp administracyjny i udokumentowana droga odzyskiwania. W miarę możliwości publicznego adresu Firewall RED server nie należy tłumaczyć przez NAT, ponieważ translacja może zakłócać przychodzące połączenia RED.

Proces w ośmiu krokach

1. Zaplanować role, adresy RED, sieci lokalizacji i osiągalny adres serwera.
2. Włączyć RED provisioning service na obu zaporach i zezwolić na ścieżkę sterującą RED.
3. W centrali utworzyć interfejs Firewall RED server.
4. Bezpiecznie przekazać wygenerowany plik provisioningu do drugiej lokalizacji.
5. W oddziale utworzyć interfejs Firewall RED client i zaimportować plik.
6. Po obu stronach dodać trasę statyczną do zdalnej sieci LAN, używając adresu RED peera jako gateway i nie wybierając interfejsu.
7. Zezwolić na ruch użytkowy na obu zaporach za pomocą wąskich, logowanych reguł; nie tworzyć powiązanej reguły NAT.
8. Oddzielnie sprawdzić tunel, trasę, dopasowanie reguły i rzeczywisty ruch dwukierunkowy.

Zielony interfejs RED potwierdza jedynie zestawienie tunelu. Nie dowodzi, że routing, reguły firewall i droga powrotna działają.

Planowanie i projekt

Kiedy Site-to-Site RED jest odpowiedni

Site-to-Site RED to prosty sposób połączenia dwóch Sophos Firewall. Provisioning RED przejmuje część klasycznej negocjacji VPN, natomiast zdalne sieci LAN nadal korzystają ze zwykłego routingu i reguł firewall.

W nowych projektach nadal trzeba świadomie wybrać między RED a Site-to-Site IPsec. IPsec oferuje więcej opcji profili, routingu, interoperacyjności i redundancji. Site-to-Site RED jest atrakcyjny, gdy oba końce to Sophos Firewall i wystarcza prosty tunel specyficzny dla Sophos.

Fizyczne urządzenie SD-RED konfiguruje się zgodnie z instrukcją Konfiguracja i rozwiązywanie problemów Sophos SD-RED. Tryby pracy RED nie dotyczą opisanego tutaj tunelu firewall-to-firewall.

Planowanie przykładowej topologii

Poniższy przykład celowo używa adresów dokumentacyjnych. Wszystkie należy zastąpić rzeczywistymi sieciami i adresami obu lokalizacji:

• Centrala, rola Firewall RED server: adres publiczny 198.51.100.10, LAN 10.10.0.0/16
• Oddział, rola Firewall RED client: adres publiczny 203.0.113.20, LAN 10.20.0.0/16
• Adres RED centrali: 10.255.100.1
• Adres RED oddziału: 10.255.100.2

Dwa adresy RED tworzą parę adresów między zaporami. Nie mogą kolidować z siecią LAN lokalizacji ani inną siecią interfejsu lub VPN. Zapora klienta musi niezawodnie osiągać publiczny adres IP lub FQDN serwera.

Przykład używa 255.255.255.252 (/30) jako RED netmask. Ta mała sieć tranzytowa zawiera dokładnie potrzebną parę. Przy wyborze innej wolnej sieci trzeba spójnie zmienić oba adresy RED i maskę. RED nie rozwiązuje nakładających się sieci LAN; adresację lub NAT należy zaplanować przed tunelem.

Sophos wyraźnie opisuje interfejsy RED jako bezpieczne, szyfrowane tunele. Podczas rejestracji RED provisioning service SFOS wykorzystuje dane rejestracyjne do wygenerowania certyfikatu dla bezpiecznej komunikacji RED. Dlatego w udokumentowanym procesie firewall-to-firewall nie wybiera się ręcznie PSK ani certyfikatu w interfejsie: serwer generuje Provisioning file z danymi konfiguracji klienta. Plik należy przekazać wyłącznie chronionym kanałem.

Konfiguracja tunelu i ścieżki danych

Tworzenie Firewall RED server

Najpierw serwer tworzy się na zaporze ze stabilnie osiągalnym adresem publicznym:

1. W System services > RED włączyć RED provisioning service.
2. Otworzyć Network > Interfaces.
3. Wybrać Add interface > Add RED.
4. W Branch name wpisać na przykład RED-HQ-Branch.
5. Ustawić Type na Firewall RED server.
6. Pozostawić Tunnel ID jako Automatic.
7. Wpisać 10.255.100.1 jako RED IP.
8. Wpisać 255.255.255.252 jako RED netmask.
9. Przypisać wybraną strefę, w przykładzie RED-S2S.
10. Początkowo nie zmieniać Tunnel compression ani MTU i zapisać.
11. W Network > Interfaces wybrać z menu Download provisioning file.

Plik provisioningu należy do tego tunelu i trzeba traktować go jako wrażliwy element konfiguracji. Jest przesyłany do oddziału chronionym kanałem i po imporcie nie pozostaje w ogólnodostępnym folderze pobierania ani udostępnionym katalogu.

Strefa wpływa później na dopasowania reguł i Device Access. Można użyć LAN, ale przy wielu lokalizacjach dedykowana strefa zwykle tworzy wyraźniejszą granicę bezpieczeństwa. Konfiguracja stref i interfejsów na Sophos Firewall wyjaśnia ogólne zależności.

Automatic zapobiega przypadkowemu ponownemu użyciu Tunnel ID. Jeśli wartość musi być ręczna, według Sophos nie może być używana na żadnym urządzeniu. W udokumentowanym procesie klienta nie wpisuje się drugiego Tunnel ID; powiązanie pochodzi z pliku provisioningu serwera. Tunnel compression może poprawić przepustowość wolnego łącza, ale zużywa zasoby; zmienia się ją dopiero po powtarzalnym pomiarze przed i po. MTU interfejsu RED wpływa na fragmentację; problem z MTU lub fragmentacją może więc blokować przepływy z większymi pakietami, mimo że tunel jest aktywny. Mniejszą MTU testuje się tylko przy potwierdzonej fragmentacji lub problemie Path MTU.

Tworzenie Firewall RED client

W drugiej lokalizacji klient jest tworzony przy użyciu pliku wygenerowanego przez serwer:

1. Także tutaj w System services > RED włączyć RED provisioning service.
2. Utworzyć nowy interfejs w Network > Interfaces > Add interface > Add RED.
3. Użyć Branch name, na przykład RED-Branch-HQ.
4. Ustawić Type na Firewall RED client.
5. W Firewall IP/hostname wpisać publiczny adres lub FQDN serwera.
6. W Provisioning file wybrać plik z zapory serwera.
7. Wpisać 10.255.100.2 jako RED IP.
8. Wpisać tę samą RED netmask 255.255.255.252.
9. Przypisać RED-S2S, pozostawić Tunnel compression i MTU bez zmian i zapisać.

Jeżeli klient może osiągnąć serwer tylko przez przetłumaczony lub zmienny adres, trzeba szczególnie starannie przetestować DNS, NAT przed serwerem i drogę powrotną. Sophos zaleca, aby w miarę możliwości serwer był bezpośrednio osiągalny bez NAT.

Klient inicjuje połączenie wychodzące, więc oddział nie potrzebuje równoważnej publikacji przychodzącej.

Dodawanie tras statycznych bez interfejsu

Po zestawieniu tunel nie zna automatycznie sieci LAN za zaporami. Po obu stronach tworzy się trasę unicast IPv4:

• Centrala: cel 10.20.0.0/16, gateway 10.255.100.2
• Oddział: cel 10.10.0.0/16, gateway 10.255.100.1

Kluczowy wyjątek RED polega na tym, że dla tych dwóch tras nie wybiera się żadnego interfejsu. Zapora wysyła żądania ARP, aby określić osiągalny interfejs RED dla adresu peera. Późniejsze wybranie interfejsu może zakłócić ten mechanizm i nie jest ulepszeniem.

Trasę tworzy się w Routing > Static routes > IPv4 unicast route > Add. Administrative Distance i Metric dobiera się świadomie do pozostałej architektury routingu. Konfiguracja i test trasy statycznej na Sophos Firewall wyjaśnia ogólną logikę pól i sprawdzenie za pomocą Route Lookup.

Ograniczanie usługi RED i reguł firewall

Najpierw lokalna usługa RED musi przyjąć połączenie. W Administration > Device access włączyć RED tylko dla rzeczywistej strefy wejściowej. Przy stabilnych adresach publicznych utworzyć zamiast tego w Local service ACL exception rule > Add wąską regułę Accept z Source zone, Source Network / Host, interfejsem WAN jako Destination host i Services: RED. Zwykłe reguły firewall nie kontrolują usług lokalnych. Device Access i Local Service ACL wyjaśnia to rozdzielenie.

Następnie w Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule przepływ z centrali wymaga: centrala źródło LAN/10.10.0.0/16, cel RED-S2S/10.20.0.0/16; oddział źródło RED-S2S/10.10.0.0/16, cel LAN/10.20.0.0/16. Services ograniczyć do potrzebnych.

Dla ruchu inicjowanego z oddziału dodać odwrotną parę. Włączyć Log firewall traffic, sprawdzić pozycję i wyłączyć Create linked NAT rule. Zachować prawdziwe adresy i pełne trasy powrotne; nie nadpisywać celowego wyjątku NAT bez przeglądu. Zrozumienie i konfiguracja reguł Sophos Firewall opisuje szczegóły.

Weryfikacja, troubleshooting i rollback

Kontrolowana weryfikacja tunelu

Weryfikacja zaczyna się od pojedynczego przepływu testowego z zapisanym dokładnym czasem. Najpierw sprawdza się, czy oba interfejsy RED są aktywne i czy Route Lookup dla adresu w zdalnej sieci LAN pokazuje oczekiwaną trasę. Następnie przepływ musi trafić na przewidzianą Rule ID na obu zaporach.

Packet Capture na Sophos Firewall pokazuje, czy pakiet wchodzi do interfejsu RED po stronie źródłowej, dociera do peera i jest przekazywany do docelowej sieci LAN. Drogę powrotną testuje się osobno. Sam ping nie wystarcza, jeśli aplikacja produkcyjna używa TCP lub UDP na innych portach.

Sukces oznacza więc jednoczesne spełnienie wszystkich punktów:

• Interfejsy RED są aktywne po obu stronach.
• Route Lookup pokazuje zaplanowaną trasę w obu kierunkach.
• Oczekiwana reguła firewall jest dopasowana na obu zaporach.
• Rzeczywisty przepływ aplikacji działa dwukierunkowo.
• Adresy źródłowe i docelowe są widoczne bez niezamierzonego NAT.
• Po kontrolowanym restarcie nowy przepływ działa ponownie; klaster HA wymaga osobnego testu failover.

Sophos dokumentuje dla HA opóźnienie ponownego łączenia tuneli RED z Auxiliary Firewall po failoverze. Zależy ono od liczby interfejsów i innych ustawień i dotyczy też Site-to-Site RED. Nie należy obiecywać natychmiastowego powrotu: zapisać czas, stan interfejsu i czas ponownego połączenia, po czym powtórzyć test aplikacji.

Systematyczne zawężanie błędów

Klient nie zestawia tunelu: Sprawdzić RED provisioning service, adres serwera, DNS, osiągalność, Device Access i plik provisioningu należący do tunelu. Nie łączyć bez sprawdzenia nowego pliku ze starą konfiguracją klienta.

Plik provisioningu jest odrzucany: sprawdzić, czy pochodzi z aktualnego interfejsu serwera i nie został zmieniony. Najpierw zachować stan początkowy; potem ewentualnie pobrać nowy plik i odtworzyć klienta w oknie serwisowym.

Tunel jest aktywny, ale zdalna sieć LAN jest nieosiągalna: Po obu stronach sprawdzić sieć docelową i adres RED peera w trasie statycznej. Dla tej specjalnej trasy RED nie może być wybrany interfejs. Następnie sprawdzić dopasowanie reguły i trasę powrotną.

Działa tylko jeden kierunek: Zwykle na jednej zaporze brakuje właściwej reguły lub trasy albo sieć lokalizacji jest już osiągana bardziej szczegółową trasą lub trasą o wyższym priorytecie. Route Lookup, Packet Capture i rzeczywisty ruch powrotny muszą być spójne.

Połączenie jest niestabilne: Skorelować opóźnienie, utratę pakietów, publiczną osiągalność serwera, NAT przed serwerem i zmiany ścieżki WAN. Zachować lokalne dla węzła logi z dokładnego czasu testu. Wyszukiwanie i analiza logów usług Sophos Firewall wyjaśnia pliki logów i ścieżki wsparcia.

Tunel jest aktywny, ale przepływy z większymi pakietami stają: w Packet Capture sprawdzić oba kierunki pod kątem fragmentacji i komunikatów ICMP Path MTU. Porównać wartości MTU obu interfejsów RED i przetestować różne rozmiary pakietów. Dopiero na podstawie tych danych stopniowo testować tę samą MTU po obu stronach. Nie zmieniać jednocześnie compression i MTU.

Szeroka reguła Any, ogólne zezwolenie WAN, restart usługi ani przypadkowe zmiany adresów RED i tras nie zastępują tej korelacji. Jeśli mimo poprawnej architektury błąd pozostaje niejasny, dla Sophos Support zbiera się kopię zapasową, build SFOS, znacznik czasu, stan interfejsów, trasy, Rule IDs, Packet Capture i odpowiednie logi.

Bezpieczne wycofanie zmian

Jeśli pilotaż się nie powiedzie, najpierw wyłączyć reguły i usunąć trasy, potem interfejs klienta i na końcu serwera. Przywrócić Device Access/Local Service ACL oraz MTU lub compression; nowe obiekty usunąć tylko, gdy nie są używane gdzie indziej.

Istniejąca droga administracyjna korzystająca właśnie z tego tunelu nie jest usuwana, dopóki alternatywny dostęp nie zostanie pomyślnie przetestowany. Po wycofaniu zmian ponownie sprawdza się normalny routing, wcześniejsze reguły i osiągalność obu zapór.

FAQ