Konfigurera och testa en statisk rutt i Sophos Firewall

En statisk rutt anger vilken fast next hop eller vilket tunnelgränssnitt Sophos Firewall ska använda för att nå ett visst mål. Den passar när vägen är fast och inget val behöver göras utifrån källa, tjänst, applikation eller länkkvalitet.

Kort svar

En IPv4-rutt skapas här:

Routing > Static routes > IPv4 unicast route > Add

För målnätet 10.20.0.0/24, som kan nås via routern 192.0.2.2 på Port4, anger du:

Destination IP / Netmask: 10.20.0.0/24
Gateway IP: 192.0.2.2
Interface: Port4
Administrative distance: 1
Metric: 10
Description: Branch_10.20_via_Core

Målnätet, gatewayen och gränssnittet måste motsvara den egna miljön. Återanvänd inte Administrative Distance och Metric innan befintliga rutter till samma mål har kontrollerats; 1 och 10 är endast exempelvärden.

Kontrollera sedan målet 10.20.0.10 under Diagnostics > Tools > Route lookup. Om resultatet visar Port4 är routingbeslutet korrekt. Ändringen är fullständigt verifierad först när en verklig klientanslutning fungerar och svaret kommer tillbaka.

För att trafiken verkligen ska fungera behövs även en passande brandväggsregel och en returrutt på motparten. En statisk rutt tillåter ingen trafik och utför inte NAT automatiskt.

Förstå exemplet

Exemplet använder följande uppbyggnad:

Klientnätet bakom Sophos Firewall är 10.10.0.0/24.
Testklienten i nätet är 10.10.0.10.
Brandväggens Port4 har transit-IP-adressen 192.0.2.1/30.
Nästa router har IP-adressen 192.0.2.2 i detta nät.
Målnätet 10.20.0.0/24 ligger bakom routern.
Testsystemet är 10.20.0.10.

Destination är alltid fjärrmålet, inte nästa router. Gateway IP är den direkt nåbara next hop som vidarebefordrar paketet. Interface är porten eller tunnelgränssnittet som används för att nå denna next hop.

Målet kan vara ett nät eller en enskild värd. Om bara testvärden ska använda denna väg väljer du exempelvis 10.20.0.10/32 för IPv4 eller 2001:db8:20::10/128 för IPv6 i stället för ett helt nät. Ett bredare prefix omfattar fler måladresser och bör bara väljas om även de kan nås via denna next hop. Brandväggens tillåtelse är fortfarande en separat fråga.

Adressen anges direkt under Gateway IP; det behövs inget gateway-objekt under Routing > Gateways. För den egna miljön byter du målnät, gateway och gränssnitt tillsammans. Om bara en exempeladress ändras kan rutten visserligen sparas men peka mot fel nät eller en router som inte kan nås. Gatewayens IP-adress måste tillhöra nätet för det valda gränssnittet.

Om rutten i stället behöver en egen Health Check eller ska kunna väljas i en SD-WAN Route, följ den separata guiden för Custom Gateways i Sophos Firewall.

Grunderna för portar, zoner och gränssnitts-IP beskrivs i Konfigurera zoner och gränssnitt i Sophos Firewall.

När en statisk rutt passar

Den här artikeln behandlar unicast-destinationsnätverk. Om en sändare ska nå en multicast-grupp via flera gränssnitt följer du den separata anvisningen Konfigurera multicast med en statisk multicast-rutt.

Multicast skickar en enda dataström till en grupp i stället för separata kopior till varje mottagare, exempelvis för videokonferenser, utbildning eller programvarudistribution. Mottagarna måste ansluta sig till gruppen; sändare, mottagare och berörda routrar måste stödja multicast. IPv4-gruppadresser ligger mellan 224.0.0.0 och 239.255.255.255, medan källadressen förblir en unicast-adress. Detta är det allmänna adressintervallet, inte ett tillstånd att använda varje mål i en statisk multicast-rutt. Under Routing > Static routes aktiverar Enable multicast forwarding vidarebefordran. Manage multicast route stöder att lägga till, redigera, radera och filtrera på käll-IP, multicast-IP, Source Interface eller Destination Interface. Den länkade multicast-anvisningen beskriver förutsättningar, tillåtet gruppintervall, säkra tester och återställning.

En statisk rutt är lämplig när ett nät alltid kan nås via samma next hop, till exempel:

ett filialnät bakom en intern Core Router
ett servernät bakom en Layer 3-switch
ett nät bakom en RED-tunnel
ett fjärrnät via ett XFRM-gränssnitt i en ruttbaserad IPsec-tunnel

Om brandväggen dessutom måste fatta beslut utifrån källa, tjänst eller applikation, eller byta väg baserat på latens, jitter och paketförlust, är en SD-WAN-rutt vanligtvis ett lämpligare verktyg. I små eller befintliga routingdomäner kan RIPv2 automatiskt utbyta enkla nätverk. I större nät som ändras ofta minskar OSPF eller BGP det manuella underhållet.

Konfigurera en IPv4-rutt

Dokumentera målnät, next hop, utgående gränssnitt, förväntad zon, returväg och en nåbar testvärd före ändringen. Därefter:

Öppna Routing > Static routes.
Klicka på Add under IPv4 unicast route.
Ange 10.20.0.0/24 under Destination IP / Netmask.
Ange nästa router 192.0.2.2 under Gateway IP.
Välj Port4 som Interface.
Ställ in Administrative distance på 1.
Ange 10 under Metric.
Lägg till en tydlig Description, exempelvis Branch_10.20_via_Core.
Spara med Save.

För den här rutten tar Sophos Firewall först hänsyn till det valda gränssnittet och därefter gatewayen. Om något av fälten är felaktigt nås inte avsedd next hop. I IPv4-listan kan du filtrera på IP-adress, Gateway IP, Interface eller Description och redigera, klona, radera, aktivera eller inaktivera rutter. IPv6-listan stöder filtrering på IP-adress, Gateway IP eller Interface samt att lägga till, redigera eller radera rutter.

Administrative Distance och Metric

Administrative Distance bedömer konkurrerande routingkällor. Ett lägre värde har företräde: en rutt med 1 föredras framför en rutt med 5.

Om flera statiska rutter till samma mål har samma Administrative Distance avgör Metric. Även här föredras det lägre värdet.

Global Route Precedence mellan Static, SD-WAN och VPN är en annan nivå än Administrative Distance och Metric. Den bör inte ändras förhastat för en enskild ny rutt.

Exempelvärdena 1 och 10 är enkla utgångsvärden för en enskild rutt, inte en allmän produktrekommendation. Jämför befintliga rutter till samma mål innan värdena används. För Primary/Backup eller ECMP väljs Administrative Distance och Metric medvetet enligt önskad prioritet.

Två rutter med olika Administrative Distance kan beskriva en föredragen och en sekundär väg. Administrative Distance och Metric övervakar dock inte själva next hop. För en tillgänglighetskontroll används en övervakad gateway i en SD-WAN-rutt. För val baserat på latens, jitter eller paketförlust behöver rutten dessutom en SD-WAN Profile med Best quality eller Custom SLA.

Gör ruttbaserad IPsec redundant med två internetanslutningar visar ett fullständigt exempel med två operatörer och två Any-to-Any-XFRM-tunnlar. Gateways, spegelvända rutter, Route Precedence, Failover och Failback verifieras tillsammans.

För IPv4 ECMP skapar du flera rutter till samma mål med samma Administrative Distance och Metric men med olika next hops. Anslutningar kan då fördelas över likvärdiga next hops; det skapas ingen kvalitetsbaserad Primary/Backup-väg.

Använd Blackhole medvetet

Med Blackhole kasserar brandväggen trafik till det angivna målet utan att svara källan. Det kan vara användbart för avsiktligt blockerade eller aggregerade nät, men ersätter inte en normal next hop.

Om statiska rutter distribueras via RIP, OSPF eller BGP måste Blackhole-rutter filtreras specifikt. Annars kan brandväggen även annonsera denna blockeringsrutt till andra routrar.

Specialfall för IPv6 och tunnlar

Under IPv6 unicast route anges måladress med prefix, Gateway IP, Interface och Metric. Sophos dokumenterar ingen Administrative Distance, Blackhole-inställning, beskrivning, Clone-funktion eller aktiverings-/inaktiveringsfunktion för IPv6-formuläret. IPv4-inställningar bör därför inte överföras till IPv6 utan kontroll.

Följ dessa steg för ett normalt routat IPv6-nät:

Klicka på Add under Routing > Static routes > IPv6 unicast route.
Ange ett målnät, exempelvis 2001:db8:20::/64.
Ange 2001:db8:4::2 under Gateway IP och välj Port4 under Interface.
Välj en Metric som 10 efter jämförelse med befintliga rutter och spara med Save.

Exemplet förutsätter 2001:db8:4::1/64 på Port4 och en direkt nåbar router på 2001:db8:4::2. Alla IPv6-adresser är dokumentationsvärden; byt ut dem tillsammans mot adresser från den egna planen. Dokumentera tidigare ruttvärden och säkerställ oberoende administrationsåtkomst före ändringen. Kontrollera sedan 2001:db8:20::10 med Route lookup, en verklig IPv6-klientanslutning och Packet capture med host 2001:db8:20::10; utgående trafik och svar måste följa den planerade vägen. Det behövs också en IPv6-brandväggsregel och en returrutt till klientnätet. RED/ARP-undantaget nedan visar inte att samma mekanism gäller för IPv6; bekräfta eventuella IPv6-RED-specialfall för den installerade versionen före ändringen.

För en ruttbaserad IPsec-tunnel med Any-to-Any-Subnets kan rutten peka direkt mot XFRM-gränssnittet utan att en separat gateway behövs. Om tunneln använder specifika Traffic Selectors skapar SFOS rutten automatiskt; då konfigureras inga egna IP-adresser eller ytterligare rutter på XFRM-gränssnittet. En XFRM-rutt är inte heller det versionsberoende CLI-specialfallet ipsec_route; skillnaden förklaras i Skapa en IPsec-rutt i Sophos Firewall.

För ett nät bakom peer-gränssnittet i en Site-to-Site RED-tunnel mellan Sophos Firewalls gäller ytterligare ett undantag: peer-RED-gränssnittets IP-adress anges som gateway, men inget gränssnitt väljs. På så sätt kan brandväggen fastställa det nåbara gränssnittet via ARP. Konfigurera Site-to-Site RED mellan två Sophos Firewall förklarar den fullständiga server- och klientdesignen.

Brandväggsregel, NAT och returväg

Routing bestämmer vägen. Brandväggsregeln avgör om paketet får passera och NAT ändrar adresserna vid behov. Dessa tre uppgifter konfigureras separat.

I exemplet behövs en regel från klientnätet 10.10.0.0/24 till målnätet 10.20.0.0/24. Destination Zone är zonen för Port4. Regeln begränsas till de tjänster som faktiskt behövs och logging aktiveras för testet.

I ett normalt routat platsnät är SNAT oftast inte önskvärt, eftersom motparten ska se klientens verkliga IP-adress. Routern 192.0.2.2 behöver då följande returrutt:

Målnät: 10.10.0.0/24
Next Hop: 192.0.2.1

Om det inte går att konfigurera en returrutt på motparten kan SNAT vara en teknisk lösning. Det döljer dock klientens ursprungliga IP-adress och bör förbli ett medvetet designbeslut. Sambanden förklaras i Förstå NAT i Sophos Firewall.

Statiska rutter via XML API: fält och begränsningar vid redigering

När statiska rutter automatiseras måste XML-fälten under UnicastRoute skiljas från beteckningarna i användargränssnittet. API-parametertabellerna för SFOS 22.0 och 23.0 dokumenterar följande:

Distance betecknar Metric, inte Administrative Distance: valfritt, standardvärde 0, intervall 0–255.
AdministrativeDistance betecknar Administrative Distance: valfritt, standardvärde 1, intervall 1–255.

Dessa API-standardvärden är ingen rekommendation för rutten som visas ovan och bevisar inte att utelämnade fält förblir oförändrade vid en uppdatering. Den önskade prioriteten måste fortfarande jämföras med befintliga rutter.

XML-exemplet innehåller även OldConfiguration med tidigare fält för mål, gateway, gränssnitt och prioritet. Parametertabellen saknar dock en beskrivning av detta block. Exemplet bevisar därför varken vilka fält som identifierar rutten som ska redigeras, vilka tidigare värden som är obligatoriska eller om samtidiga ändringar upptäcks eller jämförs atomärt. Automatisering får inte bygga på detta för att garantera korrekt matchning vid uppdateringar eller samtidighetskontroll.

Även för adressfälten finns motsägelser mellan exemplet och tabellen:

IPFamily: exemplet visar IPv4/IPv6, medan tabellen anger datatypen INTEGER och standardvärdet IPv4.
DestinationIP: beskrivningen nämner IPv4-/IPv6-adresser, men datatypen är IPADDRESS6.
Netmask: exemplet visar 0.0.0.0, medan tabellen beskriver ett prefix som INTEGER i intervallet 0–128.

Det går inte att härleda en universell, körbar IPv4-/IPv6-förfrågan från detta. Före en API-redigering i produktion ska förfrågans schema och entydiga matchning mot den befintliga rutten för den installerade versionen klarläggas och verifieras i en testmiljö. Dokumentera de tidigare värdena och säkerställ oberoende administrationsåtkomst i förväg. Kontrollera därefter de sparade ruttvärdena, Route Lookup och en verklig klientanslutning inklusive returvägen; återställningen som beskrivs nedan är fortfarande nödvändig. Så länge schemat eller matchningen är oklart ska ändringen göras enligt arbetsgången i användargränssnittet som beskrivs ovan, i stället för med en gissad XML-förfrågan.

För borttagning gäller särskilda dokumentationsbegränsningar. Tabellerna för Delete Unicast Route i SFOS 22.0 och 23.0 markerar DestinationIP och Netmask som obligatoriska fält. Det belägger dock inte att de utgör en fullständig och entydig selektor för den rutt som ska tas bort. Alla tio celler för standardvärden är tomma; det innebär varken värdet 0, ”oförändrat” eller null. För IPFamily anges endast datatypen INTEGER, utan någon koppling mellan tillåtna värden och IPv4 eller IPv6. Ett exempel på en Delete-förfrågan saknas.

De standardvärden för Add/Update och antaganden om OldConfiguration som beskrivs ovan får därför inte överföras till Delete. Så länge förfrågans schema och den entydiga identifieringen av målrutten för den installerade builden är oklara ska borttagningen göras via arbetsgången i användargränssnittet och med den återställning som beskrivs nedan, inte med en gissad XML-förfrågan för borttagning. Dokumentera de tidigare ruttvärdena och säkerställ oberoende administrationsåtkomst i förväg; kontrollera därefter ruttvärdena, Route Lookup och en verklig klientanslutning inklusive returvägen.

Kontrollera rutten

En sparad rutt är inte verifierad förrän en verklig klient når motparten och returvägen fungerar.

CLI-kontrollerna nedan hör hemma i 4. Device Console, inte i Advanced Shell, och läser bara det aktuella tillståndet. Kontrollera hela syntaxen för den installerade versionen med Tab eller ? innan kommandona körs. Kör inte ofullständiga kommandon: de kan få tjänsten access_server att sluta svara.

Ange 10.20.0.10 under Diagnostics > Tools > Route lookup. Utdata måste visa Port4.
Kontrollera de konfigurerade IPv4- respektive IPv6-rutterna i Device Console och, vid konkurrens med SD-WAN eller VPN, Route Precedence:
```
show static-route
show static-route6
system route_precedence show
```
Starta en verklig anslutning från klienten 10.10.0.10 till 10.20.0.10, exempelvis ping eller TCP 443, i enlighet med brandväggsregeln.
Kontrollera källa, mål, tjänst, Firewall Rule ID och eventuellt NAT Rule ID i Log viewer.
Använd host 10.20.0.10 under Diagnostics > Packet capture för att kontrollera om förfrågningar lämnar via Port4 och om svaren återkommer.

Om Route Lookup visar rätt väg men ingen trafik flödar ligger orsaken oftast i brandväggsregeln, NAT, returrutten eller målsystemet. Det fullständiga testet av paketflödet beskrivs i Testa en Sophos Firewall-regel med Log Viewer och Packet Capture.

Vid djupare routingproblem kan de senaste posterna i unicast- och kernelloggen i Device Console hjälpa:

show logs staticd.log lines 50
show logs zebra.log lines 50

staticd.log gäller statiska unicast-rutter; zebra.log visar installationen av statiska IPv4-unicast-rutter i kärnan. Tjänste- och loggfiler i Sophos Firewall kopplar fler loggfiler till de ansvariga tjänsterna.

Efter en omstart av ett gränssnitt eller en tunnel kan en ren gateway-rutt till en början saknas i routingtabellen. Den visas när passande trafik matchar målet och gatewayen och brandväggen väljer gränssnittet. Att posten saknas direkt efter omstarten bevisar därför ännu inte att något är fel.

Avgränsa fel och återställ

Route Lookup visar fel gränssnitt

Kontrollera måladress och prefix; ett skrivfel kan matcha ett annat nät.
Gatewayen måste kunna nås direkt via det valda gränssnittet.
Jämför konkurrerande statiska rutter samt Administrative Distance och Metric.
Kontrollera den aktuella ordningen med system route_precedence show för SD-WAN eller VPN. Den globala ändringen förklaras i Ändra Route Precedence säkert.

Förfrågan lämnar, men inget svar kommer tillbaka

Kontrollera returrutten på nästa router och på målsystemet.
Kontrollera brandväggsregeln för den initierande riktningen och befintliga NAT-regler. En regel i motsatt riktning behövs endast om motparten själv initierar nya anslutningar.
Använd Packet Capture för att fastställa om svaret återkommer till Port4.
Kontrollera den lokala brandväggen och standardgatewayen på målsystemet.

Säker återställning

En ny IPv4-rutt inaktiveras först i stället för att raderas. Kontrollera därefter Route Lookup, en ny klientanslutning och den tidigare vägen på nytt. Först när utgångsläget har bekräftats tas rutten och de regler eller NAT-objekt som skapades enbart för ändringen bort vid behov.

Sophos dokumenterar ingen aktiverings-/inaktiveringsfunktion för IPv6. Därför dokumenteras de tidigare värdena i förväg och den nya rutten redigeras eller tas bort vid en återställning. I ett HA-kluster upprepas end-to-end-testet på den nya Primary efter en failover.