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.
Inventariare le route multicast statiche esistenti e pianificare la migrazione nella finestra di manutenzione.
In Routing > Multicast (PIM-SM) attivare PIM sulle interfacce IPv4 coinvolte.
Configurare l’RP statico previsto e l’intervallo di gruppi su tutti i router PIM.
Controllare il flusso dati multicast con regole firewall IPv4 restrittive e registrate.
Verificare insieme adesione al gruppo, applicazione UDP, neighbor PIM, RP SET, stato multicast, Rule ID e percorso dei pacchetti.

⚠️ Il passaggio dalle route multicast statiche a PIM-SM modifica il percorso multicast in produzione. Occorre quindi documentare route, gruppi e ricevitori esistenti, oltre al piano di rollback. La guida di SFOS 22 descrive separatamente Static Multicast Forwarding e PIM-SM, ma non indica una regola generale di coesistenza o esclusione. Verificare il build effettivamente utilizzato durante la finestra di manutenzione, anziché presumere che possano funzionare in parallelo.

Questo articolo tratta il routing multicast IPv4 dinamico con un RP statico. SFOS 22 supporta PIM versione 2 e PIM-SM; Sophos documenta BSR per la selezione dinamica dell’RP. L’esempio resta volutamente basato sull’RP statico. Candidate RP e BSR vengono solo contestualizzati più avanti.

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 richiede almeno un’interfaccia PIM con un indirizzo IPv4. Indica come supportate le interfacce fisiche, RED e le interfacce GRE; 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 utilizzati senza test in questa configurazione di base.

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.

Inventariare lo Static Multicast Forwarding esistente

In Routing > Static routes si documentano le route multicast esistenti, le applicazioni dipendenti e le interfacce di destinazione. La guida di SFOS 22 non stabilisce se Enable multicast forwarding e PIM-SM possano essere configurati in parallelo su ogni build. Modificare quindi lo stato esistente solo durante la finestra di manutenzione e annotare la risposta dell’interfaccia.

Non eliminare preventivamente le route multicast statiche esistenti. Rimangono un modello di rollback documentato finché PIM-SM non è stato verificato completamente. Se SFOS richiede di disattivare il forwarding statico prima di attivare PIM, questo passaggio fa parte della migrazione pianificata e non costituisce una regola generale del prodotto qui presunta senza riscontri.

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
Salvare. Solo dopo la configurazione completa il neighbor PIM, l’associazione dell’RP e lo stato multicast mostrano se la topologia funziona.

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. Sul firewall B, la tabella di routing unicast deve indicare Port4 e 10.255.0.1 come percorso previsto; sul firewall A, la RP IP è l’indirizzo di una propria interfaccia. Un valore salvato non è sufficiente: in Routing > Information > PIM-SM > RP SET, il gruppo deve poi risultare effettivamente associato a questo RP.

Salvare la configurazione. Se SFOS non consente di attivare PIM, controllare il messaggio dell’interfaccia e lo stato corrente di Enable multicast forwarding. Modificare questa opzione solo se l’interfaccia conferma effettivamente il conflitto sul build utilizzato e il percorso di rollback è documentato.

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, fino a otto indicazioni di gruppo o rete, una priorità da 1 a 255 con valore predefinito 1 e un intervallo Advertisement da 30 a 180 secondi con valore predefinito 60.

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. Le normali regole firewall di SFOS controllano il traffico tra zone e reti. Il seguente modello a due regole è quindi una configurazione Avanet strettamente limitata a questa topologia, non un modello PIM obbligatorio documentato da Sophos.

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. In Packet Capture, valutare insieme Rule ID, Status, Reason e le interfacce di ingresso e uscita. La guida di SFOS 22 non documenta un significato generale per la Rule ID 0; questo valore da solo non dimostra quindi che nessuna regola abbia trovato corrispondenza.

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. Il sistema operativo deve aderire al gruppo 239.10.10.10 e l’applicazione deve inoltre restare in ascolto 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; i PIM timers e i flag bits forniscono ulteriore contesto diagnostico.
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 sistema operativo del ricevitore abbia aderito al gruppo corretto e che l’applicazione sia in ascolto su UDP 5000.
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.

Log e report non vengono sincronizzati tra i nodi HA. In caso di problema HA, salvare quindi i dati del nodo che gestiva il traffico prima del cambio. La guida HA ufficiale non documenta un trasferimento dello stato specifico per PIM; l’articolo non ne deduce alcuna affermazione più ampia sulla sincronizzazione.

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.
Se lo Static Multicast Forwarding è stato disattivato durante la migrazione, ripristinare lo stato precedente documentato insieme alle relative route.
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.