Konfigurera och verifiera RIP på Sophos Firewall

RIP distribuerar automatiskt IPv4-routes mellan routrar. På Sophos Firewall passar protokollet främst för små eller befintliga routingdomäner där ett fåtal routrar behöver utbyta nätverk utan komplicerat vägval.

Den säkra kortversionen är:

1. Dokumentera transitnätet, lokala LAN, peer, förväntade prefix och returväg.
2. Förbered en konfigurationsbackup och oberoende managementåtkomst.
3. Testa direkt IP-nåbarhet mellan transitadresserna.
4. Tillåt Dynamic Routing under Administration > Device access endast för peerzonen eller genom ett begränsat undantag.
5. Välj RIPv2 under Routing > RIP och lämna inledningsvis de globala timerinställningarna oförändrade.
6. Lägg till transitnätet och de lokala LAN-näten under RIP Networks.
7. Ställ LAN-interfacen i Passive mode via Override interface configuration.
8. Matcha version och autentisering på transitinterfacet mot peerens inställningar.
9. Kontrollera status och inlärda routes under Routing > Information > RIP.
10. Testa Route Lookup, Firewall Rule ID och en verklig dubbelriktad tjänst.

⚠️ Default information originate och redistribuering av Connected, Static, OSPF eller BGP förblir avstängda tills varje annonserat prefix och dess returväg är kända. Bred redistribuering kan oväntat sprida management-, transit-, blackhole- eller andra interna routes i hela RIP-domänen.

Den här proceduren behandlar RIPv2 för IPv4 i Gateway Mode. RIPv1 beskrivs endast som ett äldre interoperabilitetsfall. Sophos Firewall stöder inte RIP i Transparent Mode.

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

RIP är ett distance-vector-protokoll. 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 destinationen inte kan nås.

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 peer 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. Med flera redundanta vägar, snabb konvergens eller större interna nätverk är OSPF vanligen det lämpligare protokollet. BGP hör hemma i designer med autonoma system, operatörer eller medveten routingpolicy.

RIP ersätter inte en brandväggsregel och övervakar inte applikationskvalitet. En SD-WAN-route är rätt nivå för val baserat på källa, tjänst, applikation, latens, jitter eller paketförlust.

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.

SFOS erbjuder bland annat följande globala val:

• 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 peers RIPv2. Send V2 and receive both kan underlätta en kontrollerad övergång, men breddar vilken indata som accepteras. Så snart alla peers använder RIPv2 begränsas både sändning och mottagning till V2.

Förstå RIP Networks och Passive Mode

Ett RIP Network är inte det fjärranslutna destinationsnätet. Posten aktiverar RIP på lokala interface vars IP-adress matchar 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 peeren.
• 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.

Global Default metric är startvärdet för redistribuerade routes. Standardvärdet är 1. Administrative distance avgör mellan konkurrerande routingkällor; Sophos använder som standard 120 för RIP. Värdena ändras inte utan dokumenterad anledning.

Standardtimerinställningarna är:

• Update: 30 sekunder
• Timeout: 180 sekunder
• Garbage: 120 sekunder

Timerinställningarna samordnas på alla peers. Aggressivt förkortade värden kan medföra att routes i onödan tas bort och lärs in igen vid paketförlust eller hög belastning.

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
• Router eller 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. I en verklig miljö ersätts transitadresser, interface, zoner och LAN-prefix tillsammans. De båda transit-IP-adresserna måste vara direkt nåbara.

Firewall A ska lära sig 10.20.20.0/24 via 198.51.100.2. Peeren ska lära sig 10.10.10.0/24 via 198.51.100.1. Först denna fram- och returväg möjliggör routad trafik 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 är oberoende av den nya routingen förenklar återställningen.

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

Under Administration > Device access är Dynamic Routing som standard avstängt för alla zoner. I exemplet tillåts det endast i transitinterfacets zon.

Device Access-matrisen gäller för hela zonen. Om andra, ej betrodda interface delar samma zon är en begränsad Local Service ACL Exception för transitnätet och avsedd peer bättre. Device Access och Local Service ACL förklarar uppdelningen.

Behörigheten gäller RIP-paket till brandväggen. Dataflödet mellan 10.10.10.0/24 och 10.20.20.0/24 kräver fortfarande vanliga brandväggsregler. Dynamic Routing aktiveras inte i LAN-zonen enbart för att LAN-nätet annonseras som RIP Network.

Konfigurera RIPv2 i WebAdmin

Konfigurationen speglas på båda peers. Endast transit-IP och lokalt LAN skiljer sig åt.

1. Ange de globala värdena

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

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

Default information originate annonserar en standardroute i RIP-domänen. Detta är endast lämpligt när brandväggen medvetet ska vara utgång för alla okända destinationer och både returvägen och feltillståndet är planerade.

2. Lägg till RIP Networks

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

1. 198.51.100.0 med nätmasken 255.255.255.252
2. 10.10.10.0 med nätmasken 255.255.255.0

Ange samma transitnät och 10.20.20.0/24 på peer B.

Kontrollera före lagring vilket lokalt interface varje Network matchar. Ett alltför brett Network kan aktivera RIP på ytterligare interface och ta med fler direktanslutna nät i processen.

3. Ange Interface Overrides

Välj de deltagande interfacen under Routing > RIP > Override interface configuration.

För transitinterfacet gäller:

• Send version: V2
• Receive version: V2
• Passive mode: av
• Split horizon: anpassat till peer- och hubbdesignen
• Authentication: identisk på båda sidor när den används

För LAN-interfacet gäller:

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

RIPv2 stöder autentisering med klartext och MD5. Klartext skyddar inte lösenordet. MD5 autentiserar routinguppdateringar, men krypterar varken prefix eller metrics. Transitsegmenten förblir därför begränsade till avsedda routrar. För nya, starkare skyddade eller större designer är ett modernare routingprotokoll över en kontrollerad transport normalt mer lämpligt.

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

4. Spegla peeren

På Router eller Firewall B anges samma version, timerinställningar och autentisering. Använd 198.51.100.0/30 och 10.20.20.0/24 som Networks och gör interfacet mot mottagarens LAN passivt.

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

Brandväggsregler, NAT och Route Precedence

För testet behöver båda brandväggarna begränsade, 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.

En inlärd RIP-route vinner inte nödvändigtvis automatiskt. Längre prefix har företräde; därefter spelar även routingkälla, Administrative Distance och global Route Precedence roll. När en statisk route, SD-WAN- eller VPN-route konkurrerar visar Diagnostics > Tools > Route lookup den väg som faktiskt har valts. Route Precedence ändras inte globalt för ett enda RIP-test.

Verifiera RIP och den verkliga datavägen

Verifieringen skiljer mellan routingutbyte, vald route och dataflöde.

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. Peer B ska känna till 10.10.10.0/24 via 198.51.100.1.

Jämför följande under Routing > Information > RIP > Status:

• deltagande interface
• skickade och mottagna RIP-versioner
• timerinställningarna Update, Timeout och Garbage
• routingkällor och redistribuering
• Bad Packets och Bad Routes
• använd autentisering eller Key Chain

En synlig post bekräftar RIP-utbytet, men ännu inte att routen väljs eller att datatrafiken passerar.

Testa Route Lookup och trafik

1. Kontrollera destinationen 10.20.20.10 på Firewall A under Diagnostics > Tools > Route lookup. Next hop och interface ska motsvara transitvägen.
2. Kontrollera destinationen 10.10.10.10 på peer B.
3. Starta en verklig tillåten anslutning från klienten 10.10.10.10 till servern 10.20.20.10.
4. Kontrollera källa, destination, tjänst, Firewall Rule ID, Action och eventuell NAT Rule ID i Log viewer.
5. Bekräfta under Diagnostics > Packet capture att begäran och svar passerar förväntade interface.

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

För ett läsande control-plane-test kan RIP-paket filtreras kort i Device Console:

tcpdump 'udp port 520'

Stoppa utdata med Ctrl+C. Uppdateringar förväntas mellan de två transitadresserna. RIP-paket från ett klient-LAN tyder däremot i det här exemplet på en felaktig interface- eller Device Access-gräns.

I Advanced Shell ger loggarna ytterligare sammanhang:

cd /log
tail -f ripd.log

ripd.log visar protokollspecifika händelser. zebra.log hjälper till att avgöra om en dynamiskt inlärd route har installerats i routingstacken. Stoppa liveutdata med Ctrl+C; därefter kan tail -f zebra.log användas. Sophos Firewall service- och loggfiler klassificerar övriga filer.

Avgränsa fel systematiskt

Ingen RIP-route visas

Testa först direkt nåbarhet mellan transitadresserna. Därefter måste Dynamic Routing vara aktivt i rätt peerzon, ett RIP Network måste matcha det lokala interfacet och kompatibla sändnings- och mottagningsversioner måste finnas. När autentisering används måste metod och hemlighet stämma överens.

tcpdump 'udp port 520' skiljer saknade paket från avvisade eller oanvändbara uppdateringar. Om räknarna Bad Packets eller Bad Routes ökar under Status jämförs version, autentisering, subnät och peerkonfiguration.

Routen visas under RIP men används inte

Protokollutbytet fungerar då. Route Lookup visar om ett mer specifikt prefix, en statisk route, SD-WAN, VPN eller en annan Administrative Distance vinner. RIP-metricen ensam avgör inte 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

Peeren behöver returrouten och båda brandväggarna behöver passande regler. Kontrollera även NAT, asymmetriska vägar och värdens gateway. En befintlig framväg bevisar inte returvägen.

Routen försvinner och visas igen

En instabil transitlänk, paketförlust, omstarter av peeren, avvikande timers eller autentiseringsfel kan utlösa timeout. Jämför värdena Update, Timeout och Garbage på båda sidor. Förkorta inte timers baserat på misstanke; bekräfta först paketvägen och peerstatusen.

Oväntade nätverk annonseras

Kontrollera RIP Networks, Default information originate och varje redistribueringsalternativ separat. Redistribute connected kan omfatta fler interface än bara planerat LAN. Redistribute static kan även distribuera blackhole- eller managementroutes. Funktionen förblir avstängd tills en fullständig prefixlista och filterstrategi finns.

Testa HA och failover på ett kontrollerat sätt

Kontrollera efter en planerad failover i ett HA-kluster på nytt på aktuell Primary:

• RIP Status och deltagande interface
• inlärda routes och deras ålder
• Route Lookup för båda LAN-näten
• ripd.log och zebra.log på den node som behandlade händelsen
• en ny dubbelriktad testanslutning

Genomför testet i ett underhållsfönster. Artikeln lovar varken oavbruten RIP-konvergens eller att befintliga sessioner bevaras. Loggar lagras per bearbetande node och samlas därför vid behov in från båda appliances.

Å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 destinationsnät.

Återställ i omvänd ordning:

1. Stäng av nyaktiverad redistribuering och Default information originate om de avsiktligt ingick i testet.
2. Ta bort lokala RIP Networks.
3. Återställ Interface Overrides till dokumenterat tidigare tillstånd.
4. Återställ de globala RIP-inställningarna.
5. Ta endast bort Dynamic Routing från transitzonen eller ACL-undantaget om ingen OSPF-, BGP- eller PIM-neighbor också behöver det.
6. Aktivera den alternativa statiska eller dynamiska routen på ett kontrollerat sätt.
7. Kontrollera 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.

Checklista

• Gateway Mode, interface, zoner och transitadresser är dokumenterade.
• En backup och oberoende managementåtkomst finns.
• De båda transit-IP-adresserna kan nå varandra direkt.
• Dynamic Routing är endast tillåtet för peerzonen eller ett begränsat undantag.
• Båda sidor använder kompatibla RIPv2- och autentiseringsvärden.
• RIP Networks matchar endast avsedda lokala interface.
• Klienternas LAN-interface använder Passive Mode.
• Default Route Origination och redistribuering aktiveras endast medvetet.
• Routes och Status visar förväntade prefix, next hops och timers.
• Route Lookup bekräftar valda fram- och returvägar.
• Brandväggsreglerna är begränsade, loggade och utan oavsiktlig SNAT.
• En verklig tjänst fungerar dubbelriktat.
• Rollback och HA-test är dokumenterade.

FAQ