Ändra Route Precedence säkert på Sophos Firewall

Route Precedence avgör om Sophos Firewall först utvärderar Static Routes, SD-WAN Policy Routes eller VPN-rutter. Inställningen gäller globalt och kan omedelbart påverka både produktionstrafik och administrativ åtkomst.

Kort svar

Standardordningen är:

1. static
2. sdwan_policyroute
3. vpn

Den passar i många miljöer eftersom direktanslutna nätverk och statiska rutter då inte åsidosätts av en bred SD-WAN-rutt. Ordningen bör bara ändras när flera rutttyper konkurrerar om samma destination i det konkreta paketflödet.

Före varje ändring ska man dokumentera den aktuella ordningen, säkerställa en oberoende hanteringsåtkomst, kontrollera berörda rutter och förbereda den exakta återställningen. En vanlig SD-WAN-rutt beskrivs i Konfigurera och testa en SD-WAN-rutt på Sophos Firewall.

Vilken ordning passar?

Standard och versionsskillnad

Standardordningen är identisk i SFOS 21.5 och 22.0. Däremot har tilldelningen av ipsec_route ändrats:

• SFOS 21.5: static omfattar direktanslutna nätverk, ipsec_route, Unicast Routes, Dynamic Routes och SSL VPN. Automatiskt skapade policybaserade IPsec-rutter tillhör vpn.
• SFOS 22.0: static omfattar direktanslutna nätverk, Unicast Routes, Dynamic Routes och SSL VPN. vpn omfattar automatiskt skapade policybaserade IPsec-rutter och ipsec_route.

Detta är viktigt vid uppgraderingar: En rekommendation för ipsec_route i SFOS 21.5 får inte överföras oförändrad till SFOS 22.0. I SFOS 22.0 behandlar brandväggen policybaserade IPsec-rutter internt. Automatiskt skapade policybaserade VPN-rutter och rutter som definierats med ipsec_route syns inte i routingtabellen. ipsec_route krävs inte för systemgenererad trafik. En manuell IPsec-rutt är bara lämplig i rätt versionsberoende specialfall.

På migrerade brandväggar är det inte den dokumenterade standarden som gäller, utan den faktiska utmatningen. En migrering kan till exempel behålla sdwan_policyroute vpn static. Migrerade SD-WAN-rutter kan dessutom fortfarande vara bundna till ID-numret för den ursprungliga brandväggsregeln och försvinna när regeln tas bort.

Static först

static sdwan_policyroute vpn är oftast rätt utgångsläge för LAN, DMZ, VLAN, SSL VPN och vanliga SD-WAN-internetvägar. Direktanslutna nätverk behandlas då som statiska rutter.

Det skyddar interna destinationer mot alltför breda SD-WAN-rutter. Om sdwan_policyroute står före static och en SD-WAN-rutt till exempel använder destinationen Any, kan intern eller administrativ trafik oväntat skickas mot WAN-gatewayen.

SD-WAN först

sdwan_policyroute static vpn är lämpligt när Policy Routing medvetet ska ha företräde framför statiska rutter. Detta måste planeras utifrån konkreta källor, destinationer och tjänster. För Reply Packets och systemgenererad trafik gäller SD-WAN-rutter endast om motsvarande CLI-alternativ är aktiverade.

Kontrollera Sophos Firewall SD-WAN-routing för Reply Packets och System Traffic förklarar dessa två alternativ i detalj.

VPN först

vpn static sdwan_policyroute är ett riktat undantag, till exempel för dokumenterade L2TP-scenarier. Prioriteringen av vpn framför static gäller då endast trafik där den konkurrerande rutten leder till WAN-zonen. Den är ingen generell lösning för alla IPsec-tunnlar.

SSL VPN-anslutningar tillhör kategorin static, inte vpn. Ruttbaserad IPsec via XFRM-gränssnitt styrs av den konfigurerade statiska, dynamiska eller SD-WAN-rutten. Därför är XFRM-gränssnitt, rutt, SD-WAN-kriterier, NAT, brandväggsregel och returväg avgörande.

En global ändring är olämplig om endast ett enskilt destinationsnätverk dirigeras fel. Då är en mer specifik statisk rutt eller SD-WAN-rutt, VPN-konfigurationen eller en versionsanpassad ipsec_route oftast ett mer exakt verktyg.

Förbered ändringen säkert

Kommandona körs i Device Console, inte i Advanced Shell. Om åtkomsten ännu inte är konfigurerad hjälper Anslut till Sophos Firewall via SSH. SSH bör endast tillåtas från betrodda nätverk.

Förberedelser:

1. Säkerställ en oberoende reservväg till brandväggen och testa den aktivt före ändringen, till exempel lokal konsol, dedikerat hanteringsgränssnitt eller en bekräftad och opåverkad administrativ väg.
2. Notera källa, destination, tjänst, zon och berörda gränssnitt.
3. Kontrollera statiska rutter, SD-WAN Policy Routes, VPN-rutter och XFRM-gränssnitt.
4. Identifiera breda SD-WAN-rutter med Any samt migrerade regler.
5. Kontrollera NAT, brandväggsregeln och motpartens returväg.
6. Fastställ underhållsfönster, acceptanstest och återställning.

⚠️ Viktigt: Route Precedence gäller globalt. Ändra inte routing-, NAT-, brandväggs- och SD-WAN-regler samtidigt, eftersom effekten då inte kan kopplas till en enskild ändring på ett tillförlitligt sätt.

Visa och dokumentera den aktuella ordningen exakt:

system route_precedence show

Dokumentera hela utmatningen tillsammans med datum, anledning, berörda nätverk och förväntat beteende. Använd alla tre värden för att förbereda det exakta återställningskommandot före ändringen.

I WebAdmin visas den aktuella ordningen även här:

Routing > SD-WAN routes

Ordningen ändras via Device Console. Om SD-WAN är inblandat ska man i förväg även registrera status för systemgenererad trafik och Reply Packets:

show routing sd-wan-policy-route system-generate-traffic
show routing sd-wan-policy-route reply-packet

Dessa värden får inte oavsiktligt blandas ihop med effekten av Route Precedence. En särskilt kritisk kombination uppstår när sdwan_policyroute står före static, en matchande SD-WAN-rutt använder destinationen Any och SD-WAN är aktiverat för både systemgenererad trafik och Reply Packets. Då kan åtkomst till WebAdmin och SSH från det berörda interna subnätet gå förlorad, medan brandväggen eventuellt fortfarande kan nås från andra subnät.

Ändra Route Precedence

Syntaxen innehåller alltid alla tre värden:

system route_precedence set [sdwan_policyroute] [static] [vpn]

Ställ in standardordningen:

system route_precedence set static sdwan_policyroute vpn

Om denna ordning redan är aktiv ligger felet sannolikt i Route Lookup, SD-WAN-kriterier, VPN-konfiguration, NAT, brandväggsregel eller returväg.

⚠️ Före SD-WAN-First: Kontrollera om breda SD-WAN-rutter omfattar interna nätverk eller hanteringsåtkomsten. Kör kommandot endast med en förberedd reservväg.

Utvärdera SD-WAN Policy Routes först:

system route_precedence set sdwan_policyroute static vpn

⚠️ Före VPN-First: Använd endast denna ordning för ett bekräftat VPN-specialfall. Den löser inte en saknad rutt, felaktiga Traffic Selectors, NAT- eller returvägsproblem.

Utvärdera VPN-rutter först:

system route_precedence set vpn static sdwan_policyroute

Testa och återställ ändringen

Bekräfta först efter ändringen att den förväntade ordningen är aktiv:

system route_precedence show

Testa därefter det berörda paketflödet:

• Testa applikationen, en TCP-anslutning eller ping till destinationen.
• Filtrera Log Viewer efter källa, destination och brandväggsregel.
• Kör Packet Capture på inkommande och utgående gränssnitt.
• Kontrollera Route Lookup och den berörda SD-WAN-rutten.
• Kontrollera NAT och den översatta käll-IP-adressen.
• Bekräfta motpartens returväg.
• Testa WebAdmin och SSH från relevanta administratörsnätverk.

En grön VPN-status eller en befintlig rutt bevisar inte att paketflödet fungerar. Praktiska steg finns i Testa en Sophos Firewall-regel med Log Viewer och Packet Capture och Använd Packet Capture i Sophos Firewall WebAdmin.

Om flera platser eller routingvägar berörs ska man testa minst en klient per relevant nätverk, en serverdestination samt berörda Remote Access- eller VPN-vägar.

Vid återställning ställs endast den tidigare dokumenterade fullständiga utgångsordningen in. Den kan inte härledas enbart från det första värdet, eftersom sex kombinationer är möjliga. Använd det förberedda kommandot enligt detta mönster:

system route_precedence set <första värdet> <andra värdet> <tredje värdet>

Ersätt platshållarna med alla tre värden från den tidigare sparade utmatningen. Kontrollera sedan igen:

system route_precedence show

Upprepa därefter samma funktions-, routing- och hanteringstester. Om det ursprungliga felet återkommer efter återställningen var Route Precedence sannolikt inblandad. Om inget ändras ligger orsaken någon annanstans.

Vanliga fel

SD-WAN-rutten är för bred

En SD-WAN-rutt med stora nätverksområden eller destinationen Any kan omfatta mer trafik än planerat. Om SD-WAN står före Static kan interna destinationer och hanteringsåtkomst oväntat skickas till WAN-gatewayen. Reply Packets och systemgenererad trafik påverkas om motsvarande SD-WAN-alternativ är aktiverade.

VPN-status förväxlas med routing

En aktiv tunnel bekräftar endast förhandlingen. Den bevisar inte att routing, Traffic Selectors, brandväggsregler, NAT och returväg är korrekta. Vid ruttbaserad IPsec kontrolleras först XFRM-gränssnitt och rutt. Vid policybaserad IPsec kontrolleras dessutom den versionsberoende hanteringen av ipsec_route. Artikeln Felsök IPsec VPN på Sophos Firewall leder systematiskt genom analysen.

NAT förbises

Routing bestämmer paketets väg, medan NAT ändrar käll- eller destinationsadressen. Om rutten är korrekt men returvägen är felaktig är NAT eller returrutten ofta orsaken. Mer information finns i Förstå NAT på Sophos Firewall.

Flera ändringar görs samtidigt

Den som ändrar Route Precedence, SD-WAN, NAT, brandväggsregler och VPN-parametrar samtidigt kan inte längre skilja orsak från verkan. Bättre är: en ändring, fullständigt test, nästa ändring.

Checklista

• Aktuell Route Precedence dokumenterad.
• SFOS-version och tilldelning av ipsec_route beaktade.
• Berörda källor, destinationer, nätverk och tjänster noterade.
• Static, SD-WAN, VPN och XFRM kontrollerade.
• Direktanslutna nätverk och hanteringsvägar beaktade.
• Breda SD-WAN-rutter med Any identifierade.
• Status för System Traffic och Reply Packets registrerad.
• NAT, brandväggsregler och returväg kontrollerade.
• Oberoende hanteringsåtkomst och återställning förberedda.
• Ändringen genomförd separat.
• Applikation, Log Viewer, Packet Capture och hanteringsåtkomst testade.

Vanliga frågor