Perché il multicast non attraversa una VPN senza un piano

Due sedi possono raggiungersi perfettamente via unicast e comportarsi comunque come se una delle due non vedesse l’annuncio di rilevamento della stampante, il flusso IPTV o il battito del cluster. Non è un tunnel rotto; è la differenza tra una destinazione e un gruppo. La consegna multicast richiede un modello di appartenenza, stato di inoltro lungo il percorso e un’interfaccia disposta a trasportare il traffico, e nulla di tutto ciò proviene da una rotta unicast. Andare dal gruppo dell’applicazione a un ricevitore che funziona è il percorso più breve verso una risposta.

Iniziate dal gruppo e dall’applicazione

Chiedete quale indirizzo di gruppo usa l’applicazione e a cosa serve il traffico. Un protocollo di rilevamento che annuncia servizi, un flusso di streaming e i pacchetti di hello di un protocollo di routing sono tre problemi diversi con tre risposte accettabili diverse. L’indirizzo di gruppo stesso dice l’ambito: gli indirizzi del blocco di controllo della rete locale non sono pensati per essere inoltrati fuori dal collegamento dal routing ordinario, e le applicazioni che li usano di solito presuppongono un unico dominio di broadcast. Un flusso di streaming su un gruppo con ambito globale è un progetto diverso da un protocollo di rilevamento che si aspetta che ogni dispositivo senta ogni query, e solo il secondo si preoccupa della dimensione del dominio di broadcast.

Decidete se il requisito è il servizio o il meccanismo di rilevamento, perché queste risposte differiscono in costo di un ordine di grandezza. Una chiede un indirizzo che non cambia; l’altra chiede un dominio di broadcast esteso su un collegamento geografico con tutto ciò che ne consegue.

Il rilevamento locale dovrebbe fermarsi

Il Multicast DNS descritto in RFC 6762 è progettato attorno a un solo collegamento: le query vanno a un gruppo fisso, le risposte sono inviate allo stesso gruppo e il protocollo conta sul fatto che ogni partecipante senta tutti. I router non inoltrano quel traffico per impostazione predefinita, ed è una decisione di progetto, non una svista. Il confine esiste perché un dispositivo in un edificio non possa annunciarsi con nonchalance in un altro. Un tunnel che sembra sistemare il rilevamento portando il gruppo ovunque ha rimosso quel confine per ogni applicazione, non solo per quella che aveva bisogno di aiuto.

I ripetitori e i riflettori esistono, e sono servizi reali con conseguenze reali: ogni nome annunciato in una sede diventa visibile nell’altra, compresi i nomi dei dispositivi che identificano persone o attrezzature. Se il requisito reale è che un servizio specifico sia individuabile, un record di servizio pubblicato nel DNS è di solito la modifica più piccola, e rivela un nome invece di un flusso di nomi.

Tre cose che il multicast instradato richiede

Il multicast instradato richiede tre cose che lavorano insieme: ricevitori che si uniscono al gruppo, router che ne mantengono lo stato di inoltro e un tunnel che tratta gli indirizzi di gruppo come traffico da trasportare. Un tunnel con una politica che elenca solo sottoreti unicast farà cadere il traffico del gruppo al confine della crittografia, ed è per questo che il primo sintomo è spesso silenzio invece di un errore. Un’interfaccia basata su rotte, come un tunnel GRE o VTI, trasporta ciò che la tabella di routing vi invia, il che rende il gruppo raggiungibile una volta che lo stato multicast esiste.

La raggiungibilità della sorgente è la seconda metà. I protocolli di routing multicast come PIM costruiscono alberi di distribuzione verificando che il percorso di ritorno alla sorgente sia quello atteso, quindi una rotta unicast che punta altrove rompe l’albero anche quando l’appartenenza al gruppo è corretta. Installare una rotta per il ricevitore non fa nulla per quella verifica, ed è l’errore che produce un ping funzionante e un flusso che fallisce. Verificate prima il percorso di ritorno della sorgente, poi aggiungete l’appartenenza e solo dopo guardate l’applicazione.

ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20

Le prime due righe mostrano a cosa si è unito l’host e cosa inoltra il kernel, la terza mostra l’appartenenza dell’applicazione stessa e l’ultima il percorso unicast che userà la verifica del percorso inverso. Leggerle insieme distingue un’applicazione che non si è mai unita da una rete che non ha mai inoltrato.

Dimostratelo con una sorgente e un ricevitore

Prima di toccare una configurazione, confermate che l’applicazione funzioni su un solo segmento. Se fallisce localmente, il routing multicast non è il problema e nessuna modifica al tunnel aiuterà. Poi ripetete con un ricevitore attraverso il tunnel e osservate i pacchetti su entrambi i lati del confine di crittografia.

tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'

I pacchetti visibili dentro il tunnel ma assenti fuori indicano incapsulamento o politica; i pacchetti visibili su entrambi i lati senza progresso dell’applicazione indicano l’appartenenza del ricevitore o il binding dell’applicazione. Mantenete le catture brevi e filtrate, perché una cattura multicast ampia su un segmento occupato è soprattutto rumore.

Preferite un indirizzo di servizio quando serve solo il servizio

Il rilevamento esiste per trovare qualcosa che si muove. Un server con un nome stabile non ha bisogno di rilevamento, e un indirizzo documentato in un DNS privato risponde alla domanda reale dell’utente senza estendere un dominio di broadcast su un collegamento geografico. Lo stesso ragionamento vale per stampanti, elettrodomestici e servizi web interni. Un nome nel DNS è raggiungibile da ogni sede che ne ha bisogno senza annunciare nulla alle sedi che non ne hanno, e continua a funzionare quando il dispositivo viene sostituito da uno con un indirizzo diverso.

Quando un protocollo richiede davvero il multicast, limitatelo al gruppo e alle sedi che ne hanno bisogno, documentate il perché e riesaminate la decisione quando l’applicazione cambia. Estendere il rilevamento ovunque è facile una volta, e difficile da annullare dopo un anno di dispositivi che ne dipendono in silenzio.