Konfigurera och verifiera RIP på Sophos Firewall

RIP distribuerar automatiskt IPv4-routes mellan routrar. På Sophos Firewall lämpar sig protokollet främst för små eller befintliga routingdomäner där ett fåtal routrar utbyter nätverk utan komplicerade vägval.

Den säkra kortversionen är:

Dokumentera transitnät, lokala LAN, peer, förväntade prefix och returväg.
Förbered en konfigurationsbackup och en oberoende väg för managementåtkomst.
Kontrollera att transitadresserna kan nå varandra direkt via IP.
Tillåt Dynamic Routing under Administration > Device access endast för peerzonen eller via ett snävt undantag.
Välj RIPv2 under Routing > RIP och lämna inledningsvis de globala timerinställningarna oförändrade.
Lägg till transitnätet och de lokala LAN-näten under RIP Networks.
Ställ LAN-interfacen i Passive mode via Override interface configuration.
Stäm av version och autentisering på transitinterfacet mot motparten.
Kontrollera status och inlärda routes under Routing > Information > RIP.
Testa Route Lookup, Firewall Rule ID och en verklig dubbelriktad tjänst.

⚠️ Default information originate och redistribuering av Connected, Static, OSPF eller BGP ska förbli avstängda tills varje annonserat prefix och dess returväg är kända. En bred redistribuering kan oavsiktligt sprida Connected- eller Static-routes i hela RIP-routingdomänen.

Den här proceduren behandlar RIPv2 för IPv4 i Gateway Mode. RIPv1 tas endast upp för anslutning av äldre motparter. Sophos Firewall stöder inte RIP i Transparent Mode.

När RIP passar och när det inte gör det

RIP är ett distansvektorprotokoll. Det bedömer en väg utifrån antalet routerhopp. En route med lägre metric föredras. Högst 15 hopp är nåbara; metric 16 betyder att målet inte kan nås.

Routrar utbyter routinguppdateringar regelbundet. Den mottagande routern för in ändringarna i sin routingtabell, ökar vägens metric med 1 och använder avsändaren som Next Hop.

Den enkla modellen är en fördel när:

endast ett fåtal routrar deltar,
topologin är liten och i stort sett stabil,
en befintlig motpart endast stöder RIP,
automatiskt routeunderhåll är viktigare än snabb konvergens och komplex policy.

För en enda fast väg är en statisk route ofta enklare. Vid flera redundanta vägar, krav på snabb konvergens eller större interna nätverk passar OSPF vanligtvis bättre. BGP är avsett för designer med autonoma system, operatörer eller särskilt styrda vägval.

RIP ersätter inte en brandväggsregel och övervakar inte applikationskvalitet. Om vägen ska väljas utifrån källa, tjänst, applikation, latens, jitter eller paketförlust behövs i stället en SD-WAN-route.

Skilja mellan RIPv1 och RIPv2

Använd RIPv2 för nya konfigurationer. Det överför nätmasker och stöder autentisering. RIPv1 är classful, överför inte nätmasker och stöder inte autentisering på Sophos Firewall.

Under RIP version erbjuder SFOS följande tre inställningar:

Send V2 and receive both: skicka RIPv2 samt ta emot RIPv1 och RIPv2
V1: skicka och ta emot RIPv1
V2: skicka och ta emot RIPv2

I exemplet använder båda motparterna RIPv2. Send V2 and receive both kan vara lämpligt under en kontrollerad övergång, men accepterar fortfarande RIPv1-uppdateringar. Så snart alla motparter använder RIPv2 ställs både sändnings- och mottagningsversionen in på V2.

Förstå RIP Networks och Passive Mode

Ett RIP Network är inte det fjärranslutna målnätet. Posten aktiverar RIP på lokala interface vars IP-adress tillhör det angivna nätet. Det direktanslutna nätet tas därmed med i RIP-processen och kan annonseras.

I exemplet anges både transitnätet 198.51.100.0/30 och det lokala LAN-nätet 10.10.10.0/24 på Firewall A:

Transitnätet aktiverar RIP på interfacet mot motparten.
LAN-nätet annonseras som ett nåbart lokalt nät.
Passive mode på LAN-interfacet hindrar brandväggen från att skicka RIP-uppdateringar där.

Passive Mode tar inte bort LAN-nätet från routingprocessen. Det hindrar endast RIP-annonser från att skickas via interfacet. Dessutom förblir Dynamic Routing avstängt i klientzonen så att klienter inte kan skicka routinguppdateringar till brandväggen.

Planera exempeltopologin

Det genomgående exemplet ansluter två LAN:

Firewall A: Transit-IP 198.51.100.1/30, lokalt LAN 10.10.10.0/24
Firewall B: Transit-IP 198.51.100.2/30, lokalt LAN 10.20.20.0/24
Transitnät: 198.51.100.0/30
Testklient A: 10.10.10.10
Testserver B: 10.20.20.10

198.51.100.0/24 är reserverat för dokumentation. Transitnät, transit-IP-adresser, LAN-prefix och testvärdar ska konsekvent ersättas med värdena i den egna miljön. Dokumentationsadresserna får inte användas oförändrade i en produktionskonfiguration. De båda transit-IP-adresserna måste kunna nå varandra direkt.

Firewall A ska lära sig 10.20.20.0/24 via 198.51.100.2. Motparten ska lära sig 10.10.10.0/24 via 198.51.100.1. Först när både fram- och returvägen finns kan routad trafik fungera utan Source NAT.

Före ändringen dokumenteras interface, zon, befintliga routes, Route Precedence, förväntad metric och en nåbar testvärd. En aktuell konfigurationsbackup och en managementväg som inte är beroende av den nya routingen möjliggör en kontrollerad återställning.

Tillåt Dynamic Routing på ett begränsat sätt

Kontrollera först under Administration > Device access för vilka zoner Dynamic Routing för närvarande är tillåtet. I exemplet tillåts Dynamic Routing uteslutande för den dedikerade transitzonen eller genom ett ACL-undantag för motparten.

Device Access-matrisen gäller för hela zonen. För en dedikerad och betrodd transitzon kan Dynamic Routing aktiveras där. Om åtkomsten endast ska vara möjlig från en viss motpart eller ett visst transitnät ska zonens kryssruta förbli avmarkerad och ett snävt Allow-undantag för källa och tjänst i stället skapas under Local service ACL exception rule. En samtidig zonövergripande tillåtelse skulle upphäva denna begränsning. Den länkade artikeln förklarar skillnaden mellan Device Access och Local Service ACL.

Denna tillåtelse gäller RIP-paket till brandväggen och kan inte ersättas med en vanlig brandväggsregel. Dataflödet mellan 10.10.10.0/24 och 10.20.20.0/24 kräver däremot fortfarande vanliga brandväggsregler. Dynamic Routing aktiveras inte i LAN-zonen enbart för att LAN-nätet annonseras som ett RIP Network. Dokumentera det faktiska Device Access-läget före ändringen; utgå inte från något generellt standardläge.

Om båda brandväggarna skickar RIP-uppdateringar via transitinterfacet, men endast Firewall A tillåter inkommande uppdateringar, lärs routes bara in på ena sidan: A tar emot uppdateringarna från B och lär sig 10.20.20.0/24 via 198.51.100.2. B fortsätter att skicka sina uppdateringar, men kastar de inkommande uppdateringarna från A eftersom tillåtelsen för Dynamic Routing saknas på B. B lär sig därför inte den route till 10.10.10.0/24 som A annonserar via RIP.

Detta är en asymmetri i utbytet av routinginformation (kontrollplanet), inte ett bevis på ett visst fel i datatrafiken. Kontrollera båda sidor under Routing > Information > RIP > Routes och kontrollera den faktiska tillåtelsen att ta emot uppdateringar på brandväggen som inte lär sig routes. En nödvändig korrigering ska begränsas till den faktiska peerzonen eller ett snävt ACL-undantag; tillåt inte generell åtkomst från WAN. Kontrollera sedan Route Lookup, brandväggsregler, NAT och de verkliga fram- och returvägarna separat.

Konfigurera RIPv2 i WebAdmin

I exemplet är även enheten på sida B en Sophos Firewall. Med två Sophos-brandväggar speglas konfigurationen på motparten; endast transit-IP och lokalt LAN skiljer sig. För en router från en annan tillverkare konfigureras RIPv2, transitnät, lokalt LAN, Passive Mode och eventuell autentisering med motsvarande funktioner i den enheten.

1. Ange globala värden

Öppna de globala inställningarna under Routing > RIP:

Ställ in RIP version på V2.
Lämna Default metric på det befintliga standardvärdet 1.
Lämna Administrative distance på det befintliga standardvärdet 120.
Lämna inledningsvis Update, Timeout och Garbage på 30, 180 respektive 120 sekunder.
Låt Default information originate vara avstängt.
Aktivera ingen redistribuering.
Spara med Apply.

Default information originate skapar och annonserar en standardroute i RIP-routingdomänen och är avstängt som standard. Det är endast lämpligt om brandväggen avsiktligt ska vara utgång för alla okända mål och både returvägen och beteendet vid ett avbrott är planerade.

Default metric för redistribuerade routes har standardvärdet 1; tillåtna värden är 1 till 16. Administrative distance har standardvärdet 120 och ett tillåtet intervall på 1 till 255. Utan en dokumenterad routingdesign ska båda värdena förbli oförändrade.

Administrative distance hjälper routern att välja den bättre routen mellan konkurrerande routingkällor; RIP-metricen jämför däremot vägar inom RIP.

Standardvärdena för Update, Timeout och Garbage är 30, 180 respektive 120 sekunder. Update anger intervallet mellan två periodiska routinguppdateringar. Den officiella dokumentationen för SFOS 22.0 anger 5 till 2147483647 sekunder för var och en av dessa tre timers; dokumentationen för SFOS 23.0 anger 1 till 32767 sekunder för var och en och kallar Timeout för Time-out. Detta är versionsspecifika dokumentationsuppgifter, inte en garanti för indatavalidering i en testad build. Exemplet behåller standardvärdena; avvikande värden väljs endast när båda motparterna har en gemensam plan för timers och avbrott.

Om redistribuering avsiktligt behövs, aktivera endast de planerade källorna under Routing > RIP: Redistribute connected för direktanslutna routes, Redistribute static för statiska routes, Redistribute OSPF för OSPF-routes och Redistribute BGP för BGP-routes. Ange motsvarande metric för redistribuerade routes för varje aktiverad källa; alla fyra fälten tillåter 0 till 16, till skillnad från globala Default metric. Välj värden utifrån den dokumenterade routingdesignen, inte genom att kopiera ett generellt värde. Spara med Apply och kontrollera sedan förväntade och oväntade prefix samt returvägen enligt beskrivningen nedan. I exemplet förblir alla fyra källor avstängda.

2. Lägg till RIP Networks

Lägg till följande lokala nät på Firewall A under Routing > RIP > RIP Networks > Add:

198.51.100.0 med nätmasken 255.255.255.252
10.10.10.0 med nätmasken 255.255.255.0

På motpart B läggs samma transitnät och 10.20.20.0/24 till.

Kontrollera före lagring vilket lokalt interface respektive Network omfattar. Ett alltför brett Network kan aktivera RIP på fler interface och föra in ytterligare direktanslutna nät i processen.

3. Ange Interface Overrides

Välj det berörda interfacet med Select interface under Routing > RIP > Override interface configuration.

Send och Receive tillåter oberoende av varandra V1, V2 eller båda versionerna. Valet för varje interface åsidosätter globala RIP version. Send har standardvärdet V2; mottagningsversionen V2 som väljs nedan är en avsiktlig exempelkonfiguration, inte ett påstående om standardvärdet för Receive. Passive mode är avstängt som standard och aktiveras avsiktligt för LAN.

För en avsiktligt autentiserad RIPv2-anslutning, aktivera Authentication och ange ett lösenord; konfigurationen måste stämma överens på båda motparterna. Om autentisering väljs för ett RIPv1-interface skickar det routinguppdateringar men accepterar inga routes. När båda versionerna väljs fortsätter RIPv2 att fungera med autentisering. Sophos rekommenderar att RIPv1 konfigureras på ett annat interface än autentiserat RIPv2.

För transitinterfacet gäller:

Send version: V2
Receive version: V2
Passive mode: av
Split horizon: behåll det dokumenterade ursprungsläget; SFOS har alternativet avstängt som standard
Poisoned reverse: är endast tillgängligt när Split Horizon är aktiverat och är avstängt som standard
Authentication: kontrollera det faktiska ursprungsläget och ställ medvetet in samma värde på båda sidor

För LAN-interfacet gäller:

Send version: V2
Receive version: V2
Passive mode: på

Spara valet med Save. RIPv2 stöder autentisering med klartext och MD5. Klartext skyddar inte lösenordet. MD5 autentiserar routinguppdateringar, men krypterar varken prefix eller metrics. Transitsegment ska därför förbli begränsade till avsedda routrar. Den offentliga CLI-hjälpen för SFOS 22 och WebAdmin-hjälpen lämnar olika uppgifter om standardläget för autentisering. Därför förutsätts inget standardläge här: kontrollera båda transitinterfacens faktiska inställning och konfigurera dem sedan medvetet på samma sätt.

Split horizon hindrar normalt att en route som lärts in via ett interface annonseras tillbaka via samma interface. Poisoned reverse kan uttryckligen annonsera den där som onåbar med metric 16. Ändra endast dessa alternativ när hubb-, spoke- eller fleråtkomsttopologin kräver det och testa ändringen tillsammans med motparten.

4. Spegla motparten

På Firewall B anges samma version, timers och autentisering. Använd 198.51.100.0/30 och 10.20.20.0/24 som Networks och gör interfacet mot det lokala LAN-nätet passivt.

En ensidig konfiguration räcker inte. Utan annonsering av returnätet kan Firewall A visserligen lära sig det fjärranslutna LAN-nätet, men svaren hittar ingen väg tillbaka.

Varför ändringarna i denna guide görs via WebAdmin

Den dokumenterade vägen till CLI skiljer sig mellan versionerna: hjälpen för SFOS 22.0 anger 3. Route Configuration > 1. Configure Unicast Routing > 1. Configure RIP, prompten rip> och därefter enable. Hjälpen för SFOS 23.0 anger i stället 3. Route Configuration > 1. Configure Unicast Routing, prompten router# och därefter router#configure terminal. Tabellposten router rip är ett CLI-kommando, inte ytterligare ett menyval. Detta är en jämförelse av de dokumenterade ingångarna, inte en körbar konfigurationssekvens.

Den offentliga CLI-hjälpen för SFOS 22 innehåller felaktigt sammansatta autentiseringskommandon och dokumenterar inte alla kommandon som krävs för att spara och verifiera. Även hjälpen för SFOS 23.0 är fortfarande tvetydig beträffande CLI-kontexterna för autentisering och MD5-exemplet. Korrigerade klartextexempel gör inte automatiskt de övriga kommandona till en tillförlitlig sekvens. Ingen obekräftad syntax eller några steg för kontextbyte eller sparande härleds från detta material.

Konfiguration och återställning görs i stället via de dokumenterade fälten i WebAdmin. CLI används endast för läsande supportdiagnostik som är dokumenterad för den installerade SFOS-versionen.

Brandväggsregler, NAT och Route Precedence

För testet behöver båda brandväggarna snäva, loggade regler för de tjänster som faktiskt behövs mellan 10.10.10.0/24 och 10.20.20.0/24. Skapa brandväggsregler korrekt förklarar regelmekaniken.

I ett normalt routat platsnät förblir Source NAT avstängt. Båda sidor ska se den verkliga källadressen och känna till returvägen via RIP. SNAT kan dölja saknade returroutes och försvåra senare analys och åtkomstkontroll.

Inom RIP behåller SFOS den route till ett mål som har lägst hoppmetric. Det bevisar inte i sig att vägen även är den aktiva systemövergripande routen. Om en statisk route, SD-WAN-route eller VPN-route konkurrerar kontrolleras den faktiskt valda vägen under Diagnostics > Tools > Route lookup. Route Precedence ändras inte globalt för ett enskilt RIP-test.

Verifiera RIP och den verkliga datavägen

Vid verifieringen kontrolleras tre frågor var för sig: Utbyts routes, väljs rätt route och fungerar datatrafiken?

Kontrollera Routes och Status

Under Routing > Information > RIP > Routes ska Firewall A visa nätet 10.20.20.0/24 med Next Hop 198.51.100.2 och en rimlig metric. Motpart B ska känna till 10.10.10.0/24 via 198.51.100.1.

Jämför följande uppgifter på båda brandväggarna under Routing > Information > RIP > Status:

deltagande interface
skickade och mottagna RIP-versioner
Update-, Timeout- och Garbage-timers
routingkällor och redistribuering
routens From, Tag och Time
inkommande och utgående uppdateringsfilter, om sådana har angetts
Key Chain-namn, om ett sådant har konfigurerats
Bad Packets och Bad Routes

En synlig RIP-route bekräftar routeutbytet, men inte att SFOS väljer routen eller skickar datatrafik via den. Statusvyn bevisar inte vilken hemlighet som används; den måste hanteras och kontrolleras på båda motparterna.

Testa Route Lookup och trafik

Kontrollera målet 10.20.20.10 på Firewall A under Diagnostics > Tools > Route lookup. Next Hop och interface ska stämma med transitvägen.
Kontrollera målet 10.10.10.10 på motpart B.
Starta en verklig tillåten anslutning från klienten 10.10.10.10 till servern 10.20.20.10.
Kontrollera källa, mål, tjänst, Firewall Rule ID, Action och eventuell NAT Rule ID i Log viewer.
Bekräfta under Diagnostics > Packet capture att begäran och svaret passerar de förväntade interfacen.

Hela proceduren beskrivs i Testa en brandväggsregel med Log Viewer och Packet Capture.

Avgränsa fel systematiskt

Ingen RIP-route visas

Kontrollera först att transitadresserna kan nå varandra direkt. Därefter måste Dynamic Routing vara tillåtet i rätt peerzon, ett RIP Network måste motsvara det lokala interfacet och sändnings- och mottagningsversionerna måste vara kompatibla. Om autentisering används måste metod och hemlighet stämma överens.

Om räknarna Bad Packets eller Bad Routes ökar under Status jämförs version, autentisering, subnät och motpartens konfiguration. Om räknarna förblir oförändrade och diagnostikvyerna inte visar någon RIP-trafik från motparten kontrolleras först interfacetilldelningen och Local Service ACL. Globala RIP-värden bör ändras först därefter.

Routen visas under RIP men används inte

Då fungerar protokollutbytet. Route Lookup visar vilken väg som faktiskt är aktiv. RIP-metricen jämför RIP-vägar; den avgör inte ensam mellan alla routingkällor.

Ta inte bort global Route Precedence eller en befintlig produktionsroute innan dess påverkan på andra nätverk har dokumenterats.

Trafiken fungerar bara i en riktning

Motparten behöver returrouten och båda brandväggarna behöver lämpliga regler. Kontrollera även NAT, asymmetriska vägar och värdens standardgateway. En fungerande framväg bevisar inte att returvägen fungerar.

Routen försvinner och visas igen

Om inga uppdateringar tas emot innan det konfigurerade Timeout-värdet löper ut blir routen ogiltig. Under Garbage-tiden annonserar SFOS den som onåbar med metric 16 och tar sedan bort den. Jämför därför nåbarhet, motpartens status samt Update-, Timeout- och Garbage-värdena på båda sidor innan timers ändras.

Oväntade nät annonseras

Kontrollera RIP Networks, Default information originate och varje redistribueringsalternativ separat. Redistribuering kan omfatta fler Connected- eller Static-routes än de LAN som är avsedda för det här exemplet. Funktionen ska förbli avstängd tills samtliga prefix som faktiskt ska distribueras är kända.

Återställ ändringen på ett säkert sätt

Innan RIP tas bort måste det finnas en alternativ väg eller ett planerat underhållsfönster för varje inlärt målnät.

Återställningen börjar med ersättningsvägen, inte med att de aktiva RIP-routena tas bort:

Aktivera en alternativ statisk eller dynamisk route och verifiera den med Route Lookup, managementåtkomst och verklig dubbelriktad trafik.
Stäng av nyaktiverad redistribuering och Default information originate om de avsiktligt ingick i testet; kontrollera sedan de förväntade prefixen igen.
Ta bort lokala RIP Networks ett i taget och kontrollera fram- och returvägen efter varje steg.
Återställ Interface Overrides och globala RIP-inställningar till det dokumenterade ursprungsläget.
Ta bort Dynamic Routing från transitzonen eller ACL-undantaget sist och endast om ingen OSPF-, BGP- eller PIM-granne också behöver tillåtelsen.
Kontrollera slutligen Route Lookup, regler, managementåtkomst och verklig trafik på nytt.

Ta inte bort RIP och ersättningsvägen samtidigt. Håll en befintlig administratörssession öppen tills returvägen har bekräftats.

Frisläppningskontroll

Båda brandväggarna visar de förväntade RIP-routena med rätt Next Hop och rimlig metric.
Route Lookup bekräftar avsedd fram- och returväg.
Inga oväntade prefix eller oavsiktlig redistribuering förekommer.
Snäva, loggade brandväggsregler används utan oavsiktlig SNAT.
En verklig tjänst fungerar i båda riktningarna.
Ersättningsväg och återställning är dokumenterade och genomförbara.