Por que o multicast non cruza unha VPN sen un plan

Dous sitios poden alcanzarse perfectamente por unicast e aínda así comportarse como se un deles non vise o anuncio de descubrimento da impresora, o fluxo IPTV ou o latexo do clúster. Iso non é un túnel roto; é a diferenza entre un destino e un grupo. A entrega de multicast necesita un modelo de pertenza, estado de reenvío ao longo do camiño e unha interface disposta a transportar o tráfico, e nada diso vén dunha ruta unicast. Percorrer do grupo da aplicación a un receptor que funcione é o camiño máis curto cara a unha resposta.

Comece polo grupo e pola aplicación

Pregunte que enderezo de grupo usa a aplicación e para que é o tráfico. Un protocolo de descubrimento que anuncia servizos, un fluxo de emisión e os paquetes de saúdo dun protocolo de encamiñamento son tres problemas distintos con tres respostas aceptables distintas. O propio enderezo de grupo indica o alcance: os enderezos do bloque de control da rede local non están pensados para que o encamiñamento ordinario os reenvíe fóra da ligazón, e as aplicacións que os usan adoitan supor un único dominio de difusión. Un fluxo de emisión nun grupo de alcance global é un deseño distinto ao dun protocolo de descubrimento que espera que cada dispositivo escoite cada consulta, e só o segundo se preocupa polo tamaño do dominio de difusión.

Decida se o requisito é o servizo ou o mecanismo de descubrimento, porque esas respostas difiren en custo nunha orde de magnitude. Unha pide un enderezo que non cambia; a outra pide un dominio de difusión estendido por unha ligazón de área extensa con todo o que se deriva diso.

O descubrimento local debería deterse

O Multicast DNS descrito en RFC 6762 está deseñado arredor dunha soa ligazón: as consultas van a un grupo fixo, as respostas envíanse ao mesmo grupo e o protocolo depende de que cada participante escoite a todos. Os encamiñadores non reenvían ese tráfico por defecto, e iso é unha decisión de deseño, non un descoido. A fronteira existe para que un dispositivo dun edificio non poida anunciarse sen máis noutro. Un túnel que parece arranxar o descubrimento levando o grupo a todas partes eliminou esa fronteira para cada aplicación, non só para a que precisaba axuda.

Os repetidores e os reflectores existen, e son servizos reais con consecuencias reais: cada nome anunciado nun sitio vólvese visible no outro, incluídos nomes de dispositivo que identifican persoas ou equipamento. Se o requisito real é que un servizo concreto sexa localizable, un rexistro de servizo publicado en DNS adoita ser o cambio máis pequeno, e revela un nome en lugar dun torrente deles.

Tres cousas que necesita o multicast encamiñado

O multicast encamiñado necesita tres cousas traballando xuntas: receptores que se unan ao grupo, encamiñadores que manteñan estado de reenvío para el e un túnel que trate os enderezos de grupo como tráfico que transportar. Un túnel cunha política que só enumera subredes unicast descartará o tráfico do grupo na fronteira de cifrado, e por iso o primeiro síntoma adoita ser silencio en vez dun erro. Unha interface baseada en rutas, como un túnel GRE ou VTI, transporta o que a táboa de encamiñamento lle envíe, o que fai alcanzable o grupo unha vez que existe o estado de multicast.

A alcanzabilidade da fonte é a segunda metade. Os protocolos de encamiñamento multicast como PIM constrúen árbores de distribución comprobando que o camiño de volta á fonte é o esperado, así que unha ruta unicast que apunta a outro sitio rompe a árbore mesmo cando a pertenza ao grupo é correcta. Instalar unha ruta para o receptor non fai nada por esa comprobación, e ese é o erro que produce un ping que funciona e un fluxo que falla. Verifique primeiro o camiño de retorno da fonte, logo engada a pertenza e só despois mire a aplicación.

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

As dúas primeiras liñas mostran a que se uniu o host e que reenvía o núcleo, a terceira mostra a pertenza da propia aplicación e a última a ruta unicast que usará a comprobación de camiño inverso. Leelas xuntas distingue unha aplicación que nunca se uniu dunha rede que nunca reenviou.

Demostre con unha fonte e un receptor

Antes de tocar unha configuración, confirme que a aplicación funciona nun só segmento. Se falla localmente, o encamiñamento multicast non é o problema e ningún cambio de túnel axudará. Despois repita cun receptor a través do túnel e observe os paquetes aos dous lados da fronteira de cifrado.

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

Os paquetes visibles dentro do túnel pero ausentes fóra apuntan a encapsulación ou política; os paquetes visibles aos dous lados sen progreso da aplicación apuntan á pertenza do receptor ou á vinculación da aplicación. Manteña as capturas curtas e filtradas, porque unha captura multicast ampla nun segmento ocupado é sobre todo ruído.

Prefira un enderezo de servizo cando só precisa o servizo

O descubrimento existe para atopar algo que se move. Un servidor cun nome estable non necesita descubrimento, e un enderezo documentado en DNS privado responde a pregunta real do usuario sen estender un dominio de difusión por unha ligazón de área extensa. O mesmo razoamento se aplica a impresoras, aparellos e servizos web internos. Un nome en DNS é alcanzable desde cada sitio que o necesita mentres non anuncia nada aos sitios que non, e segue funcionando cando o dispositivo se substitúe por outro cun enderezo distinto.

Cando un protocolo require de verdade multicast, límíteo ao grupo e aos sitios que o necesitan, documente por que e revise a decisión cando a aplicación cambie. Estender o descubrimento a todas partes é fácil unha vez, e difícil de desfacer tras un ano de dispositivos que dependen del en silencio.