Configurare e verificare PIM-SM su Sophos Firewall

PIM-SM è indicato quando il multicast attraversa più router e i ricevitori aderiscono o abbandonano dinamicamente i gruppi. Invece di mantenere una route fissa per ogni origine e ogni interfaccia di uscita, PIM-SM costruisce il percorso multicast necessario tramite un Rendezvous Point, abbreviato RP.

La procedura breve è la seguente:

Preparare un backup e un accesso di gestione indipendente, quindi documentare origine, gruppo, servizio UDP, router e reti dei ricevitori.
Verificare su ogni router la raggiungibilità unicast dell’RP e della rete di origine.
Salvare le route multicast statiche esistenti e disattivare in modo controllato Enable multicast forwarding.
Verificare Device Access nelle zone con veri neighbor PIM e consentire Dynamic Routing in modo mirato solo se necessario.
In Routing > Multicast (PIM-SM) attivare PIM sulle interfacce IPv4 coinvolte.
Configurare lo stesso RP statico e lo stesso intervallo di gruppi su tutti i router PIM.
Consentire il flusso dati multicast con regole firewall IPv4 restrittive e registrate.
Verificare insieme adesione del ricevitore, Neighbor, RP SET, stato multicast, Rule ID e percorso dei pacchetti.

⚠️ PIM-SM e lo Static Multicast Forwarding non possono essere configurati contemporaneamente su Sophos Firewall. Il passaggio modifica il percorso multicast in produzione. Prima occorre documentare route, gruppi e ricevitori esistenti, oltre a un percorso di ritorno.

Questo articolo tratta il routing multicast IPv4 dinamico con un RP statico. In un dominio PIM, un Bootstrap Router, abbreviato BSR, distribuisce l’informazione su quale RP sia responsabile per ciascun gruppo. Candidate RP viene illustrato più avanti, ma non viene presentato come una presunta soluzione Bootstrap Router automatica.

Quando PIM-SM è la scelta corretta

PIM-SM è particolarmente utile quando sono coinvolti più router multicast, i ricevitori si trovano in reti diverse o le appartenenze ai gruppi cambiano spesso. I router creano così lo stato solo dove esiste un mittente o un ricevitore interessato.

Per un singolo mittente noto e poche interfacce di uscita permanentemente definite, una route multicast statica rimane generalmente più semplice. Non richiede né un RP né un’adiacenza PIM. PIM-SM non è semplicemente un’opzione migliore per la stessa configurazione ridotta, ma un modello operativo differente.

PIM-SM non sostituisce inoltre né il routing unicast né le regole firewall:

Unicast Routing determina in quale direzione sono raggiungibili origine e RP.
PIM-SM costruisce da queste informazioni l’albero di distribuzione multicast tra i router.
IGMP segnala nella rete locale dei ricevitori quali host desiderano ricevere un gruppo.
Le regole firewall consentono o bloccano il flusso dati multicast effettivo tra le zone.

Comprendere IGMP, RP e RPF

Un ricevitore invia nella propria rete IPv4 locale un messaggio di appartenenza IGMP per il gruppo. L’ultimo router multicast traduce questo interesse in un PIM Join verso l’RP. L’RP è il punto d’incontro comune tramite il quale mittenti e ricevitori si trovano inizialmente. In base allo stato creato, il percorso dati può successivamente passare a un Source Tree più breve; l’RP non deve quindi inoltrare in modo permanente ogni pacchetto dati.

Nella tabella multicast, (*,G) indica lo stato condiviso di un gruppo indipendentemente da una specifica origine. (S,G) indica invece lo stato per una determinata origine S e un gruppo G. Nell’esempio è (10.10.10.20, 239.10.10.10).

Il meccanismo di controllo decisivo è il Reverse Path Forwarding, abbreviato RPF. Per un pacchetto proveniente dall’origine 10.10.10.20, il firewall verifica attraverso quale interfaccia raggiungerebbe tale origine secondo la tabella di routing. Se il flusso multicast arriva da un’altra interfaccia, il percorso di ritorno non corrisponde e lo stato o il flusso dati può non funzionare.

PIM è indipendente dal protocollo di routing unicast utilizzato, ma non da route unicast funzionanti. Route statiche, OSPF o BGP possono fornire il percorso RPF. Per l’esempio seguente sono sufficienti route unicast statiche; nei domini di routing più grandi, OSPF può fornire dinamicamente la stessa base.

Pianificare la topologia di esempio

L’esempio collega un mittente dietro il firewall A a un ricevitore dietro il firewall B:

Mittente: 10.10.10.20
Rete di origine sul firewall A: 10.10.10.0/24, interfaccia Port2, zona DMZ
Transito firewall A: 10.255.0.1/30, interfaccia Port4, zona PIM-Transit
Transito firewall B: 10.255.0.2/30, interfaccia Port4, zona PIM-Transit
Rete dei ricevitori sul firewall B: 10.20.20.0/24, interfaccia Port3, zona LAN
Ricevitore di test: 10.20.20.50
Gruppo multicast: 239.10.10.10
Servizio applicativo: UDP 5000
RP statico: 10.255.0.1
Intervallo di gruppi dell’RP: 239.10.10.0/24

Gli indirizzi sono valori di esempio privati. Origine, rete dei ricevitori, rete di transito, gruppo e servizio devono essere sostituiti insieme con i valori dell’applicazione reale. In questo esempio, l’RP 10.255.0.1 si trova sul firewall A e deve essere raggiungibile in unicast da tutti i router PIM.

L’intervallo 239.10.10.0/24 è intenzionalmente più restrittivo di *. Un asterisco assegna tutti i gruppi all’RP e dovrebbe essere utilizzato solo se l’intero dominio PIM è stato progettato in questo modo. Sophos documenta un massimo di otto indicazioni di gruppo o rete per RP.

Le route unicast devono essere configurate prima di PIM. Il firewall A riceve una route verso 10.20.20.0/24 tramite 10.255.0.2; il firewall B una route verso 10.10.10.0/24 tramite 10.255.0.1. Per RPF è particolarmente importante il percorso dal firewall B verso l’origine. In Diagnostics > Tools > Route lookup, una ricerca per 10.10.10.20 deve quindi indicare Port4 e il Next Hop previsto. Queste route unicast non sostituiscono l’albero di distribuzione PIM.

Configurare zone e interfacce Sophos Firewall spiega come separare correttamente interfacce e zone per un transito di questo tipo.

Preparare PIM-SM in sicurezza

Prima della finestra di manutenzione, documentare i seguenti punti:

Gli IP di transito e le route unicast sono stati testati in entrambe le direzioni.
Sono noti origine, gruppo, porta UDP e applicazione ricevente.
L’RP statico e il relativo intervallo di gruppi sono documentati in modo identico per tutti i router.
Sono state inventariate le route multicast statiche esistenti e l’opzione Enable multicast forwarding.
Sono disponibili un backup della configurazione e un accesso di gestione indipendente.
Gli switch nella rete dei ricevitori utilizzano IGMP Snooping solo con un ruolo Querier chiarito e funzionante.

La documentazione Sophos attuale indica interfacce fisiche, RED e interfacce GRE per PIM. Le interfacce Alias, PPPoE e Cellular WAN sono escluse. Altri tipi di interfaccia, come XFRM, non sono confermati esplicitamente nella pagina PIM e non devono quindi essere inseriti in questa configurazione di base senza verifica.

Verificare Dynamic Routing in modo mirato

I messaggi PIM appartengono al Control Plane del firewall. La guida generale di SFOS raggruppa i protocolli di routing in Administration > Device access > Dynamic Routing; la pagina PIM attuale, tuttavia, non indica espressamente questa dipendenza.

Se non si forma alcuna adiacenza PIM, occorre quindi verificare se Dynamic Routing debba essere consentito nella zona in cui si trova il vicino PIM effettivo. Nell’esempio, la zona dedicata PIM-Transit contiene soltanto la rete di transito tra i due firewall. Se l’autorizzazione è necessaria per questa configurazione, viene attivata su entrambi i dispositivi esclusivamente in tale zona.

L’autorizzazione nella matrice vale per l’intera zona. Se nella stessa zona sono presenti altre reti non attendibili, la casella rimane disattivata e una Local Service ACL Exception restrittiva consente Dynamic Routing solo dai neighbor previsti. Un’eccezione aggiuntiva non restringe un’autorizzazione di zona già attiva.

Questo livello Device Access è destinato al traffico di controllo del routing. Se l’autorizzazione PIM è necessaria per la build utilizzata, non riguarda il flusso inoltrato e non sostituisce la relativa regola firewall. Proteggere Device Access su Sophos Firewall spiega i due livelli di accesso.

Sostituire in modo controllato lo Static Multicast Forwarding

In Routing > Static routes si documentano le route multicast esistenti, le applicazioni dipendenti e le interfacce di destinazione. Enable multicast forwarding viene disattivato soltanto durante la finestra di manutenzione. Successivamente è possibile attivare PIM-SM.

Non eliminare preventivamente le route multicast statiche esistenti. Rimangono un modello di rollback documentato finché PIM-SM non è stato verificato completamente.

Configurare PIM-SM

I passaggi seguenti vengono eseguiti sul firewall A e sul firewall B.

Attivare PIM e le interfacce coinvolte

Aprire Routing > Multicast (PIM-SM).
Attivare Enable PIM.
In PIM-enabled interface, selezionare soltanto le interfacce IPv4 coinvolte nel percorso multicast:
- Firewall A: Port2 e Port4
- Firewall B: Port4 e Port3
Non considerare ancora la modifica riuscita; Neighbor e State vengono verificati solo dopo la configurazione completa dell’RP.

PIM non viene attivato indiscriminatamente su tutte le interfacce LAN o WAN. Ogni interfaccia aggiuntiva estende il Control Plane e può consentire nuovi neighbor o percorsi multicast.

Configurare RP statico e intervallo di gruppi

In RP settings, attivare l’opzione e inserire la stessa associazione statica su entrambi i firewall:

RP IP: 10.255.0.1
Multicast group: 239.10.10.0/24

La RP IP è un indirizzo unicast. Deve essere raggiungibile da entrambi i firewall attraverso il percorso PIM previsto. Un valore salvato non è sufficiente: in Routing > Information > PIM-SM > RP SET, il gruppo deve poi risultare effettivamente associato a questo RP.

Salvare quindi la configurazione. Se non è possibile attivare PIM, verificare prima se Enable multicast forwarding è ancora attivo.

Quando Candidate RP è appropriato

Candidate RP è adatto a un dominio PIM esistente nel quale il ruolo BSR e la procedura di selezione dell’RP sono già pianificati. SFOS offre a tale scopo un IP di interfaccia come Candidate RP IP, una lista di gruppi, una priorità da 1 a 255 e un intervallo Advertisement da 30 a 180 secondi.

La sola configurazione di Candidate RP, tuttavia, non rende automaticamente il firewall un BSR funzionante e non garantisce la selezione dell’RP desiderato. Sophos non documenta in WebAdmin una configurazione completa del Bootstrap Router. Candidate RP deve quindi essere utilizzato solo quando il ruolo BSR è noto e il Group-to-RP Mapping risultante può essere controllato in RP SET. Per questo esempio limitato, Static RP rimane più comprensibile.

Creare le regole firewall per il flusso dati

L’adiacenza PIM non fornisce un’autorizzazione di sicurezza generale. Su ogni router, il flusso richiede una regola firewall IPv4 restrittiva per il passaggio tra le rispettive zone.

Sul firewall A, la configurazione prevista è:

Rule name: DMZ_to_PIM_Multicast_5000
Source zone: DMZ
Source network: Host 10.10.10.20
Destination zone: PIM-Transit
Destination network: Host 239.10.10.10
Services: servizio UDP personalizzato con Destination Port 5000
Action: Accept
Log firewall traffic: attivato

Sul firewall B viene creata una seconda regola da PIM-Transit a LAN con la stessa origine, lo stesso gruppo e lo stesso servizio UDP. Per il test non è previsto SNAT, in modo da preservare l’origine e (S,G).

Le regole si applicano al flusso dati multicast. PIM Hello e messaggi di appartenenza IGMP non vengono combinati in un’ampia regola Any. Verificare tramite Rule ID che l’oggetto gruppo corrisponda come previsto sulla build utilizzata. Se compare la Rule 0, non ampliare la regola senza controllo, ma analizzare il percorso dei pacchetti.

Configurare regole Sophos Firewall sicure spiega la struttura generale.

Verificare PIM-SM dal Neighbor al ricevitore

Un’adiacenza PIM visibile è soltanto la prima parte della verifica:

In Routing > Information > PIM-SM > Interface table, sull’interfaccia di transito deve apparire l’altro firewall come Neighbor.
In RP SET, 239.10.10.0/24 deve puntare a 10.255.0.1.
Su 10.20.20.50, avviare l’applicazione ricevente e aderire a 239.10.10.10 su UDP 5000.
Avviare da 10.10.10.20 un flusso di test limitato nel tempo.
In Multicasting routing table, cercare lo stato (*,G) o (S,G) per il gruppo. Incoming e Outgoing Interfaces devono corrispondere alla topologia.
Controllare nel Log Viewer di entrambi i firewall la Rule ID prevista.
In Diagnostics > Packet capture, verificare con il seguente filtro BPF:
```
src host 10.10.10.20 and dst host 239.10.10.10 and udp port 5000
```
Il flusso deve entrare nel firewall A su Port2 e uscire da Port4. Sul firewall B viene ricevuto su Port4 e inoltrato tramite Port3. Verificare quindi il contenuto effettivo sul ricevitore.

La procedura di Packet Capture con Interface, Rule ID, Status e Reason è descritta in Utilizzare Packet Capture su Sophos Firewall.

Per il traffico di controllo è inoltre possibile utilizzare i seguenti filtri BPF durante un test limitato:

ip proto 103

103 indica PIM. IGMP utilizza il protocollo IP 2:

ip proto 2

I filtri mostrano se sono presenti pacchetti PIM e IGMP. Da soli non dimostrano né che l’RP sia corretto né che il flusso dati funzioni.

Nella Advanced Shell, pimd.log fornisce ulteriore contesto. I comandi seguenti sono di sola lettura:

tail -n 200 /log/pimd.log
grep '239.10.10.10' /log/pimd.log | tail -n 100

Un risultato grep vuoto non dimostra un errore; restano determinanti lo stato attuale in WebAdmin e il percorso reale dei pacchetti. File di servizio e log di Sophos Firewall spiega altri file di routing e log.

Isolare gli errori in base al sintomo

Non appare alcun PIM Neighbor

Verificare la raggiungibilità diretta degli IP di transito 10.255.0.1 e 10.255.0.2.
Controllare che Port4 sia selezionato come PIM-enabled interface su entrambi i firewall.
Verificare Dynamic Routing nella zona di transito corretta o nella Local Service ACL Exception appropriata.
Con ip proto 103, controllare se i pacchetti PIM raggiungono e lasciano l’interfaccia di transito.
Assicurarsi che venga utilizzato un tipo di interfaccia documentato da Sophos per PIM.

Il Neighbor è presente, ma RP SET manca o è errato

Confrontare carattere per carattere RP IP e intervallo di gruppi su tutti i router.
Verificare la raggiungibilità unicast di 10.255.0.1.
Con Candidate RP, chiarire prima il ruolo BSR effettivo. Una candidatura configurata non è sufficiente.
Non ampliare a * prima di aver capito perché il gruppo specifico non viene associato.

RP SET è corretto, ma non viene creato alcuno stato multicast

Verificare che il ricevitore abbia realmente aderito al gruppo e alla porta UDP corretti.
Con ip proto 2, cercare IGMP Reports e Queries nella rete dei ricevitori.
Con IGMP Snooping, verificare il ruolo Querier nella VLAN. Non modificare i timer IGMP per tentativi; la procedura di base non richiede modifiche ai timer.
Controllare che il mittente invii realmente a 239.10.10.10:5000.

Lo stato è presente, ma l’Incoming Interface è errata

Eseguire su ogni firewall un Route Lookup verso l’origine 10.10.10.20 e l’RP 10.255.0.1.
Controllare le route statiche, OSPF, SD-WAN e VPN per un percorso migliore inatteso.
Non modificare la Route Precedence globale finché il percorso RPF errato non è dimostrato con tabella di routing e capture.
Documentare separatamente i percorsi di ritorno asimmetrici e le connessioni parallele.

Il flusso lascia il firewall ma non raggiunge il ricevitore

Controllare su entrambi i firewall Rule ID, Status e Outgoing Interface.
Verificare porta dello switch, VLAN e IGMP Snooping nella rete dei ricevitori.
Controllare firewall locale dell’host e applicazione ricevente.
Confrontare un capture sul ricevitore o sulla porta dello switch con i timestamp SFOS.

Considerare i limiti di HA e delle interfacce

In HA Active-Active il multicast non viene distribuito tra i due nodi. Le sessioni UDP, Broadcast e Multicast non vengono trasferite durante il failover. Un cambio di ruolo controllato può quindi interrompere il flusso; successivamente occorre verificare nuovamente Neighbor, RP SET, RPF, stato multicast, regole e ricevitore.

I log sono locali al nodo. In caso di problema HA, salvare i dati del nodo attivo prima del cambio. Non si presume una sincronizzazione hitless dello stato PIM.

Questo articolo di base utilizza interfacce fisiche. Sophos indica inoltre RED e GRE come compatibili con PIM. Ciò non conferma PIM direttamente su interfacce XFRM, IPsec o SSL VPN. Un progetto multicast cifrato o dipendente dal provider richiede quindi un’architettura separata e testata.

Eseguire un rollback sicuro

Il rollback viene eseguito durante la finestra di manutenzione:

Arrestare il flusso di test e documentare l’ultimo stato funzionante o difettoso.
Disattivare le nuove regole firewall multicast.
Disattivare PIM su entrambi i firewall.
Rimuovere Dynamic Routing dalla zona di transito solo se nessun altro protocollo di routing ne dipende.
Riattivare lo Static Multicast Forwarding solo se lo stato precedente e le relative route sono completamente documentati.
Verificare nuovamente accesso di gestione, route unicast e applicazioni precedentemente in produzione.

Per questo rollback non sono necessari riavvii del servizio PIM, opzioni di debug o comandi Advanced Shell non documentati.

Domande frequenti

PIM-SM sostituisce IGMP o la regola firewall?

No. IGMP segnala l’interesse dei ricevitori nella rete locale, PIM-SM collega i router multicast coinvolti e la regola firewall consente il flusso dati specifico tra le zone. Tutti e tre i livelli devono corrispondere allo stesso progetto.

Perché una route unicast influisce sul percorso multicast?

PIM-SM utilizza RPF. In base alle informazioni di routing, il firewall verifica attraverso quale interfaccia sarebbero raggiungibili l’origine o l’RP. Se tale route indica l’interfaccia errata, il percorso di ritorno previsto non corrisponde e lo stato multicast può rimanere errato o incompleto.