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.

I router scambiano periodicamente aggiornamenti di routing. Il router ricevente integra le modifiche nella propria tabella di routing, aumenta la metrica del percorso di 1 e usa il mittente come next hop.

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.

Se entrambi i firewall inviano aggiornamenti RIP tramite l’interfaccia di transito, ma solo Firewall A consente gli aggiornamenti in ingresso, l’apprendimento delle route diventa unilaterale: A riceve gli aggiornamenti di B e apprende 10.20.20.0/24 tramite 198.51.100.2. B continua a inviare i propri aggiornamenti, ma scarta quelli in ingresso da A perché su B manca l’autorizzazione per Dynamic Routing. B quindi non apprende tramite RIP la route verso 10.10.10.0/24 annunciata da A.

Si tratta di un’asimmetria nello scambio delle informazioni di routing (piano di controllo), non della prova di uno specifico problema del traffico dati. Verificare entrambi i lati in Routing > Information > RIP > Routes e controllare l’autorizzazione effettiva alla ricezione sul firewall che non apprende le route. Qualsiasi correzione resta limitata alla zona effettiva del peer o a un’eccezione ACL restrittiva; non autorizzare l’accesso generalizzato dalla WAN. Verificare poi separatamente Route Lookup, regole firewall, NAT e i percorsi reali di andata e ritorno.

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 di un altro produttore, configurare RIPv2, la rete di transito, la LAN locale, Passive mode e l’eventuale autenticazione tramite le funzioni equivalenti 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 genera e annuncia una route predefinita nel dominio RIP ed è disattivato per impostazione predefinita. È 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.

Administrative distance aiuta il router a scegliere la route migliore tra fonti di routing concorrenti; la metrica RIP confronta invece i percorsi all’interno di RIP.

I valori predefiniti di Update, Timeout e Garbage sono 30, 180 e 120 secondi. Update determina l’intervallo tra due aggiornamenti periodici di routing. La documentazione ufficiale di SFOS 22.0 indica da 5 a 2147483647 secondi per ciascuno dei tre timer; quella di SFOS 23.0 indica da 1 a 32767 secondi per ciascuno e denomina Timeout Time-out. Si tratta di valori documentati per versione, non di una garanzia sulla validazione degli input in una build testata. 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.

Se la ridistribuzione è deliberatamente necessaria, attivare solo le fonti previste in Routing > RIP: Redistribute connected per le route direttamente connesse, Redistribute static per le route statiche, Redistribute OSPF per le route OSPF e Redistribute BGP per le route BGP. Impostare la metrica di ridistribuzione corrispondente per ogni fonte attivata; tutti e quattro i campi consentono da 0 a 16, diversamente da Default metric globale. Scegliere i valori secondo il progetto di routing documentato, senza copiare un valore generico. Salvare con Apply, quindi verificare i prefissi attesi e inattesi e il percorso di ritorno come descritto di seguito. Nell’esempio tutte e quattro le fonti rimangono disattivate.

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

La documentazione di SFOS 22.0 e 23.0 ripete il valore predefinito di Receive come V2 and V2, quindi il valore effettivamente inteso non è chiaro. Impostare esplicitamente la versione di ricezione adatta al router remoto, senza basarsi su un valore predefinito presunto.

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

Send e Receive consentono ciascuno, indipendentemente, V1, V2 o entrambe le versioni. La selezione di ogni interfaccia prevale su RIP version globale. Send è impostato su V2 per impostazione predefinita; la versione di ricezione V2 scelta di seguito è una configurazione deliberata dell’esempio, non un’affermazione sul valore predefinito di Receive. Passive mode è disattivato per impostazione predefinita e viene attivato espressamente per la LAN.

Per una connessione RIPv2 volutamente autenticata, attivare Authentication e inserire una password; la configurazione deve coincidere su entrambi i peer. Se si seleziona l’autenticazione per un’interfaccia RIPv1, questa invia aggiornamenti di routing ma non accetta route. Se si selezionano entrambe le versioni, RIPv2 continua a funzionare con l’autenticazione. Sophos raccomanda di configurare RIPv1 su un’interfaccia diversa da quella utilizzata per RIPv2 autenticato.

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

L’accesso alla CLI documentato varia in base alla versione: la guida di SFOS 22.0 indica 3. Route Configuration > 1. Configure Unicast Routing > 1. Configure RIP, il prompt rip> e poi enable. La guida di SFOS 23.0 indica invece 3. Route Configuration > 1. Configure Unicast Routing, il prompt router# e poi router#configure terminal. La voce router rip della tabella è un comando CLI, non un’ulteriore selezione di menu. Si tratta di un confronto degli accessi documentati, non di una sequenza di configurazione eseguibile.

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. Anche la guida di SFOS 23.0 rimane ambigua sui contesti CLI per l’autenticazione e sull’esempio MD5. La correzione degli esempi in testo chiaro non rende automaticamente gli altri comandi una sequenza affidabile. Questa guida non ne ricava né sintassi non verificate né passaggi per cambiare contesto o salvare.

La configurazione e il rollback vengono pertanto eseguiti tramite i campi WebAdmin documentati. Nella procedura ordinaria, la CLI viene utilizzata solo per diagnosi di supporto in sola lettura documentate per la versione SFOS installata. Un’eccezione separata e opzionale è il Debug del routing con disattivazione sicura di SFOS 23 concordato con il supporto: modifica lo stato diagnostico e deve essere disattivato esplicitamente dopo la raccolta, anche se era già stato attivato durante una precedente sessione di supporto. Il comando debug rip zebra mostrato in quella sezione è soltanto l’esempio diagnostico documentato, non un’alternativa alla configurazione RIP o dell’autenticazione per la quale qui non viene proposta una procedura CLI eseguibile. La verifica dello stato e delle route rimane l’approccio ordinario.

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 tale percorso sia anche la route attiva a livello di sistema. In presenza di una route statica, SD-WAN o VPN concorrente, 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.