Konfigurera en Sophos Firewall IP-tunnel med 6in4, 6to4, 6rd eller 4in6

Under Network > IP tunnels skapar Sophos Firewall tunnlar som kapslar in ett nätverksprotokoll i ett annat. Därmed kan IPv6 transporteras över en IPv4-underlay eller IPv4 över en IPv6-underlay. SFOS erbjuder 6in4, 6to4, 6rd och 4in6 för dessa scenarier.

Den här funktionen är varken GRE-tunneln från Device Console eller en IPsec VPN. En IP-tunnel kapslar in paket, men krypterar eller autentiserar dem inte automatiskt.

⚠️ Använd en IP-tunnel över en icke betrodd underlay endast när säkerhetsdesignen uttryckligen accepterar avsaknaden av konfidentialitet och peer-autentisering. För en skyddad anslutning mellan platser är site-to-site IPsec normalt en bättre utgångspunkt.

Vilken tunneltyp passar?

De fyra typerna löser inte samma problem:

• 6in4 ansluter två IPv6-nätverk över en IPv4-backbone. Lokala och externa IPv4-endpoints konfigureras manuellt. Sophos rekommenderar typen för punkt-till-punkt-anslutningar.
• 6to4 transporterar IPv6 över IPv4 och är avsedd för punkt-till-multipunkt-design. Lokal IPv4-source anges manuellt, medan destinationsadressen kan hämtas automatiskt.
• 6rd utökar 6to4 med ett prefix som leverantören tillhandahåller. Typen passar endast om ISP:n lämnar de nödvändiga 6rd-värdena.
• 4in6 ansluter två IPv4-nätverk över en IPv6-backbone. De yttre lokala och externa tunnelendpoints är IPv6-adresser, och typen är avsedd för punkt-till-punkt-anslutningar.

För en kontrollerad länk med fasta endpoints är 6in4 eller 4in6 enklare att förstå. Välj inte 6to4 eller 6rd bara för att SFOS kan skapa en route automatiskt. Adresseringen och leverantörsdesignen måste passa exakt till mekanismen.

IPv6-stöd på Sophos Firewall sammanfattar SFOS IPv6-gränser. En GRE-tunnel transporterar däremot routad IP-trafik via ett separat Device Console-flöde och är inte utbytbar mot dessa fyra WebAdmin-typer.

Planera exemplet och förutsättningarna

Exemplet använder en statisk 6in4-tunnel mellan två platser:

• Visningsnamn: HQ-IPv6-via-IPv4
• Hardware name: v6hq01
• Lokal IPv4-WAN-adress: 192.0.2.10
• Extern IPv4-endpoint: 198.51.100.20
• Lokalt IPv6-nätverk: 2001:db8:100::/64
• Externt IPv6-nätverk: 2001:db8:200::/64
• Testserver: 2001:db8:200::20
• Tunnelgränssnittets zon: VPN i exemplet

192.0.2.0/24, 198.51.100.0/24 och 2001:db8::/32 är dokumentationsintervall. Ersätt dem, liksom namn, zon och prefix, med de verkliga värdena. Zonen VPN är ett begripligt exempelval, inte ett produktkrav. Det viktiga är att zonmodellen, brandväggsreglerna och Device Access stämmer överens med den verkliga arkitekturen.

Båda yttre endpoints måste kunna nås över underlay innan tunneln skapas. På båda sidor krävs en spegelvänd tunnel, unika interna nätverk, en returväg och en brandväggsregel för den verkliga applikationstrafiken. Överlappande prefix, ett saknat leverantörsvärde för 6rd eller en okänd peer-konfiguration är stoppvillkor.

En säkerhetskopia, ett underhållsfönster och oberoende hanteringsåtkomst ingår också i återställningsplanen. Skapa inte tunneln som ett experiment på den enda produktionsanslutningen.

Skapa IP-tunneln i WebAdmin

Under Network > IP tunnels > Add anges först identitet och tunneltyp, sedan endpoints och avancerade IP-värden.

Skilj på Name och Hardware name

Det vanliga Name får innehålla högst 58 tecken och kan ändras senare. Det bör visa syfte och peer, till exempel HQ-IPv6-via-IPv4.

Hardware name är tekniskt och kan inte ändras efter att det har sparats. Det får innehålla högst tio tecken och endast A-Z, a-z, 0-9 och _. SFOS blockerar dessutom många systemnamn och namndelar, däribland gre, ipsec0, sit, tun, xfrm, Port, MGMT, eth, WLAN och Halink. Det neutrala exempelvärdet v6hq01 undviker dessa konflikter.

Ett felaktigt Hardware name kan inte bytas senare. Dokumentera beroendena och återskapa tunneln kontrollerat. Kontrollera därför värdet särskilt noga före Save.

Ange tunneltyp, zon och endpoints

Välj 6in4 för exemplet. Ange avsedd säkerhetszon under Zone. Ange 192.0.2.10 under Local endpoint och 198.51.100.20 under Remote endpoint.

Adressfamiljen beror på typen. För 6in4, 6to4 och 6rd är lokal yttre endpoint IPv4; 6in4 har dessutom en fast extern IPv4-endpoint. För 4in6 är lokala och externa yttre endpoints IPv6-adresser. En intern destinationsroute ska inte anges i ett endpointfält.

I de avancerade inställningarna påverkar TTL hur länge inkapslade paket kan leva över underlay. TOS tilldelar det yttre IP-paketet ett type-of-service-värde för prioritering och routingbeteende. Den aktuella hjälpen anger inga universella bästa värden. Låt därför båda fälten stå kvar på det dokumenterade utgångsvärdet tills ett uppmätt routing- eller QoS-problem motiverar en ändring.

Efter Save bekräftar SFOS skapandet och öppnar routedialogrutan. För 6to4 och 6rd skapar brandväggen dessutom automatiskt en statisk IPv6-unicastroute. Viktigt: att stänga fönstret eller välja Cancel tar inte bort tunneln eller automatiskt skapade routes.

Lägg till routes och brandväggsregler

En sparad tunnel är ännu inte en fungerande datasökväg. För 6in4 läggs en statisk IPv6-route till det externa prefixet 2001:db8:200::/64 via det nya tunnelgränssnittet. Peeren behöver den spegelvända returvägen till 2001:db8:100::/64.

För 4in6 leder den interna routen till ett IPv4-destinationsnätverk. För 6to4 och 6rd ska den automatiskt skapade IPv6-routen läsas och jämföras med leverantörsdesignen innan fler routes läggs till. Cancel i den första routedialogrutan är ingen rollback.

Lägg till ytterligare routes under Routing > Static routes. Statiska routes på Sophos Firewall förklarar hur destinationsprefix, gränssnitt, avstånd, routingbeslut och ett verkligt test hänger ihop.

Skapa därefter en begränsad, loggad brandväggsregel mellan de berörda zonerna med verkliga source-, destination- och servicevärden. För en vanlig platsanslutning ska den ursprungliga source-adressen behållas; aktivera inte MASQ som ersättning för en saknad returväg. Processen finns i Konfigurera Sophos Firewall-regler säkert.

Validera tunneln och applikationstrafiken

Valideringen skiljer på sparad konfiguration, yttre inkapsling och intern applikation:

1. Jämför Name, Hardware name, typ, Zone och endpoints med peeren under Network > IP tunnels.
2. Kontrollera under Routing > Static routes att det externa interna prefixet pekar på förväntat tunnelgränssnitt.
3. Kör Route Lookup för den interna testservern och bekräfta förväntat gränssnitt.
4. Starta en ny anslutning till 2001:db8:200::20 från den lokala testklienten med en uttryckligen tillåten service.
5. Kontrollera Source, Destination, Service, Action och Firewall Rule ID i Log Viewer.
6. Observera först de yttre endpoints och sedan den interna testadressen med Packet Capture.
7. Kontrollera ingång, avkapsling, returroute och faktisk source-adress hos peeren.
8. Upprepa testet i motsatt riktning endast med en regel avsedd för den riktningen.

En grön eller synlig tunnelpost bevisar varken routen eller att peeren fungerar. En automatiskt skapad route bevisar inte heller att leverantören, mellanliggande enheter och brandväggsregler faktiskt transporterar inkapslingen. Packet Capture på Sophos Firewall förklarar kontrollerad capture.

Felsök efter symptom

Tunneln kan inte sparas

Kontrollera Name och Hardware name separat. Hardware name får vara högst tio tecken långt, endast använda tillåtna tecken och inte innehålla en blockerad systemterm. Kontrollera sedan att tunneltypen och adressfamiljen för lokala och externa endpoints stämmer överens.

Ett annat visningsnamn rättar inte ett ogiltigt Hardware name. Om en annan interface redan använder värdet ska ett unikt tekniskt namn planeras i stället för att prova slumpmässiga suffix flera gånger.

Tunneln finns, men ingen route leder till destinationsnätverket

För 6in4 och 4in6 läggs den nödvändiga statiska routen uttryckligen till. För 6to4 och 6rd kontrolleras att SFOS skapade den förväntade IPv6-unicastrouten och att prefixet passar designen. Ett fönster som tidigare stängdes med Cancel raderar inte den automatiskt sparade konfigurationen.

Route Lookup och routingtabellen är nästa bevis. Ändra inte global Route Precedence på grund av en misstanke och lägg inte till en konkurrerande blackhole- eller dummyroute som testhjälp.

Yttre paket syns, men intern trafik saknas

Ofta stämmer peertyp, endpointadresser, internt prefix eller returroute inte överens. Jämför båda konfigurationerna som spegelbilder. Kontrollera sedan brandväggsregeln, förväntad Firewall Rule ID och en capture av de interna source- och destination-adresserna.

Fungerande inkapsling bevisar inte att applikationstrafiken är tillåten. Omvänt kan en saknad Rule ID betyda att det interna paketet aldrig avkapslades eller hanterades av en annan route.

Små paket fungerar, men applikationer stannar

Den extra yttre IP-inkapslingen minskar den användbara paketstorleken jämfört med underlay. Kopiera inte ett främmande MTU-värde, utan mät Path MTU, fragmentering och den berörda applikationen. Den kontrollerade processen i Kontrollera MTU och MSS vid tunnelproblem kan även användas för denna analys, men fasta IPsec-värden ska inte överföras till IP-tunneln.

HA, ändringar och rollback

De två SFOS 22-hjälpsidorna lovar inget avbrottsfritt HA-tillstånd för dessa IP-tunnlar. Kontrollera efter ett planerat rollbyte tunnelposten, Route Lookup, yttre inkapsling, Firewall Rule ID och en ny applikationssession på nytt. En befintlig anslutning bevisar inte kontinuitet.

Dokumentera före en ändring Name, det oföränderliga Hardware name, typ, Zone, endpoints, automatiskt och manuellt skapade routes, regler och senaste verkliga test. Då kan en konfigurationsändring skiljas från en ändring i datasökvägen.

Stoppa testtrafiken först vid rollback. Inaktivera beroende brandväggsregler och manuella routes kontrollerat eller återställ deras bekräftade tidigare tillstånd. Kontrollera automatiskt skapade 6to4- eller 6rd-routes uttryckligen. Ta bort tunneln först när inget produktionsberoende återstår. Verifiera därefter tidigare routingväg och ett känt dataflöde igen.

Checklista

• Den valda typen passar de interna och externa adressfamiljerna.
• Båda endpoints och prefix är överenskomna med peeren.
• Visningsnamnet och det oföränderliga Hardware name är dokumenterade.
• Zone, statisk route och returväg passar säkerhetsdesignen.
• Automatiskt skapade 6to4- eller 6rd-routes har kontrollerats.
• En begränsad brandväggsregel matchar med förväntad Firewall Rule ID.
• Yttre inkapsling och intern applikationstrafik har testats separat.
• MTU, HA och rollback har validerats på den verkliga sökvägen.

Vanliga frågor