Byt Sophos Firewall Route Precedence säkert

Route Precedence i Sophos Firewall bestämmer i vilken ordning olika rutttyper beaktas vid val av rutt. Detta låter som en liten justering, men det kan omedelbart påverka produktiv trafik. Det är särskilt relevant när Statiska rutter, SD-WAN Policyrutter och VPN-rutter överlappar varandra.

Artikeln förklarar när en ändring är meningsfull, när du bör kontrollera andra orsaker först och hur du korrekt dokumenterar ändringen med Device Console, testar den och återställer den vid behov. Om du vill planera eller testa en normal SD-WAN-rutt först, passar Sophos Firewall Setup and Test SD-WAN Route.

När Route Precedence är viktigt

Route Precedence blir viktig när flera routingmekanismer teoretiskt sett passar samma destination. Brandväggen måste sedan bestämma vilken typ av routing som utvärderas först.

Typiska situationer:

• Ett internt målnätverk kan nås via en statisk väg och dessutom via en SD-WAN policyväg.
• En ruttbaserad IPsec VPN använder XFRM-gränssnitt och påverkas samtidigt av SD-WAN-regler.
• Ett policybaserat IPsec specialfodral fungerar med manuella IPsec-rutter.
• En äldre migrering har behållit SD-WAN-rutter eller en tidigare Route Precedence.
• Systemgenererad trafik eller svarspaket tar en oväntad väg efter en SD-WAN-ändring.
• Efter en uppgradering eller migrering av fast programvara beter sig befintliga rutter annorlunda än förväntat.

För IPsec specialfall är Route Precedence inte automatiskt den bästa lösningen. Ofta måste du först förstå om ett klassiskt routingproblem, en IPsec Route, en SD-WAN-regel, NAT eller en brandväggsregel är inblandad.

Krav

• Sophos Firewall i Gateway-läge.
• Tillgång till Device Console, till exempel via SSH.
• Aktuell dokumentation av påverkade statiska rutter, SD-WAN policy rutter och VPN anslutningar.
• Underhållsfönster eller åtminstone en reservväg när produktiv trafik kan påverkas.
• Tillgång till Log Viewer och vid behov Packet Capture.

Om konsolåtkomst inte är konfigurerad ännu, Anslut Sophos Firewall via SSH förklarar hur du kommer åt Device Console. SSH bör endast tillåtas från betrodda nätverk.

⚠️ Viktigt: En förändring av Route Precedence har en global effekt. Det är inte bara en enskild tunnel eller rutt som påverkas, utan ordningen på rutttyper på brandväggen. Därför bör du aldrig göra flera routing-, NAT- och SD-WAN-ändringar samtidigt.

Standardordning

Den aktuella dokumentationen beskriver följande standardordning:

1. Statisk
2. SD-WAN
3. VPN

Värdena i Device Console är:

• static
• sdwan_policyroute
• vpn

Viktigt: kategorin static är bredare än namnet antyder. Sophos räknar dit direktanslutna nätverk, rutter från ipsec_route, unicast-rutter, dynamiska rutter och SSL VPN-anslutningar. Det är särskilt relevant när fjärråtkomsttrafik, statiska rutter, dynamisk routing och SD-WAN-regler bedöms tillsammans.

Också viktigt: Direktanslutna nätverk behandlas som statiska rutter i detta sammanhang. Om sdwan_policyroute är framför static och en SD-WAN-rutt med en mycket bred destination som Any fungerar, kan intern trafik plötsligt gå mot WAN-gatewayen. Det är just därför static är den säkra utgångspunkten i många miljöer före sdwan_policyroute.

På migrerade firewalls bör den aktuella utmatningen kontrolleras extra noggrant. Sophos kan behålla Route Precedence från en tidigare version, och migrerade SD-WAN-rutter kan fortfarande vara kopplade till gamla firewallregler. I så fall är det inte standardvärdet i dagens dokumentation som avgör, utan vad system route_precedence show visar på den aktuella firewallen.

Vilken ordning är korrekt?

Det finns ingen rätt ordning för varje design. Route Precedence måste passa routingmodellen.

• Normal LAN, DMZ, VLAN, fjärråtkomst och SD-WAN Internetvägar: static sdwan_policyroute vpn Direktanslutna nätverk och statiska rutter bör inte åsidosättas av breda SD-WAN-rutter.
• Policybaserad IPsec överlappar statiska eller SD-WAN-rutter: vpn static sdwan_policyroute kan hjälpa i lämpliga VPN-routingfall. Om en statisk eller lokal rutt skickar trafik till en annan zon än WAN är en riktad ipsec_route ofta renare än en global precedence-ändring. Kontrollera sedan NAT, brandväggsregler och returväg.
• L2TP Remote Access eller andra dokumenterade VPN-specialfall: Sophos kräver vpn först i vissa scenarier. Det är ingen generell standard, utan en riktad avvikelse för ett verifierat användningsfall.
• Ruttbaserad IPsec eller WAN failover styrs avsiktligt via SD-WAN: Ordningen beror på designen, ofta med SD-WAN före en annan typ av routing. Testa XFRM-gränssnitt, SD-WAN-kriterier, gatewaystatus, NAT och Route Precedence tillsammans.
• MTA, specialrouting eller enskilda Sophos how-to-scenarier: Ordningen måste passa det testade scenariot. Kopiera inte blint från ett exempel; kontrollera alltid lokala nätverk och returrutter.

Om ett Sophos-exempel visar en annan ordning är det inte automatiskt en ny standard. Många exempel löser ett konkret, speciellt problem. Det som räknas för en produktiv brandvägg är vilka käll- och målnätverk som faktiskt konkurrerar.

Begränsning före ändring

Route Precedence bör inte vara den första reaktionen när ett målnätverk inte kan nås. Först bör du begränsa det påverkade paketflödet.

Kontrollera:

1. Vilken källa och destination berörs?
2. Vilken zon och vilket gränssnitt är inblandade?
3. Finns det en lämplig statisk väg?
4. Finns det en SD-WAN policyrutt som matchar bredare än planerat?
5. Finns det migrerade SD-WAN-rutter från en äldre SFOS-version?
6. Är en VPN-rutt eller ett XFRM-gränssnitt inblandat?
7. Gäller NAT eller MASQ?
8. Uppfylls den förväntade brandväggsregeln i Log Viewer?
9. Visar Packet Capture den förväntade in- och utmatningsvägen?

Sophos Firewall testregel med Log Viewer och Packet Capture och Sophos Firewall använder Packet Capture i WebAdmin hjälp för praktiskt exam. För NAT-frågor, Förstå NAT på Sophos Firewall passar.

Visa aktuell Route Precedence

Kommandona exekveras i Device Console, inte i Advanced Shell.

Visa aktuell ordning:

system route_precedence show

Utgången bör dokumenteras före eventuella ändringar. Det är bäst att också notera datum, orsak, påverkade nätverk och förväntat beteende. Om en återställning är nödvändig måste denna exakta ordning ställas in igen.

I WebAdmin kan du också se den aktuella Route Precedence under:

Routing > SD-WAN routes

Där kommer den att visas i ruttrådgivningsområdet. Ordern ändras via Device Console.

Route Precedence ändring

Syntaxen är:

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

Ordningen på de tre värdena bestämmer prioriteten. Ett typiskt exempel sätter statiska rutter framför SD-WAN policyrutter och VPN rutter:

system route_precedence set static sdwan_policyroute vpn

Om den här beställningen redan är aktiv är problemet förmodligen inte med Route Precedence. Då bör du specifikt kontrollera ruttsökning, SD-WAN policyrutter, IPsec konfiguration, NAT, brandväggsregler och returvägar.

Ett annat exempel sätter SD-WAN Policy Routes före statiska rutter:

system route_precedence set sdwan_policyroute static vpn

Detta kan vara avsiktligt i vissa SD-WAN-designer, men är riskabelt när breda SD-WAN-regler använder Any eller stora nätverksområden. I sådana fall kan hanteringsåtkomst, interna nätverk eller returpaket oväntat dirigeras via SD-WAN. Artikeln Sophos Firewall SD-WAN-routing för reply packets och system traffic förklarar dessa interaktioner mer i detalj.

För policybaserade IPsec specialfall kan vpn också vara nödvändig i första hand:

system route_precedence set vpn static sdwan_policyroute

Detta bör endast göras om VPN-rutterna verkligen måste prioriteras i det konkreta paketflödet. Sophos påpekar att route_precedence inte gör att VPN-rutter vinner över statiska rutter för varje destinationsväg. Om en statisk eller lokal rutt pekar mot en annan zon än WAN bör man vid policybaserade VPN med traffic selectors hellre kontrollera ipsec_route. Vid ruttbaserad IPsec med XFRM-gränssnitt är en ren SD-WAN- eller statisk rutt oftast bättre än att globalt sätta vpn först.

Teständring

Efter justering, kontrollera först den nya beställningen:

system route_precedence show

Testa sedan den påverkade trafiken specifikt. En grön VPN-status eller en befintlig rutt är inte tillräckligt med bevis.

Kontrollera:

• Anslutning till målnätverket med ping, TCP-test eller applikationstest.
• Filtrera Log Viewer på källa, destination och brandväggsregel.
• Kör Packet Capture på ingångs- och utgångsgränssnitt.
• Kontrollera ruttsökning eller påverkad SD-WAN-regel.
• Kontrollera NAT-regeln och översatt käll-IP.
• Kontrollera fjärrstationens returväg.
• Testa hanteringsåtkomst till WebAdmin och SSH från relevanta administratörsnätverk.

Om flera platser påverkas bör du inte bara kontrollera en testklient. Det är bättre att ha minst en klient per relevant nätverk, ett servermål och en fjärråtkomst eller VPN-test om dessa sökvägar påverkas av ändringen.

Återställ

En återställning består inte av ett rekommenderat standardvärde, utan av den tidigare dokumenterade ordningen.

Exempel:

system route_precedence set static sdwan_policyroute vpn

eller:

system route_precedence set sdwan_policyroute static vpn

Kontrollera igen efter återställning:

system route_precedence show

Upprepa sedan samma tester som efter bytet. Om detta gör att det ursprungliga felet återkommer är det en stark indikation på att Route Precedence verkligen är inblandad. Om inget förändras är orsaken troligen någon annanstans.

Vanliga fel

SD-WAN-regeln är för bred

Om en SD-WAN-policyrutt matchar mycket breda källor eller destinationer kan den fånga upp mer trafik än planerat. Detta är särskilt farligt om SD-WAN prioriteras framför static. Hanteringsåtkomst eller interna målnätverk kan sedan oväntat köras via en WAN-rutt.

Typiskt mönster:

• Route Precedence finns på sdwan_policyroute static vpn.
• En SD-WAN-rutt använder Any som destination.
• Systemgenererad trafik eller svarspaket utvärderas också via SD-WAN.

Åtkomst till WebAdmin eller SSH från ett internt subnät kan då förloras, även om brandväggen fortfarande kan nås från andra nätverk.

VPN status förväxlas med routing

En aktiv IPsec-tunnel bevisar bara att tunneln har förhandlats. Det bevisar inte att brandväggen dirigerar trafiken in i tunneln, att NAT är korrekt eller att fjärrstationen vet vägen tillbaka.

Vid policybaserad IPsec är det särskilt viktigt att kontrollera om statiska, lokala eller SD-WAN-rutter också matchar fjärrsubnäten. vpn static sdwan_policyroute kan hjälpa i vissa fall, men ersätter inte kontroll av zon, traffic selectors och en möjlig ipsec_route. Vid ruttbaserad IPsec bör XFRM-gränssnitt, rutt, SD-WAN-rutt och brandväggsregler kontrolleras först.

NAT förbises

Routing avgör vart ett paket skickas.

NAT avgör om källan eller destinationsadressen ändras. Om en rutt är korrekt men returvägen inte fungerar, är NAT eller returvägen ofta inblandad.

Flera ändringar samtidigt

Om Route Precedence, SD-WAN regler, NAT, brandväggsregler och VPN parametrar ändras samtidigt, kan effekten knappast tillskrivas tydligt. Det är bättre att göra en förändring, sedan testa och sedan göra nästa förändring.

Checklista

• Aktuell Route Precedence dokumenterad med system route_precedence show.
• Berörda källor, destinationer, nätverk och tjänster noterade.
• Statiska rutter, SD-WAN policyrutter och VPN rutter kontrollerade.
• Direktanslutna nätverk och interna hanteringsvägar beaktas.
• Breda SD-WAN-rutter identifierade med Any.
• NAT och brandväggsregler kontrollerade.
• Underhållsfönster eller reservväg har definierats.
• Byt set med exakt ordning.
• Efter modifiering utfördes Log Viewer, Packet Capture och applikationstest.
• Hanteringsåtkomst från administratörsnätverk kontrollerad.
• Återställningsorder dokumenterad.

Vanliga frågor