Configurare e verificare RIP su Sophos Firewall

RIP distribuisce automaticamente route IPv4 tra router. Su Sophos Firewall, il protocollo è adatto soprattutto a domini di routing piccoli o esistenti, nei quali pochi router devono scambiarsi reti senza una selezione complessa del percorso.

La procedura breve e sicura è la seguente:

Documentare la rete di transito, le LAN locali, il peer, i prefissi attesi e il percorso di ritorno.
Preparare un backup della configurazione e un accesso di gestione indipendente.
Verificare la raggiungibilità IP diretta tra gli indirizzi di transito.
In Administration > Device access, consentire Dynamic Routing solo per la zona del peer o tramite un’eccezione restrittiva.
In Routing > RIP, selezionare RIPv2 e inizialmente lasciare invariati i timer globali.
Aggiungere la rete di transito e le LAN locali in RIP Networks.
Impostare le interfacce LAN su Passive mode tramite Override interface configuration.
Allineare con il peer la versione e l’autenticazione dell’interfaccia di transito.
In Routing > Information > RIP, controllare lo stato e le route apprese.
Verificare Route Lookup, Firewall Rule ID e un servizio bidirezionale reale.

⚠️ Default information originate e la ridistribuzione di Connected, Static, OSPF o BGP rimangono disattivati finché non sono noti ogni prefisso annunciato e il relativo percorso di ritorno. Una ridistribuzione estesa può propagare involontariamente route Connected o Static in tutto il dominio di routing RIP.

Questa procedura tratta RIPv2 per IPv4 in Gateway Mode. RIPv1 viene considerato solo come caso di interoperabilità legacy. Sophos Firewall non supporta RIP in Transparent Mode.

Quando RIP è adatto e quando non lo è

RIP è un protocollo distance-vector. Valuta un percorso in base al numero di hop tra router. Viene preferita una route con metrica inferiore. Sono raggiungibili al massimo 15 hop; la metrica 16 indica una destinazione non raggiungibile.

Questo modello semplice è vantaggioso quando:

sono coinvolti solo pochi router,
la topologia è piccola e sostanzialmente stabile,
un peer esistente supporta solo RIP,
la manutenzione automatica delle route è più importante della convergenza rapida e di policy complesse.

Per un singolo percorso fisso, una route statica è spesso più semplice. Con più percorsi ridondanti, convergenza rapida o reti interne più grandi, OSPF è in genere il protocollo più adatto. BGP appartiene ai design con sistemi autonomi, provider o policy di routing deliberate.

RIP non sostituisce una regola firewall e non monitora la qualità delle applicazioni. Una route SD-WAN è il livello appropriato per selezionare in base a origine, servizio, applicazione, latenza, jitter o perdita di pacchetti.

Distinguere RIPv1 e RIPv2

Per le nuove configurazioni si utilizza RIPv2. Trasmette le subnet mask e supporta l’autenticazione. RIPv1 è classful, non trasmette le subnet mask e non supporta l’autenticazione su Sophos Firewall.

Sotto RIP version, SFOS fornisce queste tre impostazioni:

Send V2 and receive both: inviare RIPv2 e ricevere RIPv1 e RIPv2
V1: inviare e ricevere RIPv1
V2: inviare e ricevere RIPv2

Nell’esempio entrambi i peer usano RIPv2. Send V2 and receive both può essere utile durante una transizione controllata, ma continua ad accettare aggiornamenti RIPv1. Non appena tutti i peer utilizzano RIPv2, impostare su V2 sia la versione di invio sia quella di ricezione.

Comprendere RIP Networks e Passive Mode

Una RIP Network non è la rete di destinazione remota. La voce attiva RIP sulle interfacce locali il cui indirizzo IP corrisponde alla rete specificata. La rete direttamente connessa entra così nel processo RIP e può essere annunciata.

Nell’esempio, su Firewall A vengono inserite sia la rete di transito 198.51.100.0/30 sia la LAN locale 10.10.10.0/24:

La rete di transito attiva RIP sull’interfaccia rivolta al peer.
La LAN viene annunciata come rete locale raggiungibile.
Passive mode sull’interfaccia LAN impedisce al firewall di inviare aggiornamenti RIP su tale rete.

Passive Mode non rimuove la LAN dal processo di routing. Impedisce solo l’invio di annunci RIP tramite quell’interfaccia. Inoltre, Dynamic Routing resta disattivato nella zona client, in modo che i client non possano inviare aggiornamenti di routing al firewall.

Pianificare la topologia di esempio

L’esempio completo collega due LAN:

Firewall A: IP di transito 198.51.100.1/30, LAN locale 10.10.10.0/24
Firewall B: IP di transito 198.51.100.2/30, LAN locale 10.20.20.0/24
Rete di transito: 198.51.100.0/30
Client di test A: 10.10.10.10
Server di test B: 10.20.20.10

198.51.100.0/24 è riservato alla documentazione. Sostituire la rete di transito, IP di transito, prefissi LAN e host di prova in modo coerente con i valori del proprio ambiente. Non utilizzare gli indirizzi di documentazione invariati nella produzione. I due IP di transito devono essere direttamente raggiungibili.

Firewall A deve apprendere 10.20.20.0/24 tramite 198.51.100.2. Il peer deve apprendere 10.10.10.0/24 tramite 198.51.100.1. Solo questo percorso di andata e ritorno consente traffico instradato senza source NAT.

Prima della modifica, documentare l’interfaccia, la zona, le route esistenti, Route Precedence, la metrica attesa e un host di prova raggiungibile. Un backup aggiornato della configurazione e un percorso di gestione indipendente dal nuovo routing consentono un rollback controllato.

Consentire Dynamic Routing in modo restrittivo

In Administration > Device access, verificare innanzitutto per quali zone è attualmente consentito Dynamic Routing. Nell’esempio, consentirlo esclusivamente per la zona di transito dedicata oppure mediante un’eccezione ACL specifica per il peer.

La matrice Device Access si applica all’intera zona. Per una zona di transito dedicata e attendibile, è possibile attivare Dynamic Routing nella matrice. Se l’accesso deve essere limitato a un peer o a una rete di transito specifici, lasciare deselezionata la casella della zona e creare invece, in Local service ACL exception rule, un’eccezione Allow restrittiva per origine e servizio. Un’autorizzazione contemporanea per l’intera zona annullerebbe questa limitazione. Device Access e Local Service ACL spiega la distinzione.

Questa autorizzazione riguarda i pacchetti RIP destinati al firewall e non può essere sostituita da una normale regola firewall. Il traffico dati tra 10.10.10.0/24 e 10.20.20.0/24 richiede invece normali regole firewall. Dynamic Routing non deve essere attivato nella zona LAN solo perché la LAN viene annunciata come RIP Network. Prima della modifica, documentare lo stato effettivo di Device Access senza presupporre un’autorizzazione generale predefinita.

Configurare RIPv2 in WebAdmin

L’esempio utilizza un secondo Sophos Firewall sul lato B. Con due Sophos Firewall, replicare la configurazione sul peer; cambiano solo l’IP di transito e la LAN locale. Per un router da un altro fornitore, configurare RIPv2, la rete di transito, LAN locale, Modalità passiva e qualsiasi autenticazione utilizzando le caratteristiche corrispondenti del dispositivo.

1. Impostare i valori globali

Aprire le impostazioni globali in Routing > RIP:

Impostare RIP version su V2.
Lasciare Default metric al valore predefinito esistente 1.
Lasciare Administrative distance al valore predefinito esistente 120.
Lasciare inizialmente Update, Timeout e Garbage su 30, 180 e 120 secondi.
Lasciare Default information originate disattivato.
Non attivare alcuna ridistribuzione.
Selezionare Apply per salvare le modifiche.

Default information originate annuncia una route predefinita nel dominio RIP. È appropriato solo quando questo firewall deve fungere deliberatamente da uscita per tutte le destinazioni sconosciute e sono stati pianificati sia il percorso di ritorno sia il caso di guasto.

Il valore predefinito di Default metric per le route ridistribuite è 1; l’intervallo consentito va da 1 a 16. Il valore predefinito di Administrative distance è 120, con un intervallo consentito da 1 a 255. Lasciare entrambi i valori invariati a meno che il design di routing documenti un motivo per modificarli.

I valori predefiniti di Update, Timeout e Garbage sono 30, 180 e 120 secondi. SFOS accetta valori da 5 a 2147483647 secondi per ciascun timer. Questo esempio mantiene i valori predefiniti; scegliere valori diversi solo quando entrambi i peer condividono una progettazione documentata dei timer e della gestione dei guasti.

2. Aggiungere RIP Networks

In Routing > RIP > RIP Networks > Add, inserire queste reti locali su Firewall A:

198.51.100.0 con subnet mask 255.255.255.252
10.10.10.0 con subnet mask 255.255.255.0

Sul peer B inserire la stessa rete di transito e 10.20.20.0/24.

Prima di salvare, verificare quale interfaccia locale corrisponde a ogni Network. Una Network troppo ampia può attivare RIP su altre interfacce e includere nel processo ulteriori reti direttamente connesse.

3. Impostare gli Interface Overrides

Sotto Routing > RIP > Override interface configuration, utilizzare Select interface per scegliere l’interfaccia partecipante.

Per l’interfaccia di transito:

Send version: V2
Receive version: V2
Passive mode: disattivato
Split horizon: mantenere lo stato precedente documentato; SFOS disabilita questa opzione per impostazione predefinita
Poisoned reverse: disponibile solo quando Split Horizon è abilitato e disabilitato per impostazione predefinita
Authentication: verificare lo stato precedente effettivo e impostare consapevolmente entrambi i lati in modo identico

Per l’interfaccia LAN:

Send version: V2
Receive version: V2
Passive mode: attivato

Salvare la selezione con Save. RIPv2 supporta l’autenticazione a testo chiaro e MD5. Plaintext non protegge la password. MD5 autentica aggiornamenti di routing, ma non crittografa né prefissi né metriche. I segmenti di transito rimangono quindi limitati ai router previsti. La guida pubblica alla CLI di SFOS 22 e la guida WebAdmin forniscono indicazioni discordanti sullo stato predefinito dell’autenticazione. Questa guida non presuppone quindi alcun valore predefinito: verificare entrambe le interfacce di transito e configurarle consapevolmente in modo identico.

Split horizon impedisce normalmente che una route appresa tramite un’interfaccia venga annunciata nuovamente sulla stessa interfaccia. Poisoned reverse può annunciarla esplicitamente con metrica 16 come non raggiungibile. Queste opzioni vengono modificate solo se richiesto dalla topologia hub, spoke o multi-access e vengono verificate insieme al peer.

4. Replicare la configurazione sul peer

Su Firewall B, impostare la stessa versione, timer e autenticazione. Utilizzare 198.51.100.0/30 e 10.20.20.0/24 come Networks e rendere l’interfaccia locale-LAN passiva.

Una configurazione unilaterale non è sufficiente. Senza l’annuncio della rete di ritorno, Firewall A può apprendere la LAN remota, ma le risposte non trovano il percorso di ritorno.

Perché questa guida utilizza WebAdmin per le modifiche

SFOS fornisce una CLI RIP in 3. Route Configuration > 1. Configure Unicast Routing > 1. Configure RIP. Tuttavia, la guida pubblica alla CLI di SFOS 22 contiene comandi di autenticazione concatenati in modo errato e non documenta tutti i comandi necessari per il salvataggio e la verifica. Questa guida non ne ricava sintassi non verificate. Configurazione e rollback utilizzano pertanto i campi WebAdmin documentati. Utilizzare la CLI solo per la diagnostica di supporto in sola lettura documentata per la versione SFOS installata.

Regole firewall, NAT e Route Precedence

Per il test, entrambi i firewall necessitano di regole restrittive e con logging per i servizi realmente richiesti tra 10.10.10.0/24 e 10.20.20.0/24. Creare correttamente le regole firewall ne spiega il funzionamento.

In una rete di sedi normalmente instradata, source NAT resta disattivato. Entrambi i lati devono vedere l’indirizzo sorgente reale e conoscere il percorso di ritorno tramite RIP. SNAT può nascondere route di ritorno mancanti e complicare l’analisi successiva e il controllo degli accessi.

All’interno di RIP, SFOS mantiene per una destinazione la route con la metrica di hop più bassa. Questo da solo non dimostra che questo percorso è anche il percorso attivo del sistema. Quando un percorso statico, SD-WAN o VPN compete, utilizzare Diagnostics > Tools > Route lookup per controllare il percorso effettivamente selezionato. Non cambiare a livello globale Route Precedence per un singolo test RIP.

Verificare RIP e il percorso dati reale

La verifica distingue tre domande: le route vengono scambiate, viene selezionata la route corretta e il traffico dati funziona?

Verificare Routes e Status

In Routing > Information > RIP > Routes, Firewall A deve mostrare la rete 10.20.20.0/24 con next hop 198.51.100.2 e una metrica plausibile. Il peer B deve conoscere 10.10.10.0/24 tramite 198.51.100.1.

In Routing > Information > RIP > Status, confrontare:

le interfacce coinvolte
le versioni RIP inviate e ricevute
i timer Update, Timeout e Garbage
le fonti di routing e la ridistribuzione
i campi From, Tag e Time della route
filtri di aggiornamento in entrata e in uscita, se configurati
il nome della Key-chain, se configurata
Bad Packets e Bad Routes

Una route RIP visibile conferma lo scambio delle route, ma non che SFOS la selezioni o vi instradi il traffico dati. La vista Status non dimostra quale segreto sia in uso; il segreto deve essere gestito e verificato con procedure controllate su entrambi i peer.

Verificare Route Lookup e il traffico

Su Firewall A, verificare la destinazione 10.20.20.10 in Diagnostics > Tools > Route lookup. Next hop e interfaccia devono corrispondere al percorso di transito.
Sul peer B, verificare la destinazione 10.10.10.10.
Dal client 10.10.10.10, avviare una connessione reale consentita verso il server 10.20.20.10.
In Log viewer, controllare origine, destinazione, servizio, Firewall Rule ID, Action ed eventuale NAT Rule ID.
In Diagnostics > Packet capture, confermare che richiesta e risposta attraversino le interfacce previste.

La procedura completa è descritta in Verificare una regola firewall con Log Viewer e Packet Capture.

Circoscrivere gli errori in modo sistematico

Non appare alcuna route RIP

Verificare prima la raggiungibilità diretta tra gli indirizzi di transito. Quindi Dynamic Routing deve essere attivo nella zona corretta del peer, una RIP Network deve corrispondere all’interfaccia locale e devono essere presenti versioni di invio e ricezione compatibili. Se si usa l’autenticazione, metodo e segreto devono coincidere.

Se i contatori Bad Packets o Bad Routes aumentano in Status, confrontare versione, autenticazione, subnet e configurazione del peer. Se i contatori rimangono invariati e le viste diagnostiche non mostrano traffico RIP dal peer, controllare prima l’assegnazione dell’interfaccia e Local Service ACL. Modificare i valori globali di RIP solo dopo questi controlli.

La route appare in RIP, ma non viene utilizzata

Lo scambio di protocolli funziona. Route Lookup mostra quale percorso è effettivamente attivo. La metrica RIP confronta i percorsi RIP; di per sé non decide tra tutte le fonti di routing.

Non rimuovere la Route Precedence globale o una route di produzione esistente prima di averne documentato l’effetto sulle altre reti.

Il traffico funziona in una sola direzione

Il peer necessita della route di ritorno ed entrambi i firewall di regole appropriate. Controllare inoltre NAT, percorsi asimmetrici e gateway dell’host. Un percorso di andata esistente non dimostra il percorso di ritorno.

La route scompare e riappare

Se non arrivano aggiornamenti prima della scadenza del valore Timeout configurato, la route diventa non valida; durante il periodo Garbage, SFOS la annuncia con metrica 16 e poi la elimina. Confrontare raggiungibilità, stato del peer e valori Update, Timeout e Garbage su entrambi i lati prima di modificare un timer.

Vengono annunciate reti inattese

Controllare singolarmente RIP Networks, Default information originate e ogni opzione di ridistribuzione. La ridistribuzione può includere più route Connected o Static rispetto alle LAN previste nell’esempio. Lasciarla disattivata finché non sono noti tutti i prefissi che devono essere effettivamente distribuiti.

Annullare la modifica in sicurezza

Prima di rimuovere RIP, per ogni rete di destinazione appresa deve esistere un percorso alternativo o una finestra di manutenzione pianificata.

Il rollback inizia dal percorso sostitutivo, non dalla rimozione delle route RIP attive:

Abilitare il percorso statico o dinamico alternativo e convalidarlo con Route Lookup, accesso di gestione e traffico bidirezionale reale.
Disattivare nuovamente la ridistribuzione abilitata e Default information originate se erano deliberatamente parte del test; quindi controllare nuovamente i prefissi previsti.
Rimuovere le RIP Networks locali una alla volta, controllando i percorsi di andata e ritorno dopo ogni passaggio.
Ripristinare gli Interface Overrides e le impostazioni RIP globali allo stato precedente documentato.
Rimuovere per ultimi Dynamic Routing dalla zona di transito o l’eccezione ACL, e solo se nessun neighbor OSPF, BGP o PIM richiede la stessa autorizzazione.
Infine, ricontrollare Route Lookup, regole, accesso alla gestione e traffico reale.

Non rimuovere contemporaneamente RIP e il percorso sostitutivo. Mantenere aperta una sessione amministratore esistente finché il percorso di ritorno non è confermato.

Controllo per l’approvazione

Entrambi i firewall mostrano le route RIP attese con il next hop corretto e una metrica plausibile.
Route Lookup conferma i percorsi in avanti e indietro previsti.
Non compaiono prefissi inaspettati o ridistribuzioni involontarie.
Si applicano regole firewall restrittive e registrate, senza SNAT involontario.
Un servizio reale funziona in entrambe le direzioni.
Il percorso di sostituzione e la procedura di rollback sono documentati ed eseguibili.