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:

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

⚠️ Default information originate e la ridistribuzione di Connected, Static, OSPF o BGP restano disattivati finché non sono noti tutti i prefissi annunciati e i relativi percorsi di ritorno. Una ridistribuzione ampia può propagare in modo imprevisto route di gestione, transito, blackhole o altre route interne nell’intero dominio 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.

SFOS offre, tra le altre, queste opzioni globali:

• 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 utilizzano RIPv2. Send V2 and receive both può agevolare una transizione controllata, ma amplia gli input accettati. Non appena tutti i peer utilizzano RIPv2, sia l’invio sia la ricezione vengono limitati a V2.

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.

La Default metric globale è la metrica iniziale per le route ridistribuite. Il valore predefinito è 1. Administrative distance decide tra fonti di routing concorrenti; Sophos usa per impostazione predefinita 120 per RIP. Questi valori non vengono modificati senza un motivo documentato.

I timer predefiniti sono:

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

I timer vengono coordinati su tutti i peer. Valori ridotti in modo aggressivo possono causare la rimozione e il riapprendimento inutili delle route in caso di perdita di pacchetti o carico elevato.

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
• Router o 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 è riservata alla documentazione. In un ambiente reale, indirizzi di transito, interfacce, zone e prefissi LAN vengono sostituiti insieme. 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 vengono documentati interfaccia, zona, route esistenti, Route Precedence, metrica attesa e un host di test raggiungibile. Un backup della configurazione aggiornato e un percorso di gestione indipendente dal nuovo routing facilitano il ripristino.

Consentire Dynamic Routing in modo restrittivo

In Administration > Device access, Dynamic Routing è disattivato per impostazione predefinita in tutte le zone. Nell’esempio viene consentito solo nella zona dell’interfaccia di transito.

La matrice Device Access si applica all’intera zona. Se nella stessa zona sono presenti altre interfacce non attendibili, è preferibile una Local Service ACL Exception restrittiva per la rete di transito e il peer previsto. Device Access e Local Service ACL spiega questa separazione.

Questa autorizzazione riguarda i pacchetti RIP destinati al firewall. Il flusso dati tra 10.10.10.0/24 e 10.20.20.0/24 richiede comunque normali regole firewall. Dynamic Routing non viene attivato nella zona LAN solo perché la LAN è annunciata come RIP Network.

Configurare RIPv2 in WebAdmin

La configurazione viene replicata su entrambi i peer. Cambiano solo l’IP di transito e la LAN locale.

1. Impostare i valori globali

Aprire le impostazioni globali in Routing > RIP:

1. Impostare RIP version su V2.
2. Lasciare Default metric al valore predefinito esistente 1.
3. Lasciare Administrative distance al valore predefinito esistente 120.
4. Lasciare inizialmente Update, Timeout e Garbage su 30, 180 e 120 secondi.
5. Lasciare Default information originate disattivato.
6. Non attivare alcuna ridistribuzione.
7. 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.

2. Aggiungere RIP Networks

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

1. 198.51.100.0 con subnet mask 255.255.255.252
2. 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

In Routing > RIP > Override interface configuration, selezionare le interfacce coinvolte.

Per l’interfaccia di transito:

• Send version: V2
• Receive version: V2
• Passive mode: disattivato
• Split horizon: adeguato al design peer e hub
• Authentication: identica su entrambi i lati quando utilizzata

Per l’interfaccia LAN:

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

RIPv2 supporta l’autenticazione in testo normale e MD5. Il testo normale non protegge la password. MD5 autentica gli aggiornamenti di routing, ma non cifra né i prefissi né le metriche. I segmenti di transito restano quindi limitati ai router previsti. Per design nuovi, con protezione più elevata o di maggiori dimensioni, è in genere più adatto un protocollo di routing moderno su un trasporto controllato.

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

Sul Router o Firewall B vengono impostati la stessa versione, gli stessi timer e la stessa autenticazione. Come Networks si usano 198.51.100.0/30 e 10.20.20.0/24; l’interfaccia verso la LAN ricevente viene resa 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.

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.

Una route RIP appresa non prevale necessariamente in automatico. I prefissi più lunghi hanno la precedenza; successivamente contano anche la fonte di routing, Administrative Distance e la Route Precedence globale. Quando compete una route statica, SD-WAN o VPN, Diagnostics > Tools > Route lookup mostra il percorso effettivamente selezionato. Route Precedence non viene modificata globalmente per un singolo test RIP.

Verificare RIP e il percorso dati reale

La verifica separa lo scambio di routing, la route selezionata e il flusso dati.

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
• Bad Packets e Bad Routes
• l’autenticazione o la Key Chain utilizzata

Una voce visibile conferma lo scambio RIP, ma non ancora che quella route venga selezionata o che il traffico dati passi.

Verificare Route Lookup e il traffico

1. 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.
2. Sul peer B, verificare la destinazione 10.10.10.10.
3. Dal client 10.10.10.10, avviare una connessione reale consentita verso il server 10.20.20.10.
4. In Log viewer, controllare origine, destinazione, servizio, Firewall Rule ID, Action ed eventuale NAT Rule ID.
5. 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.

Per una verifica in sola lettura del control plane, filtrare brevemente i pacchetti RIP in Device Console:

tcpdump 'udp port 520'

Terminare l’output con Ctrl+C. Sono attesi aggiornamenti tra i due indirizzi di transito. I pacchetti RIP provenienti da una LAN client indicano invece, in questo esempio, un limite errato dell’interfaccia o di Device Access.

In Advanced Shell, i log forniscono ulteriore contesto:

cd /log
tail -f ripd.log

ripd.log mostra eventi specifici del protocollo. zebra.log aiuta a stabilire se una route appresa dinamicamente è stata installata nello stack di routing. Terminare l’output in tempo reale con Ctrl+C; in seguito è possibile usare tail -f zebra.log. File di servizio e di log di Sophos Firewall classifica gli altri file.

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.

tcpdump 'udp port 520' distingue i pacchetti assenti dagli aggiornamenti rifiutati o inutilizzabili. Se in Status aumentano i contatori Bad Packets o Bad Routes, confrontare versione, autenticazione, subnet e configurazione del peer.

La route appare in RIP, ma non viene utilizzata

In tal caso lo scambio del protocollo funziona. Route Lookup mostra se prevale un prefisso più specifico, una route statica, SD-WAN, VPN o un’altra Administrative Distance. La sola metrica RIP 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

Un collegamento di transito instabile, perdita di pacchetti, riavvii del peer, timer non corrispondenti o errori di autenticazione possono attivare il timeout. Confrontare i valori Update, Timeout e Garbage su entrambi i lati. Non ridurre i timer in base a un sospetto; dimostrare prima il percorso dei pacchetti e lo stato del peer.

Vengono annunciate reti inattese

Controllare singolarmente RIP Networks, Default information originate e ogni opzione di ridistribuzione. Redistribute connected può includere più interfacce della sola LAN prevista. Redistribute static può distribuire anche route blackhole o di gestione. La funzione resta disattivata finché non sono disponibili un elenco completo dei prefissi e una strategia di filtro.

Verificare HA e failover in modo controllato

In un cluster HA, dopo un failover pianificato verificare nuovamente sul Primary attuale:

• RIP Status e le interfacce coinvolte
• le route apprese e la relativa età
• Route Lookup per entrambe le LAN
• ripd.log e zebra.log sul nodo che ha elaborato l’evento
• una nuova connessione di test bidirezionale

Eseguire il test in una finestra di manutenzione. Questo articolo non promette né una convergenza RIP senza interruzioni né il mantenimento delle sessioni esistenti. I log vengono memorizzati per nodo di elaborazione e vengono quindi raccolti da entrambi gli appliance quando necessario.

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 avviene in ordine inverso:

1. Disattivare la ridistribuzione appena attivata e Default information originate se facevano deliberatamente parte del test.
2. Rimuovere le RIP Networks locali.
3. Riportare gli Interface Overrides allo stato precedente documentato.
4. Ripristinare le impostazioni RIP globali.
5. Rimuovere Dynamic Routing dalla zona di transito o l’eccezione ACL solo se non serve anche a un neighbor OSPF, BGP o PIM.
6. Attivare in modo controllato la route statica o dinamica alternativa.
7. Verificare nuovamente Route Lookup, regole, accesso di 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.

Checklist

• Gateway Mode, interfacce, zone e indirizzi di transito sono documentati.
• Sono disponibili un backup e un accesso di gestione indipendente.
• I due IP di transito possono raggiungersi direttamente.
• Dynamic Routing è consentito solo per la zona del peer o un’eccezione restrittiva.
• Entrambi i lati utilizzano valori RIPv2 e di autenticazione compatibili.
• Le RIP Networks corrispondono solo alle interfacce locali previste.
• Le interfacce LAN client utilizzano Passive Mode.
• Default Route Origination e ridistribuzione sono attivati solo consapevolmente.
• Routes e Status mostrano i prefissi, i next hop e i timer previsti.
• Route Lookup conferma i percorsi di andata e ritorno selezionati.
• Le regole firewall sono restrittive, registrate e prive di SNAT involontario.
• Un servizio reale funziona in entrambe le direzioni.
• Il rollback e il test HA sono documentati.

FAQ