Konfigurera och testa en GRE-tunnel på Sophos Firewall

En GRE-tunnel ansluter två IP-slutpunkter och transporterar routad trafik mellan dem. På Sophos Firewall skapas den i Device Console med system gre. Det passar exempelvis för en anslutning till en leverantör, en enkel overlay-väg eller en transport som uttryckligen kräver GRE.

Kort svar

För en säker installation dokumenteras först de yttre WAN-slutpunkterna, de inre tunnel-IP-adresserna och fjärrnäten. Därefter följer dessa steg:

1. Kontrollera underlay-anslutningen mellan de båda WAN-slutpunkterna och IP-protokoll 47.
2. Skapa GRE-tunneln spegelvänt på båda brandväggarna med system gre tunnel add.
3. Kontrollera namn, slutpunkter, tunnel-IP-adresser och status med system gre tunnel show.
4. Tilldela fjärrnäten till tunneln med system gre route add.
5. Skapa snäva, loggade brandväggsregler mellan LAN och VPN.
6. Testa GRE på WAN-vägen, den inre rutten, Rule ID, nyttotrafiken och returvägen var för sig.

⚠️ GRE ger i sig ingen kryptering eller autentisering. Över ett ej betrott nät används GRE endast om okrypterad transport uttryckligen har accepterats i säkerhetsdesignen. Om sekretess eller peer-autentisering krävs passar vanligtvis en site-to-site IPsec VPN bättre.

Skilj mellan GRE-slutpunkter, tunnel-IP-adresser och rutter

En GRE-konfiguration består av flera lager:

• Local gateway: Sophos Firewalls lokala WAN-gränssnitt, exempelvis Port2.
• Remote gateway: motpartens yttre IPv4-adress.
• Local IP och Remote IP: GRE-tunnelns inre punkt-till-punkt-adresser.
• GRE-rutt: tilldelar en fjärrvärd eller ett fjärrnät till tunneln.
• Brandväggsregel: tillåter det konkreta dataflödet mellan zonerna och näten.
• Returväg: leder svarspaketen tillbaka genom den spegelvända tunneln.

GRE över IPv4 använder IP-protokoll 47. Det är varken TCP eller UDP och får inte förväxlas med port 47. En framförliggande router, ett leverantörsfilter eller en security list i molnet måste därför kunna transportera IP-protokollet mellan de två yttre slutpunkterna.

En synlig tunnelstatus Enabled bekräftar att GRE-konfigurationen har sparats och aktiverats. Den visar ännu inte att motparten svarar, att rutten är korrekt eller att en applikation fungerar.

När GRE passar och när IPsec är lämpligare

GRE är enkelt och transporterar routad trafik mellan två definierade slutpunkter. Det passar när en leverantör eller plattform kräver GRE, när endast inkapsling behövs eller när en betrodd underlay-väg redan är separat skyddad.

GRE ersätter däremot inte en krypterad förbindelse mellan platser. För vanliga anslutningar över det publika internet är route-based IPsec oftast en lämpligare utgångspunkt. En kombination av GRE och IPsec kräver en egen design som har testats på båda enheterna; den här grundproceduren skapar ingen oprövad GRE-over-IPsec-väg.

Artikeln behandlar en statisk IPv4-punkt-till-punkt-tunnel. Multicast, PIM-SM, BGP över GRE och leverantörsspecifika Anycast-tunnlar är möjliga utökningar, men planeras först när den grundläggande unicast-vägen fungerar.

Planera exempeltopologin

Exemplet ansluter två Sophos Firewalls:

• Plats A WAN: Port2 med 192.0.2.10
• Plats A LAN: 10.10.10.0/24
• Plats A tunnel-IP: 10.255.255.1
• Plats B WAN: Port2 med 198.51.100.20
• Plats B LAN: 10.20.20.0/24
• Plats B testserver: 10.20.20.10
• Plats B tunnel-IP: 10.255.255.2
• Tunnelnät: 10.255.255.0/30
• Testtjänst: HTTPS, alltså TCP 443

192.0.2.0/24 och 198.51.100.0/24 är dokumentationsnät och används inte i produktion. Båda WAN-adresserna, gränssnitten, tunnel-IP-adresserna, LAN-näten och testservern ersätts tillsammans med de verkliga värdena. Tunnel-IP-adresserna måste bilda ett eget punkt-till-punkt-nät som är identiskt planerat på båda sidor och får inte överlappa befintliga nät.

Exemplet använder tunnelnamnen gre_branch på plats A och gre_hq på plats B. Namnen kan väljas fritt, men får enligt det aktuella SFOS 22-API:t vara högst 15 tecken långa.

Före ändringen behövs en konfigurationsbackup, ett underhållsfönster och en oberoende administrationsanslutning som återställningsväg. Dessutom dokumenteras befintliga Static Routes och SD-WAN Routes, NAT-regler, brandväggsregler och överlappande nät.

Kontrollera kraven på den yttre vägen

De båda WAN-slutpunkterna måste kunna nå varandra via underlay-nätet. Grundkonfigurationen använder statiska IPv4-adresser på båda sidor. Om den lokala WAN-adressen tilldelas via PPPoE eller DHCP fortsätter man inte med det här receptet: äldre officiella Sophos-anvisningar för GRE utesluter dynamiska lokala WAN-gränssnitt, medan det aktuella SFOS 22-API:t endast dokumenterar DDNS för Remote Gateway. Stödet måste därför klarläggas för den konkreta versionen och anslutningen.

Före tunnelkonfigurationen kontrolleras följande:

• Fjärrsidans WAN-adress routas via förväntad WAN-gateway.
• Framförliggande routrar, leverantörer och ACL:er i molnet tillåter IP-protokoll 47 mellan de båda slutpunkterna.
• Det finns ingen CGNAT- eller NAT-konfiguration vars GRE-beteende är oklart.
• De inre tunnel-IP-adresserna och LAN-näten överlappar varken lokalt eller på fjärrsidan.
• Motparten använder samma yttre och inre värden spegelvänt.
• En returväg till båda LAN-näten är planerad.

En ping till den publika motparten kan stödja kontrollen av underlay-vägen, men bevisar inte GRE-stöd. Det hjälper inte heller att öppna TCP- eller UDP-port 47, eftersom GRE inte är ett portbaserat transportprotokoll.

Skapa GRE-tunneln på båda brandväggarna

Konfigurationen görs via CLI i menyn 4. Device Console. Den aktuella hjälpsidan från Sophos innehåller felaktigt renderade syntaxfragment. Före ändringen kontrolleras därför med Tab eller ? på den använda versionen att följande parametrar erbjuds.

Konfigurera plats A

På brandvägg A anges den lokala WAN-porten Port2, den yttre motparten 198.51.100.20 och det inre tunnelparet:

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

Därefter görs endast en läskontroll:

system gre tunnel show

Posten måste visa gre_branch, Port2, fjärrsidans WAN-adress och båda tunnel-IP-adresserna korrekt. Ett skrivfel döljs inte med en andra konfiguration med nästan samma namn.

Konfigurera plats B spegelvänt

På brandvägg B byter de lokala och externa värdena plats:

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

Även här följer läskontrollen:

system gre tunnel show

Enabled är vid den här tidpunkten endast en mellanliggande kontroll. Valideringen är inte klar förrän ett verkligt LAN-till-LAN-dataflöde fungerar.

Routa fjärrnät via GRE

För den enkla fasta vägen skapas en GRE-rutt på varje brandvägg. Plats A skickar LAN-nätet på plats B via gre_branch:

system gre route add net 10.20.20.0/255.255.255.0 tunnelname gre_branch

Plats B får den spegelvända returvägen:

system gre route add net 10.10.10.0/255.255.255.0 tunnelname gre_hq

Därefter läses de konfigurerade tilldelningarna på båda enheterna:

system gre route show

Rutten får inte konkurrera med en statisk, SD-WAN-, VPN- eller direktansluten väg som är lika lång eller mer specifik. Den globala Route Precedence ändras inte på måfå. Först verifieras vilken rutt som faktiskt matchar och vilken väg paketen tar.

Custom Gateway och SD-WAN som alternativ

Vissa leverantörsdesigner använder en Custom Gateway på GRE-vägen i stället för den enkla GRE-rutten och väljer den i en SD-WAN Route. Det passar när Source, Service, Failover eller en definierad gatewaystatus ska ingå i routingbeslutet.

Fjärrsidans tunnel-IP är då Next Hop. Health Check, Zone och Probe Target måste passa den konkreta leverantörsdesignen; övervakning som har stängts av i en tillverkaranvisning är inte en universell standard. Sambandet mellan objektet, proben och ett verkligt test förklaras i Skapa och kontrollera en Sophos Firewall Custom Gateway. Valet av väg beskrivs i Konfigurera en Sophos Firewall SD-WAN Route.

GRE-rutt och SD-WAN Route aktiveras inte okontrollerat parallellt för samma nät. Före bytet dokumenteras vilken mekanism som ska vinna och hur man återgår till den tidigare vägen.

Skapa brandväggsregler utan onödig NAT

GRE-tunneln och dess rutt tillåter ännu ingen nyttotrafik. För en HTTPS-anslutning som startas på plats A krävs en snäv, loggad regel på båda brandväggarna.

På brandvägg A gäller:

• 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: aktiverad

På brandvägg B tillåts den inkommande tunneltrafiken till testservern:

• 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: aktiverad

De här två reglerna täcker anslutningen som startas på plats A och dess stateful returtrafik. Om värdar på plats B själva ska få starta nya anslutningar till plats A skapas dessutom det spegelvända regelparet LAN till VPN på brandvägg B och VPN till LAN på brandvägg A, med de nät och tjänster som faktiskt behövs. En bred Any-regel behövs inte för valideringen.

Vid en normal platskoppling behålls den ursprungliga käll-IP-adressen. MASQ aktiveras inte som en förmodad lösning på ett routingproblem. Om returvägen saknas korrigeras rutten på motparten. Den allmänna regelstrukturen beskrivs i Skapa och kontrollera Sophos Firewall-regler säkert.

Validera tunneln och nyttotrafiken tillsammans

Kontrollen följer paketvägen och skiljer konfiguration från faktisk funktion:

1. Kör system gre tunnel show på båda brandväggarna och jämför slutpunkter och tunnel-IP-adresser.

2. Kontrollera rätt fjärr-LAN och rätt tunnelnamn med system gre route show.

3. Starta en ny HTTPS-anslutning från klienten i 10.10.10.0/24 till 10.20.20.10.

4. Kontrollera Source, Destination, Service, Firewall Rule ID, NAT Rule ID och Zone i Log viewer på båda brandväggarna.

5. Filtrera den yttre GRE-vägen under Diagnostics > Packet capture på plats A:

   host 198.51.100.20 and ip proto 47
   

6. Filtrera det inre testflödet separat:

   host 10.20.20.10 and tcp port 443
   

7. Jämför in- och utgång på båda brandväggarna och kontrollera den verkliga käll-IP-adressen på målservern.

8. Starta endast ett returtest med en tjänst som har tillåtits för detta.

Den yttre capture-filen visar inkapslingen mellan WAN-slutpunkterna. Den inre capture-filen och Rule ID visar om nyttopaketet går genom den förväntade regeln och rutten. Först när applikationen fungerar är hela vägen verifierad. Den kombinerade proceduren beskrivs mer utförligt i Testa brandväggsregler och Använd Packet Capture.

Avgränsa fel efter symptom

Inget GRE-paket lämnar WAN-gränssnittet

• Kontrollera Remote Gateway och lokalt local-gw i tunneln.
• Kontrollera underlay-rutten till fjärrsidans WAN-adress och vald WAN-gateway.
• Säkerställ att testflödet faktiskt matchar GRE-rutten eller avsedd SD-WAN Route.
• Jämför namn och tilldelning med system gre tunnel show och system gre route show.
• Skapa ingen TCP-/UDP-portöppning som ersättning för IP-protokoll 47.

GRE lämnar plats A men når inte plats B

• Kontrollera IP-protokoll 47 hos leverantören, framförliggande routrar, ACL:er i molnet och möjliga NAT-sträckor.
• Gör samtidigt en capture på plats B med det yttre WAN-filtret.
• Jämför yttre käll- och måladress med motpartens konfiguration.
• Stoppa vid dynamiskt WAN, CGNAT eller oklar NAT och dölj inte problemet med breda regler.

GRE syns på båda WAN-sidorna, men den inre trafiken saknas

• Local IP och Remote IP måste vara spegelvända på båda brandväggarna.
• Jämför GRE-rutt, målnät och tunnelnamn tecken för tecken.
• Kontrollera brandväggsregeln och förväntad Rule ID på båda sidor.
• Uteslut överlappande nät, NAT och en saknad returväg.
• Betrakta inte Enabled som bevis för den inre rutten eller applikationen.

Endast en riktning fungerar

• Kontrollera GRE-rutten för returnätet på plats B.
• Kontrollera om plats B ska initiera nya anslutningar och behöver en egen brandväggsregel för detta.
• Kontrollera Default Gateway, lokal värdbrandvägg och verklig käll-IP-adress på målservern.
• Jämför asymmetriska SD-WAN- eller statiska rutter på båda sidor.

Små paket fungerar, men stora anslutningar stannar

GRE lägger till en yttre IP-header och en GRE-header. Därmed minskar den användbara paketstorleken jämfört med underlay-nätet. Ett fast MTU- eller MSS-värde tas inte över oprövat: först mäts underlay-MTU, Path MTU Discovery, fragmentering och den berörda applikationen. Den kontrollerade proceduren beskrivs i Kontrollera MTU och MSS vid VPN-problem.

Testa HA och drift försiktigt

Den aktuella offentliga Sophos-dokumentationen ger inget löfte om avbrottsfri HA-failover eller synkroniserad tunnel-state för GRE. Ett kontrollerat rollbyte genomförs därför endast i ett underhållsfönster med oberoende administrationsåtkomst.

Efter bytet kontrolleras system gre tunnel show, system gre route show, yttre GRE-capture, ny klientanslutning, Rule ID och returväg på nytt. En befintlig TCP-anslutning räknas inte som kontinuitetsbevis.

I driften dokumenteras ansvarig, båda WAN-slutpunkterna, tunnel-IP-adresser, tunnelnamn, fjärrnät, routingmekanism, brandväggsregler, förväntad MTU-gräns och senaste verkliga test. Efter ändringar av WAN, leverantör, NAT, SD-WAN, Route Precedence eller motpart testas hela vägen på nytt.

Återställ säkert

Avvecklingen samordnas på båda brandväggarna:

1. Stoppa testtrafiken och spara det senaste tillståndet med system gre tunnel show och system gre route show.

2. Inaktivera nya brandväggsregler och en eventuell ny SD-WAN Route.

3. Ta, om den används, bort Custom Gateway från vägen först efter kontroll av Object usage.

4. Ta bort den konkreta GRE-rutten på plats A:

   system gre route del net 10.20.20.0/255.255.255.0 tunnelname gre_branch
   

5. Ta bort returrutten på plats B:

   system gre route del net 10.10.10.0/255.255.255.0 tunnelname gre_hq
   

6. Kontrollera med system gre route show att endast avsedda poster har försvunnit.

7. Ta sedan bort tunneln på plats A specifikt efter namn:

   system gre tunnel del name gre_branch
   

8. Ta endast bort tunneln för plats B där:

   system gre tunnel del name gre_hq
   

9. Avsluta med system gre tunnel show och ett test av den tidigare routingvägen.

del All används inte. Om syntaxen eller objektnamnet är oklart på den använda versionen kontrolleras det med Tab eller ? före borttagningen, utan att gissa.

Vanliga frågor