Vai al contenuto
Avanet

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. Creare per il flusso una regola firewall IPv4 restrittiva con logging.
  5. Fare aderire un ricevitore reale al gruppo e avviare il flusso.
  6. Controllare route, Rule ID, ingresso e uscita con mroute show, Log Viewer e Packet Capture.

⚠️ Static Multicast Forwarding e PIM-SM non possono essere configurati contemporaneamente su Sophos Firewall. Per Static Multicast Forwarding, PIM deve essere disattivato. Prima di passare da un metodo all’altro, verificare se PIM-SM o un’altra route multicast statica sono già utilizzati in produzione.

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.

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, controllare innanzitutto se PIM-SM è attivo. I due metodi non possono essere configurati in parallelo. Non disattivare PIM-SM prima di averne documentato i vicini, i gruppi e i ricevitori esistenti.

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.

Limitare in modo restrittivo la regola firewall

La route multicast determina il percorso, ma non autorizza da sola il flusso di dati. Per l’inoltro da DMZ a LAN si crea una regola firewall IPv4 dedicata:

  • Rule name: DMZ_to_LAN_Multicast_5000
  • Action: Accept
  • Log firewall traffic: attivato
  • Source zone: DMZ
  • Source network: Host 10.10.10.20
  • Destination zone: LAN
  • Destination network: Host 239.10.10.10
  • Services: un servizio UDP dedicato con Destination Port 5000

La destinazione è il gruppo multicast, non la rete dei ricevitori 10.20.20.0/24. La regola viene limitata al mittente reale, al gruppo effettivo e al servizio necessario. In questo esempio non si utilizza una regola ampia Any né un’autorizzazione generale per IGMP o PIM.

La regola rappresenta la configurazione di destinazione restrittiva per questa topologia di esempio; il suo match effettivo deve essere confermato sulla versione SFOS in uso mediante la Rule ID prevista. Se compare Rule 0, la regola non viene ampliata senza controllo, ma viene analizzata con Log Viewer e Packet Capture.

In questo esempio non è previsto SNAT, in modo da mantenere origine e associazione (S,G). Le regole NAT esistenti vengono comunque controllate per rilevare un match imprevisto. 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 Log Viewer, verificare se corrisponde DMZ_to_LAN_Multicast_5000 o la Rule ID prevista.

  4. 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
    
  5. Nell’elenco dei pacchetti, controllare se il flusso arriva su Port2 e appare su Port3 con stato Forwarded.

  6. 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, Rule ID 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 se PIM-SM è ancora attivo. Static Multicast Forwarding e PIM-SM non possono essere configurati contemporaneamente.
  • 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 esiste già una route, controllare se la stessa combinazione (S,G) è già configurata.

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 regola firewall prevista corrisponde oppure la cattura mostra un’altra Rule ID o Rule 0?
  • Port3 è realmente selezionata come Destination Interface?
  • Una regola NAT modifica l’origine in modo imprevisto?

Il flusso lascia il firewall, ma non raggiunge il ricevitore

  • Controllare il TTL del mittente e l’impostazione globale multicast-decrement-ttl. Non modificare l’impostazione in modo generalizzato.
  • 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 un cluster HA, il multicast non viene bilanciato tra i due nodi. Dopo un failover pianificato, controllare nuovamente route, Rule ID, ingresso, uscita e ricevitore. Sophos non documenta alcuna garanzia di failover multicast senza interruzioni; pertanto, il test deve essere eseguito in una finestra di manutenzione. Salvare log e Packet Captures sul nodo attualmente attivo.

Eseguire un rollback sicuro

Prima del rollback, documentare route, nome della regola e valori di test precedenti. Quindi:

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

Per questo rollback non è necessario un comando CLI di eliminazione. In questo modo il rollback rimane tracciabile e si evita la sintassi di eliminazione documentata pubblicamente in modo incoerente.

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.

Questa route consente di trovare dispositivi Bonjour, AirPlay o Chromecast tra VLANs?

Non da sola. mDNS utilizza 224.0.0.251, è link-local e richiede una funzione di reflection o gateway dedicata per l’inoltro tra VLANs.

Perché serve una regola firewall aggiuntiva?

La route multicast indica dove viene inoltrato il flusso. La regola firewall continua a determinare se questa specifica origine, gruppo e servizio UDP possono passare tra le zone coinvolte.