Per què el multicast no travessa una VPN sense un pla

Dos llocs poden abastar-se perfectament per unicast i, tot i així, comportar-se com si un d’ells no veiés l’anunci de descoberta de la impressora, el flux IPTV o el batec del clúster. Això no és un túnel trencat; és la diferència entre una destinació i un grup. El lliurament multicast necessita un model de pertinença, estat de reenviament al llarg del camí i una interfície disposada a portar el trànsit, i res d’això no ve d’una ruta unicast. Recórrer del grup de l’aplicació a un receptor que funcioni és el camí més curt cap a una resposta.

Comenceu pel grup i l’aplicació

Pregunteu quina adreça de grup fa servir l’aplicació i per a què és el trànsit. Un protocol de descoberta que anuncia serveis, un flux d’emissió i els paquets de salut d’un protocol d’encaminament són tres problemes diferents amb tres respostes acceptables diferents. L’adreça de grup mateixa us diu l’abast: les adreces del bloc de control de xarxa local no estan pensades perquè l’encaminament ordinari les reenviï fora de l’enllaç, i les aplicacions que les fan servir solen pressuposar un únic domini de difusió. Un flux d’emissió en un grup d’abast global és un disseny diferent d’un protocol de descoberta que espera que cada dispositiu senti cada consulta, i només el segon es preocupa per la mida del domini de difusió.

Decidiu si el requisit és el servei o el mecanisme de descoberta, perquè aquestes respostes difereixen en cost en un ordre de magnitud. Un demana una adreça que no canviï; l’altre demana un domini de difusió estès per un enllaç d’àrea àmplia amb tot el que se’n deriva.

La descoberta d’enllaç local ha d’aturar-se

El Multicast DNS descrit a RFC 6762 està dissenyat al voltant d’un sol enllaç: les consultes van a un grup fix, les respostes s’envien al mateix grup, i el protocol depèn que cada participant senti tothom. Els encaminadors no reenvien aquest trànsit per defecte, i això és una decisió de disseny, no un descuit. La frontera existeix perquè un dispositiu d’un edifici no pugui anunciar-se casualment en un altre. Un túnel que sembla arreglar la descoberta portant el grup a tot arreu ha eliminat aquesta frontera per a cada aplicació, no només per a la que necessitava ajuda.

Els repetidors i els reflectors existeixen, i són serveis reals amb conseqüències reals: cada nom anunciat en un lloc es fa visible a l’altre, inclosos noms de dispositiu que identifiquen persones o equipament. Si el requisit real és que un servei concret sigui localitzable, un registre de servei publicat al DNS sol ser el canvi més petit, i revela un nom en lloc d’un flux de noms.

Tres coses que necessita el multicast encaminat

El multicast encaminat necessita tres coses treballant juntes: receptors que s’uneixin al grup, encaminadors que mantinguin estat de reenviament per a ell, i un túnel que tracti les adreces de grup com a trànsit a portar. Un túnel amb una política que només llisti subxarxes unicast deixarà caure el trànsit del grup a la frontera de xifrat, i per això el primer símptoma sovint és silenci i no un error. Una interfície basada en rutes, com un túnel GRE o VTI, porta el que la taula d’encaminament hi enviï, cosa que fa el grup abastable un cop existeix l’estat multicast.

L’abastabilitat de la font és la segona meitat. Els protocols d’encaminament multicast com PIM construeixen arbres de distribució comprovant que el camí de tornada a la font és l’esperat, així que una ruta unicast que apunta a un altre lloc trenca l’arbre fins i tot quan la pertinença al grup és correcta. Instal·lar una ruta per al receptor no fa res per a aquesta comprovació, i aquest és l’error que produeix un ping que funciona i un flux que falla. Verifiqueu primer el camí de retorn de la font, després afegiu la pertinença i només llavors mireu l’aplicació.

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

Les dues primeres línies mostren a què s’ha unit l’amfitrió i què reenvia el nucli, la tercera mostra la pertinença de l’aplicació mateixa, i l’última el camí unicast que farà servir la comprovació de camí invers. Llegir-les juntes distingeix una aplicació que mai no s’ha unit d’una xarxa que mai no ha reenviat.

Demostreu-ho amb una font i un receptor

Abans de tocar cap configuració, confirmeu que l’aplicació funciona en un sol segment. Si falla localment, l’encaminament multicast no és el problema i cap canvi de túnel no ajudarà. Després repetiu amb un receptor a través del túnel i observeu els paquets als dos costats de la frontera de xifrat.

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

Els paquets visibles dins del túnel però absents fora apunten a encapsulació o política; els paquets visibles als dos costats sense progrés de l’aplicació apunten a la pertinença del receptor o a l’enllaç de l’aplicació. Mantingueu les captures curtes i filtrades, perquè una captura multicast àmplia en un segment ocupat és sobretot soroll.

Preferiu una adreça de servei quan només us cal el servei

La descoberta existeix per trobar una cosa que es mou. Un servidor amb un nom estable no necessita descoberta, i una adreça documentada al DNS privat respon la pregunta real de l’usuari sense estendre un domini de difusió per un enllaç d’àrea àmplia. El mateix raonament s’aplica a impressores, electrodomèstics i serveis web interns. Un nom al DNS és abastable des de cada lloc que el necessita mentre no anuncia res als llocs que no el necessiten, i continua funcionant quan el dispositiu se substitueix per un altre amb una adreça diferent.

Quan un protocol requereix genuïnament multicast, limiteu-lo al grup i als llocs que el necessiten, documenteu per què i reviseu la decisió quan l’aplicació canviï. Estendre la descoberta a tot arreu és fàcil de fer un cop, i difícil de desfer després d’un any de dispositius que en depenen en silenci.