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.
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ł, a usługę RED udostępnić tylko z wymaganych stref.
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ą.

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.

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. Przypisać świadomie wybraną strefę i zapisać interfejs.
9. Z menu nowego interfejsu RED pobrać plik provisioningu.

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.

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. Przypisać zaplanowaną strefę i zapisać interfejs.

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.

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 reguł firewall i usługi RED

Przekazywany ruch wymaga odpowiedniej reguły na obu zaporach. Szeroka reguła LAN-to-LAN jest prostym przykładem funkcjonalnym, ale w produkcji sieć źródłową, sieć docelową i usługi ogranicza się do rzeczywistej potrzeby. Logowanie pozostaje włączone podczas testów.

W tym przykładzie zapora centralna potrzebuje reguły z sieci LAN 10.10.0.0/16 do sieci oddziału 10.20.0.0/16. W oddziale odpowiednio odwzorowuje się wymagany ruch powrotny lub ruch w przeciwnym kierunku. NAT zwykle nie jest potrzebny w routowanym połączeniu lokalizacji; obie strony powinny widzieć prawdziwe adresy źródłowe i mieć pełną drogę powrotną. Zrozumienie i konfiguracja reguł Sophos Firewall szczegółowo opisuje mechanizm reguł.

Usługa RED musi być również osiągalna ze stref, z których przychodzi połączenie RED. W Administration > Device access można włączyć RED dla strefy. Jeśli znane są stabilne adresy źródłowe, wąska Local service ACL exception rule jest lepsza niż szerokie zezwolenie dla całej strefy WAN. Wyjątek dotyczy tylko kanału sterującego RED i nie zastępuje reguły firewall dla ruchu między lokalizacjami. Szczegóły opisuje Device Access i Local Service ACL.

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 lub failoverze nowy przepływ ponownie zestawia się poprawnie.

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.

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.

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żeli pilotaż nie powiedzie się lub projekt zostanie odrzucony, najpierw wyłącza się dodatkowe reguły firewall i usuwa obie trasy statyczne. Następnie można kontrolowanie usunąć interfejs RED klienta, a na końcu interfejs RED serwera. Tymczasowe zezwolenia Device Access lub Local Service ACL przywraca się do udokumentowanego stanu początkowego.

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