Konfiguracja i testowanie tunelu GRE na Sophos Firewall

Tunel GRE łączy dwa punkty końcowe IP i przenosi między nimi ruch routowany. Na Sophos Firewall tworzy się go w Device Console za pomocą system gre. Rozwiązanie pasuje na przykład do połączenia z usługą operatora, prostej ścieżki overlay lub transportu, który wyraźnie wymaga GRE.

Krótka odpowiedź

Aby bezpiecznie wdrożyć tunel, najpierw dokumentuje się zewnętrzne punkty końcowe WAN, wewnętrzne adresy tunelu i sieci zdalne. Następnie należy:

1. Sprawdzić osiągalność obu punktów WAN w warstwie underlay oraz protokół IP 47.
2. Utworzyć lustrzaną konfigurację tunelu GRE na obu zaporach za pomocą system gre tunnel add.
3. Sprawdzić nazwę, punkty końcowe, adresy tunelu i status poleceniem system gre tunnel show.
4. Przypisać sieci zdalne do tunelu za pomocą system gre route add.
5. Utworzyć precyzyjne, logowane reguły zapory między strefami LAN i VPN.
6. Oddzielnie przetestować GRE na ścieżce WAN, trasę wewnętrzną, Rule ID, ruch użytkowy i trasę powrotną.

⚠️ GRE sam w sobie nie zapewnia szyfrowania ani uwierzytelniania. W niezaufanej sieci GRE stosuje się tylko wtedy, gdy niezaszyfrowany transport został wyraźnie zaakceptowany w projekcie zabezpieczeń. Jeśli potrzebna jest poufność lub uwierzytelnianie drugiej strony, zwykle lepiej pasuje site-to-site IPsec VPN.

Rozróżnienie punktów końcowych GRE, adresów tunelu i tras

Konfiguracja GRE składa się z kilku warstw:

• Local gateway: lokalny interfejs WAN urządzenia Sophos Firewall, na przykład Port2.
• Remote gateway: zewnętrzny adres IPv4 drugiej strony.
• Local IP i Remote IP: wewnętrzne adresy point-to-point tunelu GRE.
• Trasa GRE: przypisuje zdalny host lub sieć docelową do tunelu.
• Reguła zapory: zezwala na konkretny przepływ danych między strefami i sieciami.
• Trasa powrotna: przesyła pakiety odpowiedzi z powrotem przez lustrzany tunel.

GRE przez IPv4 wykorzystuje protokół IP 47. Nie jest to ani TCP, ani UDP i nie należy go mylić z portem 47. Router nadrzędny, filtr operatora lub lista zabezpieczeń w chmurze musi więc przepuszczać ten protokół IP między dwoma zewnętrznymi punktami końcowymi.

Widoczny status tunelu Enabled potwierdza zapisanie i aktywowanie konfiguracji GRE. Nie dowodzi jednak, że druga strona odpowiada, trasa jest poprawna ani że działa aplikacja.

Kiedy GRE pasuje, a kiedy lepszy jest IPsec

GRE jest prosty i przenosi ruch routowany między dwoma zdefiniowanymi punktami końcowymi. Pasuje, gdy wymaga go operator lub platforma, potrzebna jest tylko enkapsulacja albo zaufana ścieżka underlay jest już zabezpieczona w inny sposób.

GRE nie zastępuje jednak szyfrowanego połączenia między lokalizacjami. Dla typowych połączeń przez publiczny Internet lepszym punktem wyjścia jest zwykle route-based IPsec. Połączenie GRE i IPsec wymaga odrębnego projektu przetestowanego na obu urządzeniach; ta procedura podstawowa nie tworzy niesprawdzonej ścieżki GRE-over-IPsec.

Artykuł opisuje statyczny tunel IPv4 point-to-point. Multicast, PIM-SM, BGP przez GRE i specyficzne dla operatorów tunele Anycast są możliwymi rozszerzeniami, ale planuje się je dopiero po uruchomieniu podstawowej ścieżki unicast.

Planowanie przykładowej topologii

Przykład łączy dwa urządzenia Sophos Firewall:

• Lokalizacja A WAN: Port2 z adresem 192.0.2.10
• Lokalizacja A LAN: 10.10.10.0/24
• Lokalizacja A, adres tunelu: 10.255.255.1
• Lokalizacja B WAN: Port2 z adresem 198.51.100.20
• Lokalizacja B LAN: 10.20.20.0/24
• Lokalizacja B, serwer testowy: 10.20.20.10
• Lokalizacja B, adres tunelu: 10.255.255.2
• Sieć tunelu: 10.255.255.0/30
• Usługa testowa: HTTPS, czyli TCP 443

192.0.2.0/24 i 198.51.100.0/24 to sieci dokumentacyjne, których nie używa się produkcyjnie. Oba adresy WAN, interfejsy, adresy tunelu, sieci LAN i serwer testowy należy wspólnie zastąpić rzeczywistymi wartościami. Adresy tunelu muszą tworzyć własną, identycznie zaplanowaną po obu stronach sieć point-to-point i nie mogą nakładać się na istniejące sieci.

W przykładzie użyto nazw tuneli gre_branch w lokalizacji A i gre_hq w lokalizacji B. Nazwy można wybrać dowolnie, ale według aktualnego API SFOS 22 mogą mieć maksymalnie 15 znaków.

Przed zmianą potrzebne są kopia zapasowa konfiguracji, okno serwisowe i niezależny dostęp administracyjny jako droga powrotu. Należy też zarejestrować istniejące Static Routes i SD-WAN Routes, reguły NAT, reguły zapory oraz nakładające się sieci.

Sprawdzenie wymagań ścieżki zewnętrznej

Oba punkty końcowe WAN muszą być wzajemnie osiągalne przez warstwę underlay. Podstawowa konfiguracja korzysta po obu stronach ze statycznych adresów IPv4. Jeśli lokalny adres WAN jest przydzielany przez PPPoE lub DHCP, nie należy kontynuować tej procedury: starsze oficjalne instrukcje Sophos dotyczące GRE wykluczają dynamiczne lokalne interfejsy WAN, natomiast aktualne API SFOS 22 dokumentuje DDNS wyłącznie dla Remote Gateway. Wsparcie trzeba więc wyjaśnić dla konkretnej kompilacji i łącza.

Przed skonfigurowaniem tunelu należy sprawdzić:

• Zdalny adres WAN jest routowany przez oczekiwaną bramę WAN.
• Routery nadrzędne, operatorzy i listy ACL w chmurze zezwalają na protokół IP 47 między oboma punktami końcowymi.
• Nie ma konfiguracji CGNAT lub NAT, której zachowanie wobec GRE jest nieznane.
• Wewnętrzne adresy tunelu i sieci LAN nie nakładają się lokalnie ani zdalnie.
• Druga strona używa tych samych zewnętrznych i wewnętrznych wartości w układzie lustrzanym.
• Zaplanowano trasę powrotną do obu sieci LAN.

Ping do publicznego adresu drugiej strony może potwierdzać działanie ścieżki underlay, ale nie dowodzi obsługi GRE. Nie pomaga też zezwolenie na port TCP lub UDP 47, ponieważ GRE nie jest protokołem transportowym opartym na portach.

Tworzenie tunelu GRE na obu zaporach

Konfigurację wykonuje się w CLI w menu 4. Device Console. Aktualna strona pomocy Sophos zawiera nieprawidłowo wyrenderowane fragmenty składni. Dlatego przed zmianą należy na używanej kompilacji sprawdzić za pomocą Tab lub ?, czy dostępne są poniższe parametry.

Konfiguracja lokalizacji A

Na zaporze A wpisuje się lokalny port WAN Port2, zewnętrzny adres drugiej strony 198.51.100.20 oraz wewnętrzną parę adresów tunelu:

system gre tunnel add name gre_branch local-gw Port2 remote-gw 198.51.100.20 local-ip 10.255.255.1 remote-ip 10.255.255.2

Następnie wykonywany jest tylko odczyt:

system gre tunnel show

Wpis musi poprawnie pokazywać gre_branch, Port2, zdalny adres WAN oraz oba adresy tunelu. Literówki nie należy ukrywać przez tworzenie drugiej konfiguracji o podobnej nazwie.

Lustrzana konfiguracja lokalizacji B

Na zaporze B wartości lokalne i zdalne są zamienione:

system gre tunnel add name gre_hq local-gw Port2 remote-gw 192.0.2.10 local-ip 10.255.255.2 remote-ip 10.255.255.1

Także tutaj następuje kontrola tylko do odczytu:

system gre tunnel show

Na tym etapie Enabled jest jedynie kontrolą pośrednią. Weryfikacja kończy się dopiero po potwierdzeniu rzeczywistego przepływu danych między sieciami LAN.

Routing sieci zdalnych przez GRE

Dla prostej stałej ścieżki na każdej zaporze tworzy się trasę GRE. Lokalizacja A wysyła sieć LAN lokalizacji B przez gre_branch:

system gre route add net 10.20.20.0/255.255.255.0 tunnelname gre_branch

Lokalizacja B otrzymuje lustrzaną trasę powrotną:

system gre route add net 10.10.10.0/255.255.255.0 tunnelname gre_hq

Następnie na obu urządzeniach odczytuje się skonfigurowane przypisania:

system gre route show

Trasa nie może konkurować z trasą statyczną, SD-WAN, VPN lub bezpośrednio połączoną o tej samej długości albo bardziej szczegółową. Globalnej Route Precedence nie zmienia się na próbę. Najpierw trzeba potwierdzić faktycznie dopasowaną trasę i ścieżkę pakietu.

Custom Gateway i SD-WAN jako alternatywa

W niektórych projektach operatorskich zamiast prostej trasy GRE stosuje się Custom Gateway na ścieżce GRE i wybiera ją w SD-WAN Route. Rozwiązanie pasuje, gdy Source, Service, Failover lub zdefiniowany status bramy mają wpływać na decyzję o routingu.

Next Hop jest wtedy zdalnym adresem tunelu. Health Check, Zone i Probe Target muszą odpowiadać konkretnemu projektowi operatora; monitoring wyłączony w instrukcji producenta nie jest uniwersalnym standardem. Zależność między obiektem, próbą i testem rzeczywistym wyjaśnia artykuł Tworzenie i sprawdzanie Custom Gateway na Sophos Firewall. Wybór ścieżki opisano w Konfiguracja SD-WAN Route na Sophos Firewall.

Trasy GRE i SD-WAN Route nie należy uruchamiać równolegle bez kontroli dla tych samych sieci. Przed przełączeniem dokumentuje się, który mechanizm ma wygrywać i jak wrócić do poprzedniej ścieżki.

Tworzenie reguł zapory bez zbędnego NAT

Tunel GRE i jego trasa nie zezwalają jeszcze na ruch użytkowy. Dla połączenia HTTPS inicjowanego z lokalizacji A potrzebna jest na obu zaporach precyzyjna, logowana reguła.

Na zaporze A:

• Source zone: LAN
• Source network: 10.10.10.0/24
• Destination zone: VPN
• Destination network: 10.20.20.10
• Services: HTTPS
• Action: Accept
• Log firewall traffic: włączone

Na zaporze B zezwala się na przychodzący ruch z tunelu do serwera testowego:

• Source zone: VPN
• Source network: 10.10.10.0/24
• Destination zone: LAN
• Destination network: 10.20.20.10
• Services: HTTPS
• Action: Accept
• Log firewall traffic: włączone

Te dwie reguły obejmują połączenie zainicjowane z lokalizacji A i jego stanowy ruch powrotny. Jeśli hosty w lokalizacji B mają samodzielnie inicjować nowe połączenia do lokalizacji A, należy dodatkowo utworzyć lustrzaną parę reguł LAN do VPN na zaporze B oraz VPN do LAN na zaporze A, z rzeczywiście potrzebnymi sieciami i usługami. Szeroka reguła Any nie jest potrzebna do testu odbiorczego.

W normalnym połączeniu lokalizacji oryginalny adres źródłowy pozostaje zachowany. MASQ nie włącza się jako pozornego rozwiązania problemu z routingiem. Jeśli brakuje trasy powrotnej, należy poprawić trasę po drugiej stronie. Ogólną konstrukcję reguł opisano w Tworzenie i bezpieczne sprawdzanie reguł Sophos Firewall.

Wspólny test tunelu i ruchu użytkowego

Kontrola przebiega zgodnie ze ścieżką pakietu i oddziela konfigurację od rzeczywistego działania:

1. Na obu zaporach wykonać system gre tunnel show i porównać punkty końcowe oraz adresy tunelu.

2. Za pomocą system gre route show sprawdzić odpowiednią zdalną sieć LAN i właściwą nazwę tunelu.

3. Z klienta w 10.10.10.0/24 uruchomić nowe połączenie HTTPS do 10.20.20.10.

4. W Log viewer na obu zaporach sprawdzić Source, Destination, Service, Firewall Rule ID, NAT Rule ID i Zone.

5. W Diagnostics > Packet capture w lokalizacji A ustawić filtr zewnętrznej ścieżki GRE:

   host 198.51.100.20 and ip proto 47
   

6. Oddzielnie ustawić filtr wewnętrznego przepływu testowego:

   host 10.20.20.10 and tcp port 443
   

7. Porównać wejście i wyjście na obu zaporach oraz sprawdzić rzeczywisty adres źródłowy na serwerze docelowym.

8. Test powrotny uruchomić tylko z usługą, która została do tego dozwolona.

Zewnętrzny capture pokazuje enkapsulację między punktami WAN. Wewnętrzny capture i Rule ID pokazują, czy pakiet użytkowy przechodzi przez oczekiwaną regułę i trasę. Dopiero działająca aplikacja potwierdza całą ścieżkę. Połączoną procedurę opisują dokładniej artykuły Testowanie reguł zapory i Korzystanie z Packet Capture.

Diagnostyka według objawu

Żaden pakiet GRE nie opuszcza interfejsu WAN

• Sprawdzić Remote Gateway i lokalne local-gw w tunelu.
• Sprawdzić trasę underlay do zdalnego adresu WAN oraz wybraną bramę WAN.
• Upewnić się, że przepływ testowy rzeczywiście pasuje do trasy GRE lub planowanej SD-WAN Route.
• Porównać nazwy i przypisanie za pomocą system gre tunnel show oraz system gre route show.
• Nie tworzyć zezwolenia na port TCP/UDP zamiast protokołu IP 47.

GRE opuszcza lokalizację A, ale nie dociera do lokalizacji B

• Sprawdzić operatora, routery nadrzędne, listy ACL w chmurze i możliwe odcinki NAT pod kątem protokołu IP 47.
• Jednocześnie wykonać capture w lokalizacji B z zewnętrznym filtrem WAN.
• Porównać zewnętrzny adres źródłowy i docelowy z konfiguracją drugiej strony.
• Przy dynamicznym WAN, CGNAT lub niejasnym NAT zatrzymać wdrożenie i nie maskować problemu szerokimi regułami.

GRE jest widoczny po obu stronach WAN, ale brakuje ruchu wewnętrznego

• Local IP i Remote IP muszą być na obu zaporach lustrzane.
• Porównać znak po znaku trasę GRE, sieć docelową i nazwę tunelu.
• Sprawdzić regułę zapory i oczekiwany Rule ID po obu stronach.
• Wykluczyć nakładające się sieci, NAT i brak trasy powrotnej.
• Nie traktować Enabled jako dowodu działania trasy wewnętrznej lub aplikacji.

Działa tylko jeden kierunek

• Sprawdzić w lokalizacji B trasę GRE dla sieci powrotnej.
• Sprawdzić, czy lokalizacja B ma inicjować nowe połączenia i potrzebuje do tego własnej reguły zapory.
• Na serwerze docelowym sprawdzić Default Gateway, lokalną zaporę hosta i rzeczywisty adres źródłowy.
• Porównać po obu stronach asymetryczne trasy SD-WAN lub statyczne.

Małe pakiety działają, a duże połączenia się zacinają

GRE dodaje zewnętrzny nagłówek IP i GRE. Zmniejsza to użyteczny rozmiar pakietu w porównaniu z warstwą underlay. Nie należy bez sprawdzenia przyjmować stałej wartości MTU lub MSS: najpierw mierzy się MTU underlay, Path MTU Discovery, fragmentację i działanie konkretnej aplikacji. Kontrolowaną procedurę opisano w Sprawdzanie MTU i MSS przy problemach z VPN.

Ostrożne testowanie HA i eksploatacji

Aktualna publiczna dokumentacja Sophos nie gwarantuje dla GRE bezprzerwowego HA failover ani synchronizacji stanu tunelu. Kontrolowaną zmianę ról przeprowadza się więc wyłącznie w oknie serwisowym i z niezależnym dostępem administracyjnym.

Po przełączeniu ponownie sprawdza się system gre tunnel show, system gre route show, zewnętrzny capture GRE, nowe połączenie klienta, Rule ID i trasę powrotną. Istniejące połączenie TCP nie jest dowodem ciągłości.

W eksploatacji dokumentuje się właściciela, oba punkty WAN, adresy i nazwy tuneli, sieci zdalne, mechanizm routingu, reguły zapory, oczekiwaną granicę MTU oraz ostatni test rzeczywisty. Po zmianach WAN, operatora, NAT, SD-WAN, Route Precedence lub drugiej strony cała ścieżka jest ponownie weryfikowana.

Bezpieczne wycofanie zmian

Wycofanie odbywa się w skoordynowany sposób na obu zaporach:

1. Zatrzymać ruch testowy i zapisać ostatni stan za pomocą system gre tunnel show oraz system gre route show.

2. Wyłączyć nowe reguły zapory i ewentualnie utworzoną SD-WAN Route.

3. Jeśli użyto Custom Gateway, usunąć ją ze ścieżki dopiero po sprawdzeniu Object usage.

4. W lokalizacji A usunąć konkretną trasę GRE:

   system gre route del net 10.20.20.0/255.255.255.0 tunnelname gre_branch
   

5. W lokalizacji B usunąć trasę powrotną:

   system gre route del net 10.10.10.0/255.255.255.0 tunnelname gre_hq
   

6. Za pomocą system gre route show sprawdzić, czy zniknęły tylko zamierzone wpisy.

7. Następnie w lokalizacji A usunąć tunel dokładnie według nazwy:

   system gre tunnel del name gre_branch
   

8. W lokalizacji B usunąć wyłącznie tamtejszy tunel:

   system gre tunnel del name gre_hq
   

9. Zakończyć poleceniem system gre tunnel show i testem poprzedniej ścieżki routingu.

Nie używa się del All. Jeśli składnia lub nazwa obiektu jest niejasna w używanej kompilacji, przed usunięciem sprawdza się ją za pomocą Tab lub ?, zamiast zgadywać.

Częste pytania