Configurare e testare il multicast statico su Sophos Firewall

Una route multicast statica inoltra il flusso di dati di un mittente noto a un gruppo multicast fisso attraverso interfacce selezionate. È adatta, ad esempio, a un flusso video, audio o di telemetria la cui origine, gruppo e reti dei ricevitori rimangono fissi.

Questa procedura tratta il routing multicast IPv4 statico. Il multicast IPv6 non rientra in questa guida.

La procedura breve è la seguente:

1. Documentare IP di origine, gruppo multicast, porta UDP e interfacce di ingresso e uscita.
2. In Routing > Static routes, attivare Enable multicast forwarding.
3. In Manage multicast route > Add, inserire origine, gruppo e interfacce.
4. Fare aderire un ricevitore reale al gruppo e avviare il flusso.
5. Controllare route, ingresso e uscita con mroute show e Packet Capture.

⚠️ Enable multicast forwarding è un’impostazione globale. Prima di attivarla, inventariare le configurazioni PIM-SM esistenti, le route multicast statiche e i flussi che ne dipendono. Verificare dapprima la modifica con un flusso di test limitato; in caso di comportamento imprevisto, annullarla prima di aggiungere altre Destination Interfaces.

Comprendere multicast, IGMP e la route statica

Con unicast, un host invia a un singolo indirizzo di destinazione. Con multicast, l’origine invia una volta a un indirizzo di gruppo e più ricevitori possono aderire allo stesso flusso. Il firewall non copia il flusso verso reti qualsiasi, ma solo verso le Destination Interfaces inserite nella route multicast.

L’esempio utilizza la combinazione fissa del mittente 10.10.10.20 e del gruppo 239.10.10.10. Questa combinazione viene comunemente chiamata Source and Group, abbreviata in (S,G). Se l’applicazione cambia IP di origine o gruppo, la route non corrisponde più.

IGMP segnala nel segmento IPv4 locale che un ricevitore vuole aderire a un gruppo multicast o abbandonarlo. Uno switch con IGMP Snooping può quindi inviare il flusso solo alle porte con ricevitori interessati. La route Sophos statica non apprende però nuove Destination Interfaces da IGMP: Port3 rimane configurata in modo fisso anche quando in quel momento nessun ricevitore è in ascolto.

PIM-SM risolve un’altra esigenza. Crea dinamicamente percorsi multicast tra più router multicast e richiede una progettazione pianificata del Rendezvous Point e del routing unicast. Per un singolo mittente noto e poche interfacce dei ricevitori fisse, la route statica è solitamente più chiara. Con più router, gruppi variabili o molti percorsi multicast, PIM-SM richiede una progettazione dedicata.

Una route multicast statica non è inoltre una normale route unicast statica. Non utilizza un next hop classico e appare in un’area separata.

mDNS è un altro caso d’uso

mDNS per Bonjour, AirPlay o molte ricerche Chromecast utilizza l’indirizzo link-local 224.0.0.251. Sophos consente gruppi da 224.0.2.0 a 239.255.255.255 in una route multicast statica. mDNS non rientra in questo intervallo e non viene inoltrato dai router come normale traffico multicast.

Questa guida non sostituisce quindi un reflector mDNS o un Discovery Gateway. Un flusso multimediale può funzionare tramite multicast mentre il rilevamento automatico dei dispositivi tra VLANs continua a non funzionare.

A partire da SFOS 23, questa attività di rilevamento separata viene configurata tramite il reflector mDNS in Network > mDNS. La selezione delle interfacce interne e delle categorie di servizi, insieme all’autorizzazione separata del traffico applicativo, fa parte di questa procedura dedicata; la route multicast statica descritta qui non viene sostituita.

Pianificare la topologia di esempio

L’esempio utilizza i seguenti valori:

• Mittente: 10.10.10.20
• Source Interface: Port2
• Source Zone: DMZ
• Gruppo multicast: 239.10.10.10
• Servizio applicativo: UDP 5000
• Destination Interface: Port3
• Destination Zone: LAN
• Rete dei ricevitori: 10.20.20.0/24
• Ricevitore di test: 10.20.20.50

10.10.10.20 e 10.20.20.0/24 sono valori di esempio privati. 239.10.10.10 appartiene all’intervallo multicast con ambito amministrativo ed è adatto a un esempio locale controllato. Nell’ambiente reale, sostituire insieme origine, gruppo, porta e interfacce con i valori dell’applicazione e della topologia. Il gruppo non deve essere cambiato arbitrariamente: mittente e ricevitori devono utilizzare lo stesso indirizzo e lo stesso servizio.

L’applicazione deve inoltre inviare con un TTL sufficiente. Nel routing normale, il TTL viene ridotto di uno a ogni hop. Se l’applicazione invia con TTL 1, il flusso non raggiunge un altro segmento quando la riduzione del TTL è attiva.

Prima della modifica, devono essere chiari i seguenti punti:

• Il firewall funziona in Gateway Mode.
• Il mittente raggiunge Port2 e i ricevitori si trovano dietro Port3.
• L’applicazione ricevente può aderire effettivamente al gruppo 239.10.10.10 su UDP 5000.
• PIM-SM esistente, altre route multicast e le relative dipendenze sono documentati.
• Sono noti switch, VLANs e impostazioni IGMP Snooping nella rete dei ricevitori.
• Sono disponibili un backup della configurazione e un accesso di gestione indipendente.

Configurare zone e interfacce Sophos Firewall spiega come si collegano interfacce, VLANs e zone.

Creare la route multicast statica

Attivare Multicast Forwarding

1. In WebAdmin, aprire Routing > Static routes.
2. In Multicast forwarding setting, selezionare Enable multicast forwarding.
3. Fare clic su Apply, quindi su OK.

Se non è possibile attivare l’opzione, verificare la configurazione multicast esistente. Una configurazione PIM-SM esistente non deve essere modificata senza pianificazione: nelle pagine pertinenti, la guida attuale di SFOS 22 non documenta una regola generale di coesistenza. Sono quindi determinanti il comportamento della build installata e la progettazione di rete approvata.

Inserire origine, gruppo e interfacce

1. In Manage multicast route, fare clic su Add.
2. In Source IPv4 address, inserire 10.10.10.20.
3. Selezionare Port2 come Source interface.
4. In Multicast IPv4 address, inserire 239.10.10.10.
5. Selezionare Port3 come Destination interface.
6. Salvare con Save.

WebAdmin può salvare più Destination Interfaces in una route. Tuttavia, ogni interfaccia aggiuntiva amplia l’area verso cui viene inoltrato il flusso. Deve essere selezionata solo quando sono realmente presenti ricevitori e anche l’autorizzazione di sicurezza è adeguata. Source Interface e Destination Interface non possono essere identiche.

Utilizzare la CLI come percorso alternativo controllato

Nella Device Console, il percorso è 3. Route Configuration > 2. Configure Multicast Routing. Multicast Forwarding deve essere attivo prima di aggiungere la prima route. Può essere abilitato in Gateway Mode e Transparent Mode, ma le route Multicast statiche possono essere configurate solo in Gateway Mode. Nell’opzione 1, questo comando abilita l’inoltro globale:

enable multicast-forwarding

⚠️ Secondo Sophos, comandi Device Console incompleti possono impedire ad access_server di rispondere. Completare la sintassi con ? o Tab in base alla build installata ed eseguire il comando completo solo dopo questa verifica.

In 2. Configure Static-routes è possibile aggiungere una route tra due interfacce statiche e verificarla subito:

mroute add input-interface Port2 source-ip 10.10.10.20 dest-ip 239.10.10.10 output-interface Port3
mroute show

La CLI richiede una voce mroute add separata per ogni interfaccia di uscita. Offre solo interfacce statiche, mentre WebAdmin può mostrare anche interfacce dinamiche come DHCP e PPPoE. Le interfacce di ingresso e uscita devono essere diverse; un’interfaccia non Ethernet come IPsec0 non appartiene a questa forma basata sulle porte.

Per rimuovere in modo mirato una route fisica, Sophos specifica i valori in ordine posizionale. Prima si verificano i nomi delle interfacce con mroute show:

mroute del Port2 10.10.10.20 239.10.10.10 Port3
mroute show

Sophos pubblica forme input-tunnel e output-tunnel separate per le route IPsec e GRE, ma gli esempi non usano sempre la stessa grafia. Il completamento dei comandi della versione SFOS installata è il riferimento; non si incolla un esempio pubblico senza verifica.

Non presumere che sia necessaria un’autorizzazione di sicurezza

La procedura ufficiale di SFOS 22 per creare una route multicast statica non indica alcuna regola firewall o NAT aggiuntiva. In questo esempio, pertanto, non viene creata preventivamente una regola ampia Any. Utilizzare Packet Capture per determinare dallo stato effettivo dei pacchetti se la build installata o una policy esistente richiedano comunque un match aggiuntivo.

Se il firewall mostra un drop dovuto a una policy, non procedere per tentativi. Registrare dapprima l’origine 10.10.10.20, il gruppo 239.10.10.10, UDP 5000, le zone coinvolte e il contesto della regola visualizzato. Solo dopo aver confermato il requisito per la build in uso, limitare un’autorizzazione esattamente a questi valori e attivarne il logging. Configurare in modo sicuro le regole Sophos Firewall spiega la struttura generale delle regole.

Testare il flusso di dati in modo controllato

Una route salvata non dimostra che il ricevitore ottenga il flusso. La verifica segue il pacchetto dall’applicazione al client:

1. Su 10.20.20.50, avviare l’applicazione ricevente e aderire al gruppo 239.10.10.10 su UDP 5000.

2. Avviare un flusso di test chiaramente limitato da 10.10.10.20 e annotare ora di inizio e durata prevista.

3. In Diagnostics > Packet capture, filtrare con questa espressione BPF:

   src host 10.10.10.20 and dst host 239.10.10.10 and udp port 5000
   

4. Nell’elenco dei pacchetti, controllare se il flusso arriva su Port2 e appare su Port3 con stato Forwarded. In caso di drop, annotare lo stato visualizzato e il contesto della regola senza ampliare una regola sulla base di una supposizione.

5. Sul ricevitore, verificare che arrivino pacchetti e che l’applicazione elabori il contenuto.

Utilizzare Packet Capture su Sophos Firewall spiega la procedura Packet Capture con interfaccia, contesto della regola e stato.

La tabella di routing multicast statico può essere visualizzata anche in sola lettura nella Device Console. Il percorso è 3. Route Configuration > 2. Configure Multicast Routing > 2. Configure Static-routes:

mroute show

L’output deve mostrare origine, gruppo e interfacce di ingresso e uscita previsti. Il comando non modifica la configurazione.

Per una risoluzione dei problemi più approfondita, la documentazione attuale di SFOS 22 indica mrouting.log. Nell’Advanced Shell si leggono solo le ultime voci:

tail -n 200 /log/mrouting.log

Altri file e associazioni dei servizi sono elencati in File di servizio e log di Sophos Firewall.

Delimitare l’errore in base al sintomo

Non è possibile attivare o salvare la route

• Controllare IP di origine, intervallo del gruppo e interfacce. Sono consentiti gruppi da 224.0.2.0 a 239.255.255.255.
• Source Interface e Destination Interface non possono essere identiche.
• Se la combinazione (S,G) esiste già, confrontare anche la Destination Interface. Per più uscite, la CLI richiede una voce distinta con la stessa origine e lo stesso gruppo per ciascuna di esse.

Il flusso arriva, ma non viene inoltrato

• L’IP di origine reale e il gruppo corrispondono esattamente alla route?
• mroute show mostra le interfacce previste?
• La cattura mostra Forwarded oppure un drop con un contesto della regola utilizzabile?
• Port3 è realmente selezionata come Destination Interface?

Il flusso lascia il firewall, ma non raggiunge il ricevitore

• Controllare il TTL del mittente. Non modificare parametri globali di routing sulla base di supposizioni.
• Controllare VLAN, porta dello switch e IGMP Snooping nella rete dei ricevitori.
• Assicurarsi che 10.20.20.50 aderisca al gruppo e alla porta UDP corretti.
• Controllare il firewall locale dell’host e l’applicazione sul ricevitore.
• Confrontare una cattura sul ricevitore o sulla porta dello switch con i timestamp SFOS.

Il rilevamento dei dispositivi non funziona, ma il flusso sì

I protocolli di rilevamento come mDNS sono link-local e non vengono riflessi da questa route statica. Verificare separatamente il flusso di dati effettivo e il rilevamento dei dispositivi.

Gestire separatamente VPN e HA

Sophos non supporta il multicast tramite SSL VPN. Le route multicast statiche tramite IPsec o un tunnel GRE già validato sono possibili e utilizzano forme CLI specifiche. Per IPsec, Sophos richiede inoltre un host unicast esplicito con /32 nella configurazione VPN. Gli esempi documentati pubblicamente contengono varie notazioni incoerenti, quindi non devono essere copiati senza verifica in un firewall di produzione.

Anche la versione del firmware è importante quando il multicast attraversa un tunnel VPN. La risoluzione dei problemi IPsec per NC-180433 tratta i crash ripetuti del firewall che coincidono con questo traffico. Il problema è risolto in SFOS 22.0 MR2 Build 546; una normale perdita di pacchetti o un flusso assente non dimostrano questo caso specifico.

In HA Active-Active, il multicast non viene bilanciato tra i due nodi. Sophos esclude inoltre il multicast dal Session Failover. In caso di cambio di ruolo è quindi prevedibile un’interruzione del flusso. Prima del failover, salvare la cattura e i timestamp sul nodo precedentemente attivo; successivamente, verificare di nuovo route, ingresso, uscita e ricevitore sul nuovo nodo attivo.

Eseguire un rollback sicuro

Prima del rollback, documentare route, interfacce e valori di test precedenti. Quindi:

1. Arrestare il flusso di test.
2. Rimuovere la route multicast statica in WebAdmin.
3. Disattivare Enable multicast forwarding solo se nessun’altra route multicast statica ne dipende.
4. Verificare nuovamente lo stato precedente delle applicazioni e delle reti interessate.

Se la route di esempio è stata invece creata tramite CLI, rimuoverla con il comando mroute del ufficialmente documentato sopra per le interfacce fisiche e verificare il risultato con mroute show. Per le route tramite tunnel non viene riportato alcun esempio di eliminazione non confermato.

Domande frequenti

Quando una route multicast statica è preferibile a PIM-SM?

La route statica è solitamente più semplice quando mittente, gruppo e poche Destination Interfaces rimangono fissi. PIM-SM è adatto a più router multicast, percorsi dinamici e molti gruppi variabili.