Sophos Firewall: reflector mDNS per il rilevamento dei dispositivi tra VLAN

Il reflector mDNS in SFOS 23 consente il rilevamento dei dispositivi tra reti interne e VLAN selezionate. Ad esempio, un client può trovare un ricevitore AirPlay in un’altra VLAN. Il reflector trasmette le richieste di ricerca e gli annunci dei servizi, ma non autorizza automaticamente il successivo traffico applicativo. L’autorizzazione per streaming, stampa o accesso remoto viene pianificata e verificata separatamente.

La procedura breve: in Network > mDNS, attivare mDNS reflector, scegliere in modo mirato IP version, Allowed interfaces e Services, quindi applicare con Apply. Successivamente, testare separatamente il rilevamento, l’utilizzo effettivo e i confini di rete che devono rimanere bloccati.

Questa guida descrive l’interfaccia di SFOS 23. Una guida esistente per SFOS 22 sul routing multicast statico resta una procedura diversa e non sostituisce un reflector. La sola disponibilità della documentazione non dimostra lo stato di rilascio né l’idoneità di una specifica build del firmware.

Distinguere rilevamento e utilizzo

mDNS, ovvero Multicast DNS, viene utilizzato insieme a DNS-SD per il rilevamento locale dei servizi. Bonjour è il nome utilizzato da Apple per i corrispondenti servizi Zero-Configuration. In subnet separate, questa ricerca rimane normalmente all’interno del rispettivo segmento. Il reflector collega il livello di rilevamento delle interfacce esplicitamente selezionate, senza trasformare le reti in un’unica VLAN.

Questo comporta due conseguenze distinte:

• Un dispositivo può diventare visibile anche se la connessione al suo servizio è ancora bloccata. La visibilità non dimostra né la presenza di una regola firewall adeguata né il funzionamento dello streaming.
• Le reti selezionate ricevono informazioni aggiuntive sui servizi offerti. Anche quando il traffico applicativo è bloccato, questa visibilità può essere indesiderata, ad esempio tra la rete ospiti e la rete di gestione.

Allowed interfaces è quindi un confine di sicurezza, non una semplice selezione tecnica. La finestra di configurazione definisce le interfacce partecipanti, non una coppia direzionale di origine e destinazione. Non si deve presumere che solo i client di una VLAN possano vedere i dispositivi nell’altra. Services limita le categorie di servizi riflesse; una categoria, tuttavia, non costituisce un’autorizzazione per ogni host o ogni porta di un’applicazione.

Le interfacce WAN e VPN non sono supportate. Questa impostazione non rende automaticamente un client VPN remoto parte del rilevamento locale. Inoltre, un altro protocollo di ricerca non viene supportato per il solo fatto che un’applicazione utilizzi anche mDNS.

Prerequisiti ed esempio limitato

Prima della modifica sono necessari:

• Una build di SFOS 23 con Network > mDNS, accesso a WebAdmin e un accesso di gestione indipendente.
• Interfacce interne già configurate, con VLAN e reti assegnate correttamente. Zone e interfacce devono corrispondere alla topologia effettiva.
• Un client e un dispositivo noto che offre il servizio, per i quali la ricerca mDNS funzioni già nello stesso segmento.
• Una decisione sulle categorie di servizi che possono essere visibili tra segmenti e l’identificazione delle porte applicative necessarie in base all’applicazione e alla versione del dispositivo utilizzate.
• Un backup della configurazione e una nota sullo stato precedente del reflector, sulla versione IP, sulle interfacce, sulle categorie e sulle regole applicative esistenti.

Per un test AirPlay limitato, si utilizzano ad esempio:

• Client 10.20.20.50 nella VLAN dei dipendenti 10.20.20.0/24, interfaccia firewall Port2.20, zona LAN.
• Ricevitore 10.30.30.20 nella VLAN multimediale 10.30.30.0/24, interfaccia firewall Port2.30, zona dedicata MEDIA.
• IP version: IPv4, perché questo test utilizza esclusivamente IPv4.
• Allowed interfaces: solo Port2.20 e Port2.30.
• Services: solo AirPlay.

Indirizzi, ID VLAN, nomi delle interfacce e la zona di esempio MEDIA vanno sostituiti con quelli della propria configurazione. Il reflector seleziona le interfacce, non questi due singoli host: anche altri dispositivi sulle interfacce coinvolte possono partecipare al rilevamento nell’ambito delle categorie selezionate. Per un confine di fiducia più preciso serve un progetto di segmentazione adeguato, non soltanto regole applicative più restrittive.

In questo esempio, le interfacce ospiti, di gestione e tutte le altre interfacce non coinvolte rimangono escluse. Un primo test riuscito con due interfacce è più significativo di un’autorizzazione ampia, nella quale diventa difficile distinguere cause ed effetti.

Configurare il reflector mDNS

Salvare lo stato precedente e scegliere la versione IP

1. In WebAdmin, aprire Network > mDNS e annotare le impostazioni precedenti. Un reflector disattivato può conservare una configurazione precedente; prima di attivarlo, controllare quindi anche la selezione salvata.
2. Attivare mDNS reflector. Lo stato predefinito documentato è Off.
3. In IP version, scegliere l’opzione effettivamente necessaria: IPv4 riflette solo mDNS IPv4, IPv6 solo mDNS IPv6 e Dual entrambe le versioni.

Per l’esempio si mantiene IPv4. Dual non è un rimedio generico: estende il rilevamento a entrambe le versioni IP. Se in seguito si utilizzano servizi IPv6, anche la raggiungibilità e le regole applicative per IPv6 devono essere pianificate consapevolmente e verificate separatamente.

Limitare interfacce e categorie di servizi

1. In Allowed interfaces, selezionare Port2.20 e Port2.30. Solo le interfacce selezionate partecipano alle richieste di ricerca e agli annunci riflessi; sono supportate al massimo 16 interfacce.
2. In Services, selezionare AirPlay.
3. Prima di applicare, verificare che nessuna interfaccia ospiti, WAN, VPN o di gestione sia stata inclusa accidentalmente nella selezione prevista.
4. Fare clic su Apply. Il firewall riflette immediatamente il traffico di rilevamento supportato tra le interfacce selezionate.

Oltre a AirPlay, sono disponibili AirDrop, Apple File Share, Chromecast, IoT Smart Home, Printer, Remote Desktop, Scanner, Sonos e Spotify Connect. La selezione va adattata alle esigenze effettive. Una categoria di servizi non sostituisce la verifica di eventuali ulteriori prerequisiti dell’applicazione specifica, oltre al rilevamento.

⚠️ Any elabora tutte le categorie di servizi mDNS, comprese quelle non elencate singolarmente. Questo può generare traffico di rete aggiuntivo e compromettere le prestazioni del sistema. Inoltre, amplia l’insieme dei servizi visibili. Non passare a Any solo perché manca un singolo dispositivo; verificare prima il suo rilevamento e la categoria appropriata.

Autorizzare separatamente il traffico applicativo

Per l’utilizzo successivo, creare una regola firewall mirata oppure verificare una regola esistente già adeguata. Nel test, il nome della regola è ad esempio AirPlay-Test-Client-zu-Media, l’origine è l’host 10.20.20.50 in LAN e la destinazione è l’host 10.30.30.20 in MEDIA. I servizi corrispondono alle porte TCP/UDP confermate per questo dispositivo e questa applicazione; attivare il logging per la verifica finale.

Qui non viene fornito intenzionalmente un elenco universale di porte AirPlay da copiare. Le funzioni del dispositivo e le direzioni di connessione necessarie devono essere definite prima dell’autorizzazione. La mancanza di indicazioni del produttore non va compensata con Any. Se l’applicazione richiede anche una connessione avviata dal dispositivo che offre il servizio, questa va motivata separatamente e autorizzata in modo restrittivo. La normale risposta a una connessione esistente non giustifica automaticamente una regola ampia nella direzione opposta.

Non è neppure opportuno creare, sulla base di supposizioni, un’autorizzazione UDP generale come sostituto della configurazione del reflector. La selezione del rilevamento e la regola applicativa svolgono compiti diversi. Le modifiche rimangono limitate al test documentato; altre regole, NAT e route multicast non vengono modificati incidentalmente.

Dimostrare il risultato con tre verifiche separate

1. Rilevamento sulle interfacce selezionate

Dopo Apply, controllare nuovamente la versione IP, la selezione delle interfacce e le categorie salvate. Quindi riavviare la ricerca dei dispositivi dell’applicazione sul client di test. Il risultato atteso è il ricevitore noto nella VLAN multimediale, non semplicemente una voce rimasta da una ricerca precedente.

Se il risultato non è chiaro, avviare una cattura breve e limitata nel tempo in Diagnostics > Packet capture. Per mDNS è adatto questo filtro BPF:

udp port 5353

Il filtro è solo uno strumento di osservazione e non modifica le autorizzazioni. Per il test IPv4, ci si aspetta traffico mDNS con l’indirizzo multicast locale 224.0.0.251. Confrontare interfacce e timestamp: la ricerca viene generata nella rete del client e il corrispondente traffico di rilevamento è visibile anche sull’interfaccia multimediale selezionata? Il contenuto dei pacchetti e una cattura sul client aiutano a verificare se il servizio atteso viene effettivamente annunciato. Un singolo pacchetto o un particolare stato del pacchetto, da soli, non dimostrano che la ricerca sia riuscita. Packet Capture su Sophos Firewall spiega la procedura.

2. Utilizzare il servizio effettivo

Selezionare il ricevitore rilevato e avviare un breve test AirPlay. Il successo significa che la funzione desiderata opera sul ricevitore, non soltanto che ne compare il nome. Nel log della regola o in una cattura separata della coppia di host 10.20.20.50 e 10.30.30.20, verificare indirizzo di destinazione, porte, direzione della connessione e regola corrispondente.

Se il rilevamento riesce ma l’utilizzo no, lasciare inizialmente invariata la selezione del reflector. Verificare ora le regole applicative, le porte effettive, il routing, i firewall locali dei dispositivi e l’applicazione stessa. Un reflector più ampio non risolve il blocco di un servizio applicativo.

3. Controllare i confini non autorizzati

Con una nuova ricerca in un segmento di test escluso, verificare che il servizio non diventi visibile tramite questo reflector. Testare inoltre che le connessioni non autorizzate rimangano bloccate. Cache esistenti e altri gateway di rilevamento possono alterare il risultato; una voce visualizzata senza nuovo traffico di rete corrispondente non è una prova sufficiente di una riflessione indesiderata.

In HA, le impostazioni del reflector vengono sincronizzate tra i dispositivi. La funzione di SFOS 23 supporta il rilevamento anche in caso di failover. Questo non garantisce sessioni applicative senza interruzioni. Utilizzare un test HA già pianificato per verificare nuovamente rilevamento e utilizzo dopo il cambio di ruolo; non avviare un failover in produzione soltanto per questa guida.

Individuare le cause dei problemi in modo mirato

Network > mDNS non è presente oppure manca un’interfaccia

Verificare la versione SFOS installata e la configurazione effettiva delle interfacce. Questa guida presuppone l’interfaccia di SFOS 23. Le interfacce WAN e VPN sono escluse. Documentare un’interfaccia interna mancante o una selezione che non può essere salvata indicando build, tipo di interfaccia e messaggio esatto; il limite di 16 interfacce non deve essere superato. Non aggirare il problema con una route multicast statica o una modifica non documentata nella shell.

Il servizio non viene trovato

Verificare prima nel segmento locale del dispositivo che offre il servizio se il suo rilevamento funziona. Se manca già in quel segmento, i primi elementi da esaminare sono il dispositivo, l’applicazione, l’isolamento dei client WLAN o i filtri di rete locali, non il reflector. Se funziona localmente, controllare la versione IP, entrambe le interfacce selezionate, la categoria di servizi e il risultato effettivamente salvato dopo Apply.

Quindi confrontare la breve cattura mDNS su entrambi i lati. Se la richiesta di ricerca manca già sull’interfaccia del client, verificare il client e il percorso di rete. Se la richiesta è presente ma manca un annuncio del servizio corrispondente, esaminare il dispositivo che offre il servizio. Se l’annuncio è corretto ma il servizio non viene rilevato dal client, verificare il percorso di rete di ritorno verso il client. Apportare le modifiche una alla volta e ripetere ogni volta lo stesso test.

Il servizio è visibile, ma non funziona

Acquisire separatamente il traffico applicativo e analizzare un eventuale drop in base a host, porte e contesto della regola. Ampliare l’autorizzazione solo con valori di cui sia dimostrata la necessità, senza aprire tutti i servizi tra le due VLAN. Anche un indirizzo annunciato ma non raggiungibile dal client può impedire l’utilizzo; verificare l’indirizzo di destinazione effettivo e il relativo percorso di routing.

Compaiono troppi servizi o un carico aggiuntivo

Verificare se Services è impostato su Any, se sono presenti categorie indesiderate e se Allowed interfaces include segmenti aggiuntivi. In caso di ampliamento involontario, ripristinare lo stato precedente annotato. Se il problema è iniziato immediatamente dopo l’attivazione, disattivare il reflector in modo controllato e ripetere lo stesso test limitato. Non introdurre riavvii dei servizi o reflector aggiuntivi sulla base di supposizioni.

Se il problema persiste, conservare per l’escalation build, versione IP, interfacce coinvolte, categorie, indirizzi degli host anonimizzati, timestamp e brevi catture di entrambi i lati. I dati dei clienti e i payload dei pacchetti non necessari non devono essere inclusi in un esempio di supporto pubblico.

Eseguire un rollback sicuro

1. Terminare il test e documentare il risultato e le ultime impostazioni salvate.
2. Se il reflector era precedentemente disattivato, disattivarlo nuovamente in Network > mDNS e applicare con Apply. Se era già attivo, ripristinare invece la versione IP e la selezione di interfacce e categorie annotate in precedenza, quindi applicare; non disattivare indiscriminatamente altri servizi dipendenti.
3. Disattivare solo la regola applicativa aggiunta per questo test oppure annullare la modifica documentata a una regola esistente.
4. Riaprire le impostazioni e verificare con una nuova ricerca il rilevamento, i servizi preesistenti e le connessioni che devono rimanere bloccate.

Quando viene disattivato, il reflector conserva la propria configurazione; alla successiva attivazione viene riutilizzata la selezione precedente. Disattivarlo quindi non elimina i confini di fiducia salvati. Prima di ogni successiva riattivazione, verificare nuovamente interfacce e categorie. Le voci di rilevamento già presenti sul client possono continuare a essere visualizzate dopo il rollback, e un’applicazione già in esecuzione non dimostra che il nuovo traffico di rilevamento continui a essere riflesso.