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.

Kort arbetsgång: Planera det interna destinationsnätverket och de yttre endpoints separat, spara rätt typ under Network > IP tunnels > Add och lägg till route, returroute samt en begränsad regel för den interna trafiken. Testa därefter en ny applikationssession och kontrollera yttre inkapsling, avkapsling och Rule ID separat. Save bekräftar konfigurationen, inte att datasökvägen har testats och fungerar.

⚠️ 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.

SFOS 23-hjälpen förklarar den automatiska mekanismen mer exakt: 6to4 härleder IPv6-prefixet från den lokala publika IPv4-adressen. Ingen extern endpoint konfigureras; destinationsgatewayen bestäms automatiskt utifrån IPv6-destinationsadressen. 6rd använder däremot IPv6-prefix och relaygateways som ISP:n tillhandahåller. Brandväggen bestämmer automatiskt den relaygateway som ISP:n tillhandahåller. Det kräver en lämplig 6rd-tjänst från ISP:n; välj inbyggd IPv6-anslutning om den finns tillgänglig. Dessa mekanismer ändrar inte varningen nedan om den äldre tekniken.

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.

Andra inställningar visar detta anpassningsbara gränssnittsnamn, inte det oföränderliga Hardware name.

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.

Den fullständiga dokumenterade begränsningslistan för Hardware name i SFOS 22 och 23 är: all, gre, oct, mv-pcimux0, mvmgmt0, pport_, lo, ipsec0, tun, ppp, imq, ifb, mast, sit, WWAN1, _ppp, vxlan, xfrm, USB, erspan0, Port, MGMT, eth, GE, gretap0, ip6tnl0, host, reds, wlnet, WLAN, Sophos, GuestAP, spq, Halink. Namnet får inte innehålla någon av dessa delar; förbudet gäller inte bara identiska fullständiga namn. De dokumenterade stavningarna behålls utan att dra slutsatser om hur skiftlägeskänslighet kontrolleras.

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.

Fältnamnet Remote endpoint följer SFOS 22-hjälpen. SFOS 23-hjälpen kallar fältet Remote gateway: det accepterar en IPv4-adress eller ett FQDN för 6in4, och en IPv6-adress eller ett FQDN för 4in6. Ett FQDN är peerens fullständiga DNS-namn, inte det interna destinationsprefixet. För Local endpoint beskriver SFOS 23 en adress knuten till ett gränssnitt (6in4/6to4), uttryckligen en knuten IPv4-adress för 6rd, och ett IPv6-gränssnitt för 4in6. Den lokala adressfamiljen är fortfarande den som beskrivs nedan. Skillnader i hjälptexten bevisar inte i vilken exakt version stödet i den körande produkten började.

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.

Dessa TTL/TOS-grunder följer SFOS 22-hjälpen. SFOS 23-hjälpen förklarar TTL som det maximala antalet routrar som ett inkapslat paket kan passera innan det kastas. Gränsen hjälper till att förhindra routingloopar. Inte heller här anges något numeriskt standardvärde för TTL eller ToS.

För 4in6 beskriver SFOS 23 dessutom dessa avancerade inställningar:

• Inherit ToS är valfritt och använder det inre paketets ToS-värde.
• MTU är den största paketstorleken i byte som kan skickas genom tunneln utan fragmentering. Det dokumenterade standardvärdet är det fysiska gränssnittets MTU minus 48 byte; minskningen tar hänsyn till overhead för 4in6-inkapsling.
• Override MSS är valfritt och gör det möjligt att ange MSS manuellt. MSS är den största TCP-nyttolasten i byte i ett enda TCP-paket utan fragmentering. Anpassning kan förhindra fragmentering eller ta hänsyn till Path MTU-gränser. Det dokumenterade standardvärdet är MTU-värdet minus 40 byte.

Dessa formler är dokumenterade värden, inte egna beräkningar från protokolloverhead eller resultat från labbtester. Ingen förvald aktiveringsstatus påstås för de valfria kryssrutorna. Anpassningen är fortfarande beroende av den verkliga sökvägen.

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.

SFOS 23-API: schema och validering

Det här avsnittet beskriver API-dokumentationen för Add IP Tunnel / Edit IP Tunnel, inte WebAdmin-flödet eller en testad begäran. Jämfört med SFOS 22-dokumentationen lägger parametertabellen för SFOS 23 till fyra valfria fält av typen SCALAR:

• MSS: INTEGER, tillåtet intervall 536–8912, högst fyra siffror.
• MTU: INTEGER, tillåtet intervall 576–8952, högst fyra siffror.
• LocalInterface: STRING för tunnelns lokala gränssnitt; cellen Default är tom. Det fastställer inget standardvärde vid körning.
• InheritToS: tillåtna värden Disable och Enable.

Tabellen fastställer inte att varje fält gäller för varje tunneltyp, företrädet mellan LocalInterface och LocalEndPoint, obligatoriska fältkombinationer eller i vilken version stödet vid körning började. WebAdmin-informationen om endpoints och FQDN överförs inte som ett löfte om API-kompatibilitet.

API-status 541 för Add och Edit

För båda åtgärderna dokumenterar SFOS 23 status 541 med meddelandet MTU and MSS must not exceed the local interface values. MTU och MSS får alltså inte överstiga motsvarande värden för det lokala gränssnittet. Jämför de skickade MTU/MSS-värdena, det tillhörande lokala gränssnittet och dess dokumenterade konfiguration innan något ändras. Den här API-valideringen mäter inte MTU i datasökvägen och fastställer inget generellt beräkningssamband mellan MTU och MSS.

Motstridiga standardvärden är fortfarande olösta

API-tabellen anger bokstavligen Default: Enable för MSS, trots att fältet beskrivs som INTEGER med ett numeriskt intervall. För InheritToS anger den bokstavligen Default: off, trots att endast Disable och Enable listas som tillåtna värden. Dessa motstridiga dokumentationsvärden är inga rekommenderade payloadvärden och korrigeras inte eller omtolkas till andra token.

API:t anger också MTU-standardvärdet 1500 och beskriver ToS-arv från det lokala gränssnittet. WebAdmin-hjälpen för 4in6 anger däremot det fysiska gränssnittets MTU minus 48 byte, MSS lika med MTU minus 40 byte och ToS-arv från det inre paketet. Kopplingen mellan dessa gränssnitt är fortfarande oklar; de korrekta WebAdmin-formlerna och valfria kontrollerna ovan förblir oförändrade.

Direkt tillämpbara automatiseringsinstruktioner som förutsätter dessa standardvärden, arvsregler eller fältprioriteter förblir uteslutna. Därför tillhandahålls ingen körbar API-payload här. Det kräver ett förtydligande från Sophos eller ett uttryckligen godkänt test på motsvarande SFOS-version; den dokumenterade schema- och statusinformationen är inget produkttest.

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.

För ytterligare IPv6-routes efter att 6to4 eller 6rd har sparats anger SFOS 23 popupfälten Destination IP (IPv6) och Gateway (IPv6). Ange destination och gateway enligt nätverksdesignen och välj Save; välj Cancel om ingen ytterligare route behövs. Dessa IPv6-fält gäller inte den interna IPv4-routen i en 4in6-tunnel. SFOS 22-varningen om sparad konfiguration vid Cancel ska fortfarande beaktas.

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.

4in6: transportera IPv4-trafik över IPv6

Med 4in6 ändras inte bara tunneltypen jämfört med 6in4-exemplet. De yttre endpoints är IPv6, medan de routade nätverken och brandväggsreglerna är IPv4. Ett separat planeringsexempel använder 10.10.10.0/24 lokalt, 10.20.20.0/24 på den externa platsen och 10.20.20.20 som testserver. Den yttre lokala gränssnittsadressen är 2001:db8:10::10 och den externa gatewayadressen är 2001:db8:20::20. De privata IPv4-nätverken och IPv6-dokumentationsadresserna ersätts med unika interna nätverk som inte överlappar och IPv6-endpoints som faktiskt kan nås över underlay.

1. Kontrollera först IPv6-underlay-sökvägen till 2001:db8:20::20. Routen till den yttre peeren måste gå över underlay, inte genom tunneln som ska upprättas med denna peer. En lyckad ping bevisar i sig inte att de inkapslade IPv4-paketen transporteras.
2. Välj 4in6 under Network > IP tunnels > Add, ange ett unikt namn och Hardware name och tilldela avsedd Zone. I SFOS 23 väljer du IPv6-gränssnittet med den planerade lokala adressen under Local endpoint och anger den externa IPv6-adressen under Remote gateway. På motparten byter de lokala och externa endpoints plats. Beakta även SFOS 23-inställningarna för MTU, Override MSS och Inherit ToS som beskrivs ovan.
3. Efter Save skapar du en IPv4-route till 10.20.20.0/24 via det nya tunnelgränssnittet under Routing > Static routes. Motparten får returrouten till 10.10.10.0/24. IPv6-fälten i den extra routedialogrutan för 6to4/6rd ska inte användas som mall för detta.
4. Välj IPv4 under Rules and policies > Firewall rules. Tillåt endast de anslutningar som behövs från det lokala IPv4-nätverket till det externa IPv4-nätverket, ange de verkliga zonerna och tjänsterna och aktivera Log firewall traffic. IPv6-underlay-adresserna ska inte ersätta de interna IPv4-nätverken i denna regel för applikationstrafik. Om ingen adressöversättning är avsedd behålls source-adressen.
5. Kontrollera 10.20.20.20 med Diagnostics > Tools > Route lookup och starta därefter en ny, tillåten anslutning till denna server från den lokala testklienten. Kontrollera avkapsling och returväg hos peeren. När testsessionen har avslutats ska de interna IPv4-adresserna och förväntad Firewall Rule ID visas i Log Viewer; under sessionen används capture för att kontrollera sökvägen direkt.
6. Använd BPF-filtret host 2001:db8:10::10 and host 2001:db8:20::20 för den yttre capture i capture-flödet som beskrivs nedan. För en separat inre capture rensar du BPF-strängen igen och väljer Ethernet type: IPv4 samt Destination IP: 10.20.20.20 under Display filter. Fånga endast ett test åt gången och stoppa sedan capture. Rollback genomförs med samma beroendekontroll som nedan, men här för de IPv4-routes och -regler som skapats särskilt för tunneln.

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 interna prefixet på fjärrsidan 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.

Det yttre hostfiltret fångar även annan trafik mellan endpoints. För 6in4-exemplet ska du därför leta efter paket med de förväntade yttre IPv4-adresserna och IP-protokoll 41; en ICMP-ping mellan samma värdar bevisar inte inkapsling. För 4in6 kontrolleras på motsvarande sätt ett yttre IPv6-paket med ett inre IPv4-paket. Först jämförelsen med den inre capture och en applikationssession som faktiskt fungerar bekräftar hela sökvägen. Capture-data kan innehålla nyttolast och ska endast lagras skyddat eller anonymiseras innan de delas.

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.

Testtrafiken saknas i den yttre capture

Jämför först de aktiva capture- och displayfiltren med de yttre endpoints som faktiskt används. Om Remote gateway anges som ett FQDN kontrollerar du att brandväggen kan slå upp namnet till den förväntade peer-adressen med rätt adressfamilj för tunneltypen: IPv4 för 6in4, IPv6 för 4in6. FQDN-alternativet i sig garanterar varken ett visst DNS-uppdateringsintervall eller avbrottsfri failover vid ett adressbyte.

Kontrollera därefter att testklienten över huvud taget skickar trafik till den interna destinationen och når brandväggen via sin gateway. På brandväggen måste routingbeslutet för denna destination välja tunnelgränssnittet. Om rätt inkapsling syns lokalt men inte hos peeren är nästa steg att kontrollera underlay-sökvägen och dess protokolltillstånd hos leverantören och på upstream-enheter. Regler ska inte generellt utökas till Any, och NAT ska inte aktiveras på prov som ersättning för denna avgränsning. Om orsaken fortfarande är oklar utgör SFOS-versionen, båda endpointkonfigurationerna, routes och tidsmässigt samordnade captures från båda sidor underlaget för eskalering.

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.

Enligt SFOS 23-hjälpen tas även den automatiskt skapade statiska IPv6-unicastrouten bort när en 6to4- eller 6rd-tunnel tas bort. Denna förväntan ersätter varken beroendekontroller eller jämförelsen före/efter. Den gäller inte alla manuellt tillagda routes och överförs inte till SFOS 22 enbart på grundval av SFOS 23-hjälpen.

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