SFOS 22: redistribute kernel distribuerar inte längre IPsec-rutter

Efter en uppgradering till SFOS 22 kan IPsec-tunneln fortfarande vara aktiv och OSPF- eller BGP-grannen se frisk ut. Ändå saknas plötsligt näten bakom en policybaserad IPsec-tunnel på grannroutrarna.

Den typiska orsaken är redistribute kernel: Till och med SFOS 21.5 kunde de policybaserade VPN-rutter som användes i detta arbetsflöde hämtas från kernelns routningstabell. Från och med SFOS 22.0 GA behandlar brandväggen dessa rutter internt i VPN-backend. Därför hittar redistribute kernel dem inte längre.

⚠️ Skapa inte en statisk dummy-, null- eller blackhole-rutt bara för att prefixet ska visas i OSPF eller BGP igen. Beroende på Route Precedence kan en sådan rutt själv ta över datavägen och leda produktionstrafiken förbi tunneln eller kassera den.

Kort svar: vad som ska göras nu

Om ett tidigare annonserat VPN-nät saknas efter uppgraderingen kontrolleras först om alla följande punkter stämmer:

Brandväggen har uppgraderats från SFOS 21.5 eller äldre till SFOS 22.
Den berörda tunneln är policy-based.
OSPF eller BGP hämtade tidigare VPN-näten via redistribute kernel.
Grannen förblir Full respektive Established, men det förväntade prefixet saknas på den mottagande sidan.

Om detta stämmer är en ny ipsec_route-post ingen lösning: Under SFOS 22 skapar inte heller den en vanlig kernelrutt. För en långsiktigt tydlig design rekommenderas route-based Any-to-Any-IPsec med adresserade XFRM-interface och en uttrycklig OSPF- eller BGP-konfiguration.

Uppgraderingskontrollen för SFOS 22 hjälper till med förberedelserna. Själva tunnelkonfigurationen beskrivs i Konfigurera Site-to-Site IPsec VPN.

Varför rutten saknas efter uppgraderingen

En kernelrutt är en post i operativsystemets vanliga routningstabell. Routningstjänster kan hämta sådana poster som källa och exempelvis distribuera dem till grannar med redistribute kernel.

SFOS 22 hanterar policybaserad IPsec på ett annat sätt: Paketvägen bestäms genom en intern backend-sökning med markeringar, zoner och flaggor. Tunneln kan därför vidarebefordra korrekt trots att det tillhörande VPN-nätet inte visas som en vanlig kernelrutt.

Det förklarar den till synes motsägelsefulla felbilden:

IPsec-tunneln är aktiv.
OSPF har status Full eller BGP Established.
Direkt trafik genom tunneln kan fortfarande fungera.
Det fjärranslutna VPN-prefixet hämtas dock inte längre från kernelns routningstabell till OSPF eller BGP.

Ändringen berör inte OSPF eller BGP generellt. Den berör endast en design som förutsatte att policybaserade IPsec-rutter var kernelrutter.

Identifiera beroendet före uppgraderingen

Före uppgraderingen räcker det inte att kontrollera att en befintlig tunnel är grön. Det avgörande är varifrån OSPF eller BGP hämtar det prefix som ska annonseras.

Det fjärranslutna VPN-nätet 10.60.0.0/16 används som exempel. Det är ett miljövärde som ska ersättas med det nät som faktiskt annonseras.

Dokumentera brandväggens och VPN-tunnelns status

I 4. Device Console dokumenteras först Route Precedence och manuella IPsec-rutter:

system route_precedence show
system ipsec_route show

Utdata besvarar två olika frågor: Route Precedence visar routningsklassernas globala ordning. system ipsec_route show visar manuella tilldelningar till policybaserade tunnlar. Inget av kommandona bevisar ensamt att OSPF eller BGP faktiskt annonserar prefixet.

Under SFOS 21.5 kan man dessutom i Advanced Shell dokumentera om exempelnätet visas i den routningstabell som används för policybaserad IPsec:

ip route show table 220 | grep '10.60.0.0/16'

Kommandot är skrivskyddat och sökprefixet ska anpassas till det verkliga nätet. Under SFOS 22 är det förväntat att policybaserad IPsec inte ger någon träff, och det bevisar inte att själva tunneln är trasig.

Dokumentera OSPF eller BGP separat

I respektive routnings-CLI sparas den aktiva konfigurationen. För OSPF är även följande skrivskyddade kommandon användbara:

show running-config
show ip ospf neighbor
show ip ospf route

För BGP dokumenteras konfigurationen tillsammans med de kända BGP-prefixen:

show running-config
show ip bgp

På den mottagande routern dokumenteras också om 10.60.0.0/16 lärs in och vilken Next Hop som används. Först då går det efter uppgraderingen att avgöra om tunneln, routningsgrannen eller prefixannonseringen berörs.

De fullständiga kontrollvägarna beskrivs i Konfigurera och verifiera OSPF och Konfigurera och kontrollera BGP.

Välj en säker måldesign

Dynamisk routning via ett XFRM-interface

Om fjärrnät ska läras in eller distribueras vidare dynamiskt är route-based Any-to-Any-IPsec den tydliga måldesignen:

Båda tunneländarna använder Route-based (Tunnel interface) med Any-to-Any-subnät.
De automatiskt skapade XFRM-interfacen får unika IP-adresser från ett separat transitnät.
OSPF eller BGP upprättar grannrelationen via dessa transitadresser.
De avsedda näten annonseras uttryckligen i routningsprotokollet eller distribueras via en noggrant filtrerad rutt som faktiskt finns.
Brandväggsregler tillåter nyttotrafiken mellan LAN- och VPN-zonen.

Då är rutten inte längre en biprodukt av den policybaserade tunneln. XFRM, routningsprotokollet och annonserade prefix kan kontrolleras och ändras var för sig.

Migreringen förbereds i ett underhållsfönster. Policybaserade och route-based anslutningar med samma prefix får inte vara aktiva samtidigt utan kontroll, eftersom överlappande selektorer och rutter kan ge missvisande testresultat.

Behåll policybaserad IPsec tills vidare

Alla befintliga anslutningar behöver inte migreras omedelbart. Om tunneln förblir policybaserad behöver prefixannonseringen dock en medvetet planerad, topologispecifik design. De offentligt dokumenterade förfarandena för SFOS 22 innehåller inget generellt ersättningskommando som åter gör VPN-rutter i backend tillgängliga som kernelrutter för OSPF eller BGP.

redistribute static är bara lämpligt när den statiska rutten i sig är den verkliga avsedda datavägen och begränsas till de avsedda prefixen med ACL eller Route Map. En extra rutt som endast används som källa för redistribution är ingen säker standardlösning.

Inte heller en ändring av system route_precedence återställer den saknade kernelrutten. Ordningen gäller globalt och kan ändra andra statiska, SD-WAN- och VPN-vägar. Om den måste anpassas på grund av en konkret routningskonflikt beskriver Ändra Route Precedence säkert kontrollen och återställningsvägen.

Verifiera migrering och drift

Ett lyckat test består av flera separata nivåer:

XFRM-interfacet är aktivt och adresserat med den planerade transit-IP-adressen.
OSPF når Full eller BGP Established.
Endast de avsedda prefixen annonseras och lärs in hos motparten.
Route Lookup och Routing Information visar den planerade vägen till ett konkret mål.
Log Viewer och Packet Capture visar förväntad brandväggsregel samt inkommande och utgående interface.
En verklig tjänst fungerar i båda riktningarna och använder rätt returväg.
Vid redundanta WAN-anslutningar eller HA testas en kontrollerad failover separat.

Route Lookup kontrollerar den lokala vidarebefordringsvägen, men inte prefixannonseringen till en OSPF- eller BGP-granne. Därför är Route Lookup, mottaget prefix, routningsgranne, paketflöde och ett verkligt applikationstest tillsammans avgörande.

Avgränsa felet systematiskt

Grannen är upprättad, men VPN-prefixet saknas

Kontrollera först i show running-config om nätet tidigare endast nådde OSPF eller BGP via redistribute kernel. Fastställ därefter tunneltyp och SFOS-build. Om det gäller policybaserad IPsec under SFOS 22 är den saknade kernelposten den närmast till hands liggande förklaringen. Grannrelationen behöver inte gå ned för det.

Prefixet annonseras, men trafiken fungerar inte

Då är avsaknaden av kernelredistribution inte längre den direkta orsaken. Kontrollera Route Lookup, brandväggsregler, NAT, returväg, XFRM-adress och Traffic Selector separat. Ett annonserat prefix bevisar inte att vägen dit och tillbaka är korrekt.

ipsec_route finns, men OSPF eller BGP hämtar inte nätet

Detta är förväntat under SFOS 22. system ipsec_route show visar den konfigurerade manuella tunneltilldelningen, men bekräftar varken en vanlig kernelrutt eller en fungerande dataväg. Ytterligare en ipsec_route för samma nät återställer därför inte redistribute kernel. Den exakta klassificeringen och säker Add-/Delete-syntax beskrivs i Skapa IPsec-rutt på Sophos Firewall.

Trafiken slutar fungera efter en statisk ersättningsrutt

Den nyskapade rutten kan åsidosätta den verkliga VPN-vägen. Återställ ändringen med hjälp av det tidigare dokumenterade kommandot och underhållsplanen, kontrollera Route Precedence och upprepa det senaste fungerande testet. Ändra inte fler routnings-, NAT- och VPN-inställningar samtidigt.

Återställ säkert

Före migreringen dokumenteras den policybaserade anslutningen, routningskonfigurationen, Route Precedence, regler och mottagna prefix. Vid rollback återställs endast den väg som tidigare ändrades:

ta bort nya OSPF-/BGP-annonseringar och filter på ett kontrollerat sätt,
ta endast bort XFRM-rutter när den gamla datavägen åter är aktiv och verifierad,
återställ ursprunglig Route Precedence exakt om den har ändrats,
ta bort artificiella hjälprutter helt,
kontrollera tunnel, grannstatus, prefix och verklig trafik igen.

En rollback är inte slutförd förrän administrationsåtkomsten och produktionsanslutningarna åter fungerar via den dokumenterade ursprungliga vägen.

FAQ

Återställer ipsec_route den saknade kernelrutten under SFOS 22?

Nej. ipsec_route kan fortfarande behövas i motiverade specialfall med policybaserad NAT, men behandlas internt under SFOS 22 och ger ingen källa för redistribute kernel.

Går det att helt enkelt aktivera redistribute static i stället?

Endast om den statiska rutten i sig är den korrekta datavägen och redistribution filtreras noggrant. En dummy-, null- eller blackhole-rutt som bara används för annonseringen är ingen säker generell ersättning.