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.

För 6to4 måste man också skilja mellan den fortfarande definierade unicastmekanismen och den offentliga anycast-relaymekanismen. IETF har avvecklat anycast-6to4 på grund av dess driftproblem och rekommenderar att routrar har 6to4 avstängt som standard (RFC 7526). Aktivera därför inte 6to4 för en ny internetanslutning. Det bör högst användas för en befintlig, uttryckligen samordnad unicastdesign; inbyggd IPv6-anslutning, leverantörshanterad 6rd eller en fast 6in4-peer är lättare att kontrollera.

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. Zonmodellen och brandväggsreglerna måste stämma överens med den verkliga arkitekturen. Device access styr åtkomst till tjänster på själva brandväggen och ersätter inte en regel för vidarebefordrad applikationstrafik.

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.

Underlay måste transportera ett inkapslat IP-protokoll, inte en TCP- eller UDP-port. 6in4, 6to4 och 6rd använder IPv6-i-IPv4 med IPv4-protokollnummer 41 (RFC 4213); 4in6 följer IPv6-tunnelmodellen i RFC 2473 och identifierar det inre IPv4-paketet i den yttre IPv6-headern med det IANA-registrerade Next Header-värdet 4. Bekräfta denna exakta datasökväg med leverantören, upstream-brandväggen och alla NAT-enheter före driftsättning. Att öppna en port ersätter inte denna kontroll.

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 varken universella bästa värden eller något standardvärde på hjälpsidan. Dokumentera därför utgångsvärdena som visas i det egna formuläret och ändra dem endast när ett konkret underlay- eller QoS-krav kräver det.

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.

Gå för 6in4-exemplet till Rules and policies > Firewall rules, välj IPv6 och sedan Add firewall rule > New firewall rule. Ange Action: Accept, de verkliga värdena för Source zones, Source networks and devices, Destination zones, Destination networks och Services, och aktivera Log firewall traffic. Placera regeln så att en bredare regel inte matchar först. Svarstrafik som tillhör en tillåten tillståndsbaserad anslutning behöver ingen andra regel. Skapa bara en egen, lika begränsad regel om peeren ska få initiera nya anslutningar.

För en vanlig platsanslutning ska den ursprungliga source-adressen behållas. Låt Create linked NAT rule vara avstängt; aktivera inte MASQ som ersättning för en saknad returväg. SFOS skickar tillåten trafik oöversatt när ingen NAT-regel matchar. Om designen verkligen kräver översättning ska den planeras och testas separat med ursprungligt och översatt flöde. 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. Ange den interna adressen 2001:db8:200::20 under Diagnostics > Tools > Route lookup och bekräfta förväntat tunnelgrä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. Ange host 192.0.2.10 and host 198.51.100.20 i Enter BPF string under Diagnostics > Packet capture > Configure för den yttre kontrollen och spara. Starta capture, generera exakt ett test och stoppa den igen. För en separat inre capture ska BPF-strängen under Configure rensas och sparas; ange sedan Ethernet type: IPv6 och Destination IP: 2001:db8:200::20 under Display filter och spara. Starta capture för endast ett test och stoppa den därefter.
7. Kontrollera ingång, avkapsling, returroute och faktisk source-adress hos peeren.
8. Testa en ny anslutning som initieras av peeren endast om en separat regel tillåter den; den tillståndsbaserade regeln omfattar redan svarstrafiken.

En tunnelpost bevisar varken routen eller att peeren kan nås. 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 först testtrafiken vid rollback och inaktivera den nya brandväggsregeln. Ta endast bort manuella routes som skapades för denna tunnel eller återställ ändrade routes till det dokumenterade utgångsläget. Jämför uttryckligen automatiskt skapade 6to4- eller 6rd-routes med registreringen före och efter ändringen. Ta bort tunneln först när inget produktionsberoende återstår och ta därefter bort varje automatisk route som finns kvar separat. Bekräfta slutligen den tidigare sökvägen med Route lookup och testa 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