SFOS 22: policybaserade IPsec-rutter i OSPF och BGP

Efter en uppgradering till SFOS 22 kan en policybaserad IPsec-tunnel fortsätta fungera samtidigt som ett VPN-prefix som tidigare annonserades via OSPF eller BGP saknas. Routningsgrannrelationen kan också förbli Full eller Established.

Sophos dokumenterar att SFOS 22 inte längre skapar de tidigare VPN-rutterna för policybaserad IPsec och inte längre använder ipsec0 i sändvägen. Om ett OSPF- eller BGP-prefix försvinner samtidigt ska kopplingen till omdistribution behandlas som en observerad operativ slutsats: KBA:n beskriver inte redistribute kernel, OSPF eller BGP. Ett saknat prefix betyder därför inte automatiskt att tunneln har slutat fungera.

⚠️ Skapa inte en dummy-, null-, blackhole- eller annan hjälprutt enbart för annonsering. Den kan ändra datavägen. Innan produktionen ändras ska den specifika designen klargöras med Sophos Support eller i ett planerat design- och underhållsfönster.

Snabb diagnos

Undersök detta uppgraderingsmönster i SFOS 22 när alla punkter stämmer:

1. Problemet började med uppgraderingen till SFOS 22.
2. Tunneln är policy-based.
3. OSPF eller BGP använde tidigare redistribute kernel för VPN-prefixet.
4. Tunneln och grannen är aktiva, men prefixet saknas på den mottagande routern.

För en route-based tunnel eller en inaktiv grannrelation ska motsvarande tunnel- eller routningsfel undersökas i stället.

Varför vanliga routningsvyer inte räcker

KBA:n anger att SFOS 22 inte längre skapar de tidigare policybaserade VPN-rutterna. Separat beskrivs ipsec_route-rutter som tillhörande prioritetsklassen vpn i SFOS 22 och som frånvarande i routningstabellen. Den anger inte hur OSPF- eller BGP-omdistribution hanterar något av fallen.

Bedöm tre tillstånd separat:

• VPN: Är IPsec-anslutningen aktiv och flödar trafik?
• Routningsprotokoll: Är OSPF- eller BGP-grannen aktiv?
• Annonsering: Lär sig den fjärranslutna routern exakt det förväntade prefixet?

En grön VPN-status bevisar inte att rutten annonseras. Omvänt bevisar en saknad rutt i den vanliga routningsvyn inte att en policybaserad tunnel är trasig i SFOS 22.

Identifiera VPN-flödet i conntrack-utdata

SFOS 22 använder inte längre ipsec0 i sändningsvägen och skapar inte de tidigare VPN-rutterna. Använd i stället conntrack-värdena för den specifika anslutning som testas: trafik mot VPN har mark=0x0, outzone=5 och flagga 74; trafik från VPN har mark=0x0, inzone=5 och flagga 75. Zon 5 är VPN-zonen och flaggan kan visas tillsammans med andra värden i flagvalues.

Dessa värden identifierar riktningen för en observerad VPN-anslutning, men bevisar inte OSPF- eller BGP-annonsering. I SFOS 22 är det också förväntat att Packet Capture inte visar ipsec0 i sändningsvägen och att Route Lookup under Diagnostics > Tools kan visa WAN-interfacet. Korrelera ett tydligt avgränsat testflöde i conntrack och Packet Capture i stället för att betrakta en enskild vy som ett fel.

Kontrollera säkert och skrivskyddat

Dokumentera brandväggs- och VPN-uppgifter

1. Dokumentera SFOS-version och build.
2. Under Site-to-site VPN > IPsec dokumenteras anslutningsstatus, tunneltyp och konfigurerade lokala och fjärranslutna subnät.
3. Under Routing > Routing information körs Route Lookup för ett specifikt mål, med hänsyn till visningsbegränsningen för policybaserade VPN- och ipsec_route-rutter.
4. Visa den dokumenterade konfigurationen i 4. Device Console:

system route_precedence show
system ipsec_route show

Dessa kommandon gör inga ändringar. Route Precedence visar ruttklassernas globala ordning; system ipsec_route show listar manuella IPsec-rutter. Inget av kommandona bevisar ensamt att OSPF eller BGP annonserar ett prefix.

Med skrivskyddad åtkomst till Advanced Shell dokumenteras även de rutt- och anslutningsvyer som KBA:n använder:

route -n
ip route show
conntrack -L

Begränsa conntrack-granskningen till testets ändpunkter och tidsfönster. Utdata kan bekräfta att den gamla rutten eller ipsec0 saknas och identifiera det testade VPN-flödet; de bevisar inte omdistribution eller annonsering.

Kontrollera prioriteten för ipsec_route före en ändring

I SFOS 21.5 tillhörde en rutt som lagts till med ipsec_route klassen static; i SFOS 22 tillhör den klassen vpn. Med static sdwan_policyroute vpn kan en SD-WAN-policyrutt som matchar VPN-selektorerna därför ta över trafiken efter uppgraderingen. Om den granskade designen kräver att VPN prioriteras dokumenterar Sophos static vpn sdwan_policyroute som målordning och system route_precedence set static vpn sdwan_policyroute som det ändrande kommandot.

Kör inte kommandot enbart utifrån denna diagnos: Route Precedence är global och kan påverka annan trafik. Dokumentera först system route_precedence show, matchande SD-WAN-policyer, fram- och returvägar samt en återställningspunkt. Använd sedan Ändra Route Precedence säkert för förkontroller, kontrollerad ändring, validering och rollback.

Kontrollera OSPF eller BGP separat

Använd de visningskommandon som Sophos dokumenterar i lämpligt routnings-CLI:

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

Kör endast kommandona för protokollet som används. Dokumentera även prefix och Next Hop på den mottagande routern. Se Konfigurera och verifiera OSPF och Konfigurera och kontrollera BGP för fullständiga kontroller.

Fatta designbeslutet

Dynamisk routning krävs

För dynamisk routning dokumenterar Sophos route-based Any-to-Any-IPsec. Då skapas XFRM-interface som kan adresseras och användas för OSPF eller BGP. Grannrelationen och annonserade prefix blir då uttryckliga designelement i stället för bieffekter av en policybaserad VPN-rutt.

Detta är en designriktning, inte en universell migreringsprocedur. Adressering, routningsfilter, brandväggsregler, NAT, returväg, redundans och motpart beror på topologin. Planera ändringen med Sophos Support eller i ett design- och underhållsfönster innan produktionen ändras. Grundläggande information om tunneln finns i Konfigurera Site-to-Site IPsec VPN.

Policybaserad IPsec måste behållas

KBA:n dokumenterar inte OSPF- eller BGP-omdistribution och inte heller något kommando som gör den tidigare VPN-rutten tillgänglig för något av protokollen. Ytterligare en ipsec_route, ändrad Route Precedence eller en konstgjord statisk rutt ersätter inte en granskad routningsdesign.

Om policybaserad IPsec måste behållas ska det topologispecifika annonseringsflödet utformas med Sophos Support. Uppgraderingskontrollen för SFOS 22 och Skapa IPsec-rutt på Sophos Firewall ger användbar bakgrund.

Före en produktionsändring

Tillhandahåll minst följande information inför ett support- eller designmöte:

• SFOS-version och build, tunneltyp och HA-status;
• anonymiserade lokala och fjärranslutna prefix;
• tidigare OSPF- eller BGP-konfiguration och grannstatus;
• förväntade och mottagna prefix med deras Next Hop;
• relevanta resultat från Route Lookup, Log Viewer och Packet Capture;
• krav på returväg, NAT, failover och underhållsfönster.

Ändra inte VPN, routning, NAT och brandväggsregler samtidigt utan definierade test- och återställningspunkter. Efter att designen har godkänts kontrolleras varje planerat lager separat: tunnel/XFRM, granne, annonserade prefix, väg fram och tillbaka samt en verklig tjänst.

Skilj mellan symptomen

Grannen är aktiv, prefixet saknas

Jämför tunneltyp, SFOS-build och show running-config. Den saknade tidigare VPN-rutten, en aktiv grannrelation och ett prefix som inte tas emot är separata observationer. Kontrollera i routningskonfigurationen och på den mottagande routern om omdistributionen var beroende av rutten.

Prefixet finns, trafiken störs

Den saknade redistributionen är då inte den omedelbara orsaken. Undersök Route Lookup, regler, NAT och returvägen separat.

ipsec_route finns, prefixet saknas

system ipsec_route show bekräftar endast den manuella tilldelningen. Kommandot bekräftar varken en vanlig kernelrutt eller en OSPF- eller BGP-annonsering.

Ingen universell rollbacksekvens

Utan den specifika topologin finns ingen säker sekvens för samexistens, övergång, tillbakadragande eller failover. Dessa steg hör hemma i ändringsplanen som har avtalats med Sophos Support; artikeln ger avsiktligt ingen kommandosekvens.

FAQ