SFOS 22: redistribute kernel verdeelt geen IPsec-routes meer
Na een upgrade naar SFOS 22 kan de IPsec-tunnel nog steeds actief zijn en kan ook de OSPF- of BGP-neighbor gezond lijken. Toch ontbreken op de naburige routers plotseling de netwerken achter een policy-based IPsec-tunnel.
De typische oorzaak is redistribute kernel: Tot en met SFOS 21.5 konden de policy-based VPN-routes die voor deze workflow werden gebruikt, uit de kernelroutingtabel worden overgenomen. Met SFOS 22.0 GA verwerkt de firewall deze routes intern in de VPN-backend. redistribute kernel vindt ze daarom niet meer.
⚠️ Maak geen statische dummy-, null- of blackhole-route aan enkel om het prefix opnieuw in OSPF of BGP te laten verschijnen. Afhankelijk van de Route Precedence kan zo’n route zelf het datapad overnemen en productieverkeer buiten de tunnel om leiden of verwerpen.
Kort antwoord: wat nu te doen
Als een eerder aangekondigd VPN-netwerk na de upgrade ontbreekt, wordt eerst gecontroleerd of alle volgende punten van toepassing zijn:
- De firewall is bijgewerkt van SFOS 21.5 of ouder naar SFOS 22.
- De betrokken tunnel is policy-based.
- OSPF of BGP nam de VPN-netwerken tot nu toe over via
redistribute kernel. - De neighbor blijft Full respectievelijk Established, maar het verwachte prefix ontbreekt aan de ontvangende kant.
Als dit het geval is, vormt een nieuwe ipsec_route-vermelding geen oplossing: Ook deze maakt onder SFOS 22 geen gewone kernelroute aan. Voor een duurzaam en inzichtelijk ontwerp wordt route-based Any-to-Any-IPsec met geadresseerde XFRM-interfaces en een expliciete OSPF- of BGP-configuratie aanbevolen.
De SFOS 22-upgradecheck helpt bij de voorbereiding. De eigenlijke tunnelconfiguratie staat in Site-to-Site IPsec VPN instellen.
Waarom de route na de upgrade ontbreekt
Een kernelroute is een vermelding in de normale routingtabel van het besturingssysteem. Routingdiensten kunnen zulke vermeldingen als bron overnemen en ze bijvoorbeeld met redistribute kernel aan neighbors doorgeven.
SFOS 22 behandelt policy-based IPsec anders: Het pakketpad wordt bepaald door een interne backendlookup met markeringen, zones en flags. De tunnel kan daardoor correct doorsturen, hoewel het bijbehorende VPN-netwerk niet als gewone kernelroute verschijnt.
Dit verklaart het schijnbaar tegenstrijdige foutbeeld:
- De IPsec-tunnel is actief.
- OSPF staat op Full of BGP op Established.
- Rechtstreeks verkeer door de tunnel kan nog steeds werken.
- Het externe VPN-prefix wordt echter niet meer vanuit de kernelroutingtabel in OSPF of BGP overgenomen.
De wijziging betreft niet OSPF of BGP in het algemeen. Ze betreft alleen een ontwerp dat policy-based IPsec-routes als kernelroutes veronderstelde.
De afhankelijkheid vóór de upgrade herkennen
Een bestaande omgeving moet vóór de upgrade niet alleen op een groene tunnel worden gecontroleerd. Doorslaggevend is waar OSPF of BGP het aan te kondigen prefix vandaan haalt.
Als voorbeeld wordt het externe VPN-netwerk 10.60.0.0/16 gebruikt. Dit is een omgevingswaarde en wordt vervangen door het netwerk dat daadwerkelijk wordt aangekondigd.
Firewall- en VPN-status vastleggen
In 4. Device Console worden eerst Route Precedence en handmatige IPsec-routes gedocumenteerd:
system route_precedence show
system ipsec_route show
De uitvoer beantwoordt twee verschillende vragen: Route Precedence toont de globale volgorde van de routeklassen. system ipsec_route show toont handmatige toewijzingen aan policy-based tunnels. Geen van beide opdrachten bewijst op zichzelf dat OSPF of BGP het prefix daadwerkelijk aankondigt.
Onder SFOS 21.5 kan in de Advanced Shell bovendien worden vastgelegd of het voorbeeldnetwerk voorkomt in de routingtabel die voor policy-based IPsec wordt gebruikt:
ip route show table 220 | grep '10.60.0.0/16'
De opdracht is alleen-lezen; het zoekprefix wordt aangepast aan het echte netwerk. Onder SFOS 22 is een ontbrekend resultaat voor policy-based IPsec te verwachten en vormt dit geen bewijs dat de tunnel zelf defect is.
OSPF of BGP afzonderlijk documenteren
In de betreffende routing-CLI wordt de actieve configuratie vastgelegd. Voor OSPF helpen daarnaast deze alleen-lezen opdrachten:
show running-config
show ip ospf neighbor
show ip ospf route
Voor BGP wordt de configuratie samen met de bekende BGP-prefixen vastgelegd:
show running-config
show ip bgp
Op de ontvangende router wordt eveneens vastgelegd of 10.60.0.0/16 wordt geleerd en welke Next Hop wordt gebruikt. Alleen zo kan na de upgrade worden vastgesteld of de tunnel, de routingneighbor of de prefixaankondiging is getroffen.
De volledige controlepaden worden uitgelegd in OSPF configureren en controleren en BGP configureren en controleren.
Het veilige doelontwerp kiezen
Dynamische routing via een XFRM-interface
Als externe netwerken dynamisch moeten worden geleerd of verder verspreid, is route-based Any-to-Any-IPsec het inzichtelijke doelontwerp:
- Beide tunneluiteinden gebruiken Route-based (Tunnel interface) met Any-to-Any-subnetten.
- De automatisch aangemaakte XFRM-interfaces krijgen unieke IP-adressen uit een eigen transitnetwerk.
- OSPF of BGP bouwt de neighborship op via deze transitadressen.
- De bedoelde netwerken worden expliciet in het routingprotocol aangekondigd of via een nauw gefilterde, werkelijk bestaande route geredistribueerd.
- Firewallregels staan het gebruikersverkeer tussen de LAN- en VPN-zone toe.
Hierdoor is de route geen bijproduct meer van de policy-based tunnel. XFRM, het routingprotocol en de aangekondigde prefixen kunnen afzonderlijk worden gecontroleerd en gewijzigd.
De omzetting wordt voorbereid in een onderhoudsvenster. Policy-based en route-based verbindingen met dezelfde prefixen mogen niet ongecontroleerd tegelijk actief zijn, omdat overlappende selectors en routes de test kunnen vertekenen.
Policy-based IPsec voorlopig behouden
Niet elke bestaande verbinding hoeft onmiddellijk te worden gemigreerd. Als de tunnel policy-based blijft, heeft de prefixaankondiging echter een bewust gepland, topologiespecifiek ontwerp nodig. De publiek gedocumenteerde SFOS 22-procedures bevatten geen algemene vervangende opdracht die backend-VPN-routes opnieuw als kernelroutes beschikbaar stelt voor OSPF of BGP.
redistribute static is alleen zinvol als de statische route zelf het werkelijk gewenste datapad is en met een ACL respectievelijk Route Map tot de bedoelde prefixen wordt beperkt. Een aanvullende route die enkel als bron voor redistribution dient, is geen veilige standaardoplossing.
Ook een wijziging van system route_precedence herstelt de ontbrekende kernelroute niet. De volgorde geldt globaal en kan andere statische, SD-WAN- en VPN-paden wijzigen. Als deze wegens een concreet routingconflict moet worden aangepast, legt Route Precedence veilig wijzigen de controle en het herstelpad uit.
De omzetting en werking goedkeuren
Een geslaagde test bestaat uit meerdere afzonderlijke niveaus:
- De XFRM-interface is actief en geadresseerd met het geplande transit-IP.
- OSPF bereikt Full of BGP Established.
- Alleen de bedoelde prefixen worden aangekondigd en op de tegenpartij geleerd.
- Route Lookup en Routing Information tonen voor een concreet doel het geplande pad.
- Log Viewer en Packet Capture tonen de verwachte firewallregel en de in- en uitgaande interface.
- Een echte dienst werkt in beide richtingen en gebruikt het juiste retourpad.
- Bij redundante WAN-verbindingen of HA wordt een gecontroleerde failover afzonderlijk getest.
Route Lookup controleert het lokale doorstuurpad, maar niet de prefixaankondiging aan een OSPF- of BGP-neighbor. Doorslaggevend zijn daarom Route Lookup, het ontvangen prefix, de routingneighbor, de pakketstroom en een echte toepassingstest samen.
Fouten systematisch afbakenen
Neighbor is opgebouwd, maar het VPN-prefix ontbreekt
Controleer eerst in show running-config of het netwerk tot nu toe alleen via redistribute kernel in OSPF of BGP terechtkwam. Controleer daarna het tunneltype en de SFOS-build. Als policy-based IPsec onder SFOS 22 van toepassing is, ligt het ontbreken van de kernelvermelding voor de hand; de neighbor hoeft daarvoor niet uit te vallen.
Het prefix wordt aangekondigd, maar het verkeer werkt niet
Dan is de ontbrekende kernelredistribution niet langer de rechtstreekse oorzaak. Controleer Route Lookup, firewallregels, NAT, retourpad, XFRM-adres en Traffic Selector afzonderlijk. Een aangekondigd prefix bewijst niet dat het heen- en retourpad correct zijn.
ipsec_route is aanwezig, maar OSPF of BGP neemt het netwerk niet over
Dit is onder SFOS 22 te verwachten. system ipsec_route show toont de geconfigureerde handmatige tunneltoewijzing, maar bevestigt noch een gewone kernelroute, noch een werkend datapad. Een extra ipsec_route voor hetzelfde netwerk herstelt redistribute kernel daarom niet. De precieze duiding en veilige Add-/Delete-syntaxis staan in IPsec-route aanmaken op Sophos Firewall.
Na een statische vervangingsroute valt het verkeer uit
De nieuw aangemaakte route kan het werkelijke VPN-pad overschrijven. Draai de wijziging terug aan de hand van de eerder vastgelegde opdracht en het onderhoudsplan, controleer Route Precedence en herhaal de laatste werkende test. Wijzig niet tegelijkertijd nog andere routing-, NAT- en VPN-instellingen.
Veilig terugdraaien
Vóór de migratie worden de policy-based verbinding, routingconfiguratie, Route Precedence, regels en ontvangen prefixen vastgelegd. Bij een rollback wordt alleen het eerder gewijzigde pad teruggedraaid:
- nieuwe OSPF-/BGP-aankondigingen en filters gecontroleerd verwijderen,
- XFRM-routes alleen verwijderen als het oude datapad opnieuw actief en gecontroleerd is,
- de oorspronkelijke Route Precedence exact herstellen als deze is gewijzigd,
- kunstmatige hulproutes volledig verwijderen,
- tunnel, neighborstatus, prefixen en echt verkeer opnieuw controleren.
Een rollback is pas voltooid wanneer de beheerstoegang en productieverbindingen opnieuw via het gedocumenteerde oorspronkelijke pad werken.
FAQ
Herstelt ipsec_route de ontbrekende kernelroute onder SFOS 22?
ipsec_route kan nog steeds nodig zijn bij onderbouwde policy-based NAT-uitzonderingen, maar wordt onder SFOS 22 intern verwerkt en vormt geen bron voor redistribute kernel.