Hoppa till innehållet
Avanet

Konfigurera och verifiera OSPF i Sophos Firewall

OSPF utbyter automatiskt IPv4-routes mellan routrar. Det är användbart när flera platser, redundanta vägar eller nät som ändras ofta blir besvärliga att underhålla med statiska routes. För en liten eller befintlig routingdomän med få routrar kan RIPv2 vara enklare; OSPF erbjuder däremot snabbare konvergens och en mer skalbar vägmodell.

I följande exempel bildar två Sophos Firewalls en OSPF-grannrelation via ett eget transitnät. I slutet har Neighbor statusen Full, Firewall A känner till LAN-nätet bakom Firewall B och vice versa. För IPv6 konfigureras OSPFv3 separat.

⚠️ OSPF-grannrelationer ska endast upprättas på avsedda, betrodda transit- eller VPN-gränssnitt. I exemplet anges även LAN-nätet som OSPF Network så att SFOS annonserar prefixet. Därmed aktiverar SFOS OSPF på LAN-gränssnittet och kan skicka utgående OSPF Hellos. Dynamic Routing förblir inaktiverat för LAN-zonen så att inkommande OSPF-paket inte tillåts; detta hindrar inte utgående Hellos. Aktivera inte Redistribute connected innan det är klart vilka direkt anslutna nät som annonseras.

Översikt över processen

Följande steg krävs för en enkel OSPFv2-anslutning:

  1. Adressera transitinterfacen och kontrollera den direkta IP-nåbarheten.
  2. Tillåt Dynamic Routing under Administration > Device access för en separat transitzon eller med ett strikt begränsat Local Service ACL Exception.
  3. Ange ett unikt Router ID på varje brandvägg under Routing > OSPF.
  4. Skapa Area 0.0.0.0 som Normal.
  5. Tilldela det lokala transitnätet till Area 0.0.0.0 under Networks.
  6. Ange respektive LAN som det andra OSPF-nätverket eller använd en separat verifierad omfördelning.
  7. Kontrollera Neighbor-statusen Full och den inlärda routen under Routing > Information > OSPF.

Ett OSPF-Network är inte det fjärranslutna målnätet. Posten aktiverar OSPF på de lokala interface vars IP-adress ligger inom nätet. Fjärr-LAN-nätet visas först när motparten annonserar det via OSPF.

Vad OSPF avgör på brandväggen

OSPF är ett internt link-state-routingprotokoll. Angränsande routrar utbyter information om nåbara nät och vägar, bygger en Link-State Database och beräknar den bästa vägen. Ett lägre Cost föredras framför ett högre.

OSPF löser därmed en annan uppgift än brandväggsregler och SD-WAN:

  • OSPF lär sig och distribuerar målnät inom den egna routingdomänen.
  • En brandväggsregel avgör fortfarande om nyttotrafik får passera mellan de berörda zonerna och näten.
  • NAT ändrar adresser vid behov, men ingår inte i OSPF.
  • En SD-WAN Route kan dessutom fatta beslut utifrån källa, tjänst, applikation eller länkkvalitet.

OSPF-rutter visas med övriga unicast-rutter. Klassisk routing väljer först det längsta matchande prefixet. För samma prefix jämför SFOS Administrative Distance för routingkällorna; mellan jämförbara OSPF-vägar avgör sedan OSPF-metriken. Separat bestämmer global Route Precedence om klassisk routing, SD-WAN Policy Routes eller VPN-rutter utvärderas först. Dokumentera ordningen med system route_precedence show före en global ändring.

OSPFv2 hanterar IPv4. OSPFv3 fyller samma funktion för IPv6, men konfigureras separat i Sophos Firewall.

Planera exempeltopologin

Exempelvärdena representerar två platser:

  • Firewall A: Router ID 192.0.2.10, transit-IP 198.51.100.1/30, lokalt LAN 10.10.10.0/24
  • Firewall B: Router ID 192.0.2.20, transit-IP 198.51.100.2/30, lokalt LAN 10.20.20.0/24
  • Transitnät: 198.51.100.0/30
  • OSPF Area: 0.0.0.0

Adresserna 192.0.2.0/24 och 198.51.100.0/24 är dokumentationsnät. Ersätt dem med de faktiska värdena i miljön.

Router ID ser ut som en IPv4-adress, men behöver inte vara tilldelat ett interface. Det viktiga är att det är unikt inom OSPF-domänen och förblir stabilt över tid. 0.0.0.0 är inte tillåtet. Utan ett eget värde använder SFOS den högsta interfaceadressen. Ett medvetet valt Router ID förhindrar att identiteten oväntat ändras efter en interfaceändring.

För denna enkla konfiguration räcker Backbone Area 0.0.0.0. Flera Areas är motiverade först när en större routingdomän medvetet ska struktureras och summeras. Varje ytterligare Area behöver en anslutning till Backbone Area.

Förbered OSPF säkert

Följande förutsättningar bör vara uppfyllda innan OSPF konfigureras:

  • Brandväggen körs i Gateway Mode. OSPF är inte tillgängligt i Transparent Mode.
  • Båda transit-IP-adresserna ligger i samma nät och kan nå varandra direkt, exempelvis med Ping.
  • Interface, subnätmask, MTU och zon är dokumenterade.
  • Router ID, Area, Authentication, Hello interval och Dead interval är avstämda på båda sidor.
  • Det finns en konfigurationsbackup och oberoende managementåtkomst.
  • Lämpliga brandväggsregler och returvägar är planerade för de två LAN-näten.

Ett eget transit-VLAN och en separat transitzon förenklar skyddet. Grunderna beskrivs i Konfigurera zoner och interface i Sophos Firewall.

Tillåt Dynamic Routing selektivt

Under Administration > Device access är Dynamic Routing som standard avaktiverat för alla zoner. I exemplet aktiveras tjänsten endast i den egna transitzon som nätet 198.51.100.0/30 är kopplat till.

Kryssrutan i Device Access gäller hela zonen. En separat transitzon är därför tydligast. Om transitgränssnittet delar zon kan en Local service ACL exception rule begränsa IP version, Source zone, Source networks and hosts, Destination host, tjänsten Dynamic Routing, Action och regelposition. OSPFv2 använder dock multicastdestinationerna 224.0.0.5 och 224.0.0.6; den lokala transitadressen är därför inte nödvändigtvis en fungerande Destination host. Bekräfta multicastmatchningen på installerad SFOS-build. Utan bekräftelse är en separat transitzon det säkra valet.

Denna tillåtelse gäller OSPF-paket till själva brandväggen. Ingen vanlig brandväggsregel krävs för detta. Den faktiska datatrafiken mellan 10.10.10.0/24 och 10.20.20.0/24 behöver ändå lämpliga IPv4-brandväggsregler. Skillnaden mellan lokala tjänster och vidarebefordrad trafik beskrivs i Skydda Device Access i Sophos Firewall.

Konfigurera OSPFv2 i WebAdmin

Följande steg utförs på båda brandväggarna. Endast Router ID, transit-IP och lokalt LAN skiljer sig åt.

1. Ange globala inställningar

Under Routing > OSPF anges de globala värdena:

  • Router ID: på Firewall A 192.0.2.10, på Firewall B 192.0.2.20
  • Default metric: behåll 20 om inget annat värde medvetet har fastställts för redistribuerade routes
  • ABR type: Standard för en ny standardkonfiguration
  • Auto-cost reference-bandwidth: behåll standardvärdet 100000 Mbps så länge kostnadsplaneringen inte kräver ett annat gemensamt referensvärde
  • Default-information originate: Never så länge brandväggen inte uttryckligen ska distribuera en Default Route till alla OSPF-grannar
  • Redistribute connected, static, RIP och BGP: låt dem vara avaktiverade till en början

Tillämpa därefter den globala konfigurationen med Apply.

Standardmetriken gäller rutter som importeras till OSPF. För redistribuerade rutter och annonserad Default Route kan Metric type väljas. External type 1 adderar intern kostnad till ASBR och extern kostnad. Med External type 2 jämförs först den externa metriken; vid lika värde används den interna vägen till ASBR som skiljekriterium. Interfacekostnaden avgör vägvalet inom OSPF. Lägre kostnad föredras.

Default-information originate: Always får inte användas som en snabb omkopplare för internetfailover. Brandväggen skulle då annonsera en Default Route även om den inte själv har någon. Regular annonserar den endast när det finns en Default Route i routingtabellen.

2. Skapa Backbone Area

Klicka på Add i området Areas och ange följande värden:

  • Area: 0.0.0.0
  • Type: Normal

Välj Authentication Type Text eller MD5 för Area. Om motparten stöder MD5 bör det föredras framför klartextalternativet. Tillhörande Key ID och nyckel anges senare på transitinterfacet. MD5 autentiserar OSPF-paketen, men krypterar inte den routinginformation som utbyts.

Spara därefter Area med Save.

För den här enkla designen förblir Area 0.0.0.0 av typen Normal. En Stub Area tar inte emot externa AS-routes, medan Stub no-summary dessutom undertrycker vanliga summary-routes med undantag för standardrouten. En NSSA kan införa egna externa routes i OSPF-domänen som typ 7-LSA:er; NSSA no-summary kombinerar detta med den striktare summary-begränsningen. En Virtual Link är endast tillgänglig för en Normal Area. Ändra inte Area-typen som en snabb felsökningsåtgärd, eftersom båda sidor och hela Area-designen måste stämma överens.

3. Lägg till transitnätet

Klicka på Add i området Networks:

  • IPv4/Netmask: 198.51.100.0/30
  • Area: 0.0.0.0

På Firewall A matchar adressen 198.51.100.1 detta Network, och på Firewall B matchar 198.51.100.2. Därmed körs OSPF på respektive transitinterface och de två brandväggarna kan bilda en grannrelation.

Spara Network-posten med Save.

Ett OSPF-nätverk betecknar alltid ett lokalt nät: SFOS aktiverar OSPF på varje gränssnitt vars adress matchar posten och annonserar dess prefix. För LAN använder detta exempel i steg 5 också en nätverkspost, eftersom det då går att exakt välja och ta bort önskat prefix i WebAdmin. Nackdelen är att LAN-gränssnittet då också blir en del av OSPF. En filtrerad omfördelning undviker detta, men kräver under SFOS 22 en separat kontrollerad CLI-konfiguration samt återställning.

4. Åsidosätt endast interfacevärden medvetet

Under Override interface configuration kan transitinterfacet väljas. Standardvärdena är lämpliga för många Ethernet-anslutningar:

  • Hello interval: 10 sekunder
  • Dead interval: 40 sekunder
  • Retransmit interval: 5 sekunder
  • Transmit delay: 1 sekund
  • Interface cost: Auto
  • Router priority: 1

Hello och Dead måste vara identiska på alla routrar i segmentet. Retransmit Interval och Transmit Delay anges lokalt. Cost och Router Priority får avsiktligt skilja sig åt: Cost avgör den föredragna datavägen, medan Priority påverkar valet av DR och BDR i broadcastnät. Priority 0 utesluter interfacet från detta val.

Vid samma Priority avgör Router ID, men ett pågående DR-val är inte preemptive. Ett manuellt angivet Cost är användbart om en väg ska föredras bland flera. Med Auto beräknar SFOS Cost utifrån global Reference Bandwidth och den konfigurerade interfacehastigheten. Om länkhastigheten ändras under Network > Interfaces använder OSPF inte det nya Auto-Cost-värdet förrän brandväggen har startats om.

Vid MD5-autentisering väljs Authentication Type MD5 i Area. Därefter anges samma Key ID mellan 0 och 255 och samma nyckel på transitinterfacet på båda sidor.

Spara ändrade interfacevärden med Save.

5. Annonsera endast nödvändiga LAN-nät

I exemplet måste Firewall A annonsera 10.10.10.0/24 och Firewall B 10.20.20.0/24. Det finns två fundamentalt olika sätt att göra detta:

  • En OSPF Network tar upp det passande lokala gränssnittet i OSPF och annonserar sitt prefix.
  • Redistribution tar över rutter från en annan routingskälla i OSPF.

Klicka på Routing > OSPF > NetworksAdd och tilldela det respektive LAN till området 0.0.0.0: på brandvägg A 10.10.10.0/24, på brandvägg B 10.20.20.0/24. Spara posten med Save. Dynamic Routing förblir inaktiverad för LAN-zonen; tjänsten är endast tillåten för transitzonen eller det begränsade Local Service ACL-undantaget. Därefter måste motparten exakt lära sig detta LAN. Ett oönskat lokalt nätverk tjänar som negativ kontroll och får inte visas i dess OSPF-routingtabell.

Denna variant passar så länge LAN-gränssnitten medvetet får vara en del av OSPF. Om OSPF i princip inte ska aktiveras där eller om de prefix som ska distribueras kommer från Static, RIP eller BGP, är redistribution den mer lämpliga metoden. Alternativet Redistribute connected i WebAdmin tar dock över alla direkt anslutna nät. På en produktiv brandvägg kan detta också inkludera WAN-, Management-, DMZ-, VPN- och andra VLAN-nät. Därför får kryssrutan inte aktiveras utan vidare.

För Remote Access SSL VPN importerar Redistribute connected endast det dynamiska klientsubnätet. Ett statiskt tilldelat SSL VPN-subnät injiceras inte automatiskt och måste, om det verkligen behövs, konfigureras som ett separat OSPF Network och testas separat.

WebAdmin kan inte filtrera Connected Routes efter enskilda prefix. Kommandoradshjälpen för SFOS 22 visar visserligen en ACL med Route Map, men dokumenterar endast ett exkluderingsexempel och inte en fullständig återställning av en allowlista i produktion. Utan en återställning som har verifierats för den aktuella SFOS-versionen går det inte att använda detta som ett säkert copy-and-paste-recept. Den som behöver selektiv redistribution bör därför planera ACL och Route Map som en separat routingändring, få syntax och återställning bekräftade för installerad build samt kontrollera både önskat prefix och minst ett nät som uttryckligen inte får annonseras hos motparten.

Det globala WebAdmin-alternativet Redistribute connected förblir inaktiverat i en CLI-filterad variant. Efter senare ändringar i den globala OSPF-konfigurationen måste show running-config kontrolleras igen, eftersom WebAdmin kan ta bort motstridiga avancerade CLI-inställningar och ändringar av log-adjacency-changes. Även Redistribute static aktiveras först efter en fullständig inventering av de befintliga statiska rutterna.

Konfigurera och ta bort OSPF i CLI

OSPF-CLI finns under 3. Route Configuration > 1. Configure Unicast Routing > 2. Configure OSPF. Följande minimala konfiguration för brandvägg A avbildar transitnät och LAN-annonsering för WebAdmin-exemplet:

enable
configure terminal
router ospf
ospf router-id 192.0.2.10
network 198.51.100.0/30 area 0
network 10.10.10.0/24 area 0
log-adjacency-changes
exit
write
show running-config
end

På brandvägg B används istället router-ID 192.0.2.20 och LAN-nätverket 10.20.20.0/24.

Router-ID måste vara unik, får inte vara 0.0.0.0 och behöver inte vara en faktisk tilldelad IP-adress. Utan manuell angivelse använder SFOS den högsta interface-IP:n. Area-ID får anges som ett nummer från 0 till 4294967295 eller i IPv4-notation. SFOS lagrar nätverket normaliserat enligt masken; från 198.51.100.1/30 blir det därför 198.51.100.0/30. Precis detta lagrade värde är senare avgörande för kontroll och borttagning. log-adjacency-changes loggar ändringar av grannar utan debug-läge och sätts som standard vid en WebAdmin-konfiguration.

Skilj mellan Network, OSPF-processen och Default Route

För att endast ta bort ett Network används no på raden från show running-config under router ospf:

enable
configure terminal
router ospf
no network 198.51.100.0/30 area 0
exit
write
show running-config
end

Därmed avslutas OSPF på de tillhörande gränssnitten och de berörda annonseringarna försvinner. no router ospf tar däremot bort OSPFv2-routingkonfigurationen. Före detta destruktiva steg säkerhetskopieras den fullständiga aktuella konfigurationen, en backup och alternativa rutter; kommandot bör utföras under ett underhållsfönster och är ingen tillfällig av/på-knapp.

ospf push-default-route-to-kernel löser en tredje, separat uppgift: En via OSPF inlärd standardrutt tas upp i kernel-routingtabelen. Kommandot annonserar ingen standardrutt till grannarna och är därför inte samma som Default-information originate. Före detta säkerhetskopieras befintliga standardrutter, ruttpräferens, hanteringsåterväg och ruttuppslag. Den officiellt dokumenterade återställningen sker vid OSPF-prompten med no ospf push-default-route-to-kernel; därefter kontrolleras routingtabellen, ruttuppslag, hanteringstillgång och faktisk trafik på nytt.

Globala ändringar i WebAdmin kan ta bort motstridiga CLI-inställningar. Kontrollera efter varje sådan ändring show running-config, Neighbors, inlärda routes och den sparade konfigurationen igen.

Kontrollera och verifiera OSPF

En grannrelation i sig bevisar ännu inte att önskat LAN går att nå. Verifieringen utförs därför från OSPF-lagret till det faktiska paketflödet.

  1. Under Routing > Information > OSPF > Neighbors måste motparten visas med sitt Router ID. Full visar att relevant Link-State-information har utbytts fullständigt.
  2. Under Routes måste brandvägg A se 10.20.20.0/24 över 198.51.100.2. Brandvägg B förväntar sig 10.10.10.0/24 över 198.51.100.1. Ett icke godkänt testprefix får däremot inte dyka upp.
  3. Under Interface kontrolleras Area, Router-ID, Kostnad, Timer, Nätverkstyp och MTU. Database visar Link-State-databasen; Border routers hjälper till i designer med flera Areas, för att kontrollera ABR- och ASBR-poster.
  4. Under Diagnostics > Tools > Route lookup kontrolleras ett konkret mål, exempelvis 10.20.20.10 på Firewall A.
  5. Testa därefter en verklig anslutning mellan en värd i vardera LAN. Log Viewer och Packet Capture måste visa den förväntade brandväggsregeln, transitinterfacet och returtrafiken.

För de två sista stegen hjälper Testa en Sophos Firewall-regel med Log Viewer och Packet Capture.

För en ytterligare SSH-efterkontroll går CLI-vägen via 3. Route Configuration > 1. Configure Unicast Routing > 2. Configure OSPF. show running-config är där det officiellt dokumenterade kommandot för den sparade OSPF-konfigurationen. Neighbor, Database, Interfaces och beräknade rutter kontrolleras pålitligt i SFOS 22 under Routing > Information > OSPF; därför nämner denna artikel inga odokumenterade Routing-Daemon-Show-kommandon.

I Advanced Shell ger OSPF- och kernelloggarna ytterligare sammanhang. Åtkomsten går via 5. Device Management > 3. Advanced Shell:

cd /log
tail -f ospfd.log

Den löpande utmatningen avslutas med Ctrl+C. Därefter kan den andra loggen kontrolleras:

tail -f zebra.log

ospfd.log visar OSPF-händelser. zebra.log hjälper till att kontrollera om en dynamiskt inlärd route har installerats i kärnan. Den som inte vill följa loggen i realtid kan exempelvis använda less /log/ospfd.log. Sophos Firewall-tjänster och loggfiler kopplar fler filer till ansvariga tjänster.

Avgränsa fel systematiskt

Ingen Neighbor visas

Kontrollera först den direkta nåbarheten mellan transit-IP-adresserna. Därefter måste transitinterfacet vara up, OSPF Network passa det lokala interface-IP-numret och Dynamic Routing vara aktiverat i rätt zon. Area, subnätmask, Authentication Type, Key ID, nyckel, Hello och Dead måste stämma överens på båda sidor. Duplicerade Router ID förhindrar också en korrekt anslutning.

Neighbor stannar i Init eller 2-Way

Init betyder att Hello-paket tas emot, men att kommunikationen ännu inte har bekräftats i båda riktningarna. Device Access, asymmetriska filter, interfacetilldelning och returväg är då de första kontrollpunkterna.

2-Way är normalt i ett broadcastnät mellan två routrar när ingen av dem är DR eller BDR. I exemplet med exakt två OSPF-routrar och Priority 1 blir deltagarna DR och BDR. Deras grannrelation bör därför nå Full. Om den stannar i 2-Way ska Router Priority, Network Type och motparten kontrolleras.

Neighbor stannar i ExStart, Exchange eller Loading

I dessa tillstånd har synkroniseringen av Link-State Database påbörjats, men slutförs inte. Vanliga orsaker är olika MTU-värden, Network Types som inte stämmer överens, duplicerade Router ID eller instabila anslutningar. Under Routing > Information > OSPF > Interface finns MTU, MTU Mismatch Detection, Network Type och Timer för jämförelse.

Neighbor är Full, men fjärr-LAN-nätet saknas

Då fungerar grannskapet, men LAN meddelas inte. Vid den i detta exempel använda nätverksmetoden måste den anslutna routen finnas på den sändande brandväggen och under router ospf ska den lämpliga network … area …-posten visas. show running-config visar det sparade värdet.

Om istället redistribution används måste den valda routningskällan samt eventuellt ACL, Route Map och redistribute … route-map passa till det önskade prefixet. Vid Redistribute connected måste dessutom hela listan över alla annonserade anslutna rutter kontrolleras.

Om just ett nät bakom en policybaserad IPsec-tunnel saknas efter en uppgradering till SFOS 22 kan ett beroende av redistribute kernel vara orsaken. Tunneln och OSPF-grannen kan samtidigt se friska ut; SFOS 22: IPsec-rutter och redistribute kernel förklarar kontrollen och måldesignen med route-based XFRM.

Rutten finns, men trafiken fungerar inte

OSPF har utfört sin uppgift när routen med rätt Next Hop finns. Därefter ligger felen oftast i brandväggsregeln, NAT, Route Precedence, returvägen eller målsystemet. I normalt routade platsnät behövs vanligtvis ingen SNAT, eftersom båda brandväggarna ska känna till LAN-näten via OSPF.

OSPF via route-based IPsec

OSPF kan också köras över ett XFRM-gränssnitt för en routad site-to-site IPsec-tunnel. För att SFOS ska skapa XFRM-gränssnitten måste både lokalt och fjärran subnät på båda sidor vara Any. Inställningen IPv4, IPv6 eller Dual avgör därefter vilka IP-versioner som används; vid Dual skapas separata IPv4- och IPv6-brandväggsregler manuellt. Med specifika trafikselektorer uppstår inget adresserbart XFRM-gränssnitt som man skulle kunna tilldela IP-adresser eller rutter.

För denna variant gäller dessutom:

  • Dynamic Routing tillåts under Administration > Device access för VPN-zonen.
  • XFRM-transitnätet anges som OSPF Network.
  • Nyttotrafiken behöver lämpliga IPv4- respektive IPv6-brandväggsregler för VPN-zonen.
  • Hello, Dead, Authentication och MTU måste stämma överens med motparten.
  • Den visade OSPF-nätverkstypen jämförs på båda sidor. En avvikelse kan förhindra uppbyggnaden av grannskapet och måste klargöras i designen av båda ändpunkterna.

En grön IPsec-tunnel och en OSPF Neighbor i Full är separata kontrollpunkter. Först den inlärda routen och ett verkligt paketflöde bekräftar hela konfigurationen.

Den officiella HA-hjälpen garanterar inte att OSPF-adjacency-statusen överförs. I ett HA-kluster ingår därför en planerad failover i acceptanstestet av den konkreta topologin. Därefter kontrolleras på den aktiva noden om grannar, rutter samt ospfd.log och zebra.log åter visar det förväntade tillståndet.

OSPFv3 för IPv6

Under Routing > OSPFv3 konfigureras IPv6-routing oberoende av OSPFv2. Router-ID förblir ett unikt värde i IPv4-notation. SFOS visar 0 för Default metric, men använder det icke ändringsbara värdet 20; ABR type är låst till Standard. Auto-cost reference-bandwidth är som standard inställt på 100000 Mbps. För Default-information originate finns, precis som för OSPFv2, alternativen Never, Regular och Always; i WebAdmin kan anslutna IPv6-rutter och BGP-IPv6-rutter redistribueras.

Till skillnad från OSPFv2 registreras inte ett nätverk först. Under Interfaces väljer man det IPv6-kompatibla gränssnittet och tilldelar det ett område. För en enkel uppsättning används även här området 0.0.0.0. Hello och Dead måste matcha på segmentet; Cost, Retransmit, Transmit Delay och Router Priority ställs in enligt den egna topologin. SFOS stöder endast en OSPFv3-instans per gränssnitt. Instance ID är konfigurerbart; dess standardvärde är 0.

Ytterligare OSPFv3-Areas kan skapas som Stub, Stub no-summary, NSSA eller NSSA no-summary. Varianterna skiljer sig åt genom vilka externa och sammanfattande LSA:er de bär; en NSSA kan dessutom vidarebefordra typ 7-LSA:er från sin egen redistribution till ABR. Dessa Area-typer hör hemma i en samordnad multi-area-design och inte i ett improviserat reparationsförsök.

Sophos Firewall stöder för närvarande inte Authentication för OSPFv3. Utbytet bör därför endast ske över betrodda eller redan skyddade länkar. En befintlig OSPFv2-konfiguration annonserar inga IPv6-nät, och IPv6-nyttotrafik behöver egna IPv6-brandväggsregler.

Redistribute connected redistribuerar även alla direkt anslutna IPv6-nät till OSPFv3 och bör därför inte aktiveras generellt. Enligt Sophos injiceras endast det dynamiska undernätet vid fjärråtkomst SSL VPN, inte det statiska. SFOS 22-hjälpen anger för det statiska undernätet ett “OSPF-nätverk”, även om OSPFv3 i WebAdmin konfigureras via gränssnitt istället för via en nätverkslista. Ur denna motsägelse kan ingen säker process härledas; annonseringen av ett statiskt IPv6-SSL-VPN-prefix måste klargöras med Sophos för den installerade versionen.

Verifieringen sker under Routing > Information > OSPFv3. Vid fel ger ospf6d.log protokollspecifikt sammanhang.

Återställ ändringen säkert

Innan OSPF tas bort måste det finnas en alternativ väg eller ett planerat underhållsfönster för varje inlärt målnätverk. I exemplet tas först LAN-nätverksposten bort, därefter transitnätverket och slutligen deaktiveras Dynamic Routing för transitzonen. Om istället LAN redistribueras, tas denna redistribution först bort. Därefter kontrolleras route lookup, routingtabellen och managementåtkomst igen.

Om endast ett felaktigt Cost, Timer eller filter återställs bör bara denna enda inställning ändras. Då förblir det tydligt om OSPF-grannrelationen, routeannonseringen eller först nyttotrafiken påverkades.