Por qué el multicast no cruza una VPN sin un plan

Dos sedes pueden alcanzarse perfectamente por unicast y aun así comportarse como si una de ellas no viera el anuncio de descubrimiento de la impresora, el flujo IPTV o el latido del clúster. Eso no es un túnel roto; es la diferencia entre un destino y un grupo. La entrega de multicast necesita un modelo de pertenencia, estado de reenvío a lo largo del camino y una interfaz dispuesta a transportar el tráfico, y nada de eso proviene de una ruta unicast. Recorrer del grupo de la aplicación a un receptor que funcione es el camino más corto hacia una respuesta.

Empiece por el grupo y la aplicación

Pregunte qué dirección de grupo usa la aplicación y para qué es el tráfico. Un protocolo de descubrimiento que anuncia servicios, un flujo de emisión y los paquetes de saludo de un protocolo de enrutamiento son tres problemas distintos con tres respuestas aceptables distintas. La propia dirección de grupo indica el alcance: las direcciones del bloque de control de red local no están pensadas para que el enrutamiento ordinario las reenvíe fuera del enlace, y las aplicaciones que las usan suelen suponer un único dominio de difusión. Un flujo de emisión en un grupo de alcance global es un diseño distinto al de un protocolo de descubrimiento que espera que cada dispositivo escuche cada consulta, y solo el segundo se preocupa por el tamaño del dominio de difusión.

Decida si el requisito es el servicio o el mecanismo de descubrimiento, porque esas respuestas difieren en coste en un orden de magnitud. Una pide una dirección que no cambia; la otra pide un dominio de difusión extendido por un enlace de área extensa con todo lo que se deriva de ello.

El descubrimiento local debería detenerse

El Multicast DNS descrito en RFC 6762 está diseñado en torno a un solo enlace: las consultas van a un grupo fijo, las respuestas se envían al mismo grupo y el protocolo depende de que cada participante escuche a todos. Los enrutadores no reenvían ese tráfico por defecto, y eso es una decisión de diseño, no un descuido. La frontera existe para que un dispositivo de un edificio no pueda anunciarse sin más en otro. Un túnel que parece arreglar el descubrimiento llevando el grupo a todas partes ha eliminado esa frontera para cada aplicación, no solo para la que necesitaba ayuda.

Los repetidores y los reflectores existen, y son servicios reales con consecuencias reales: cada nombre anunciado en una sede se vuelve visible en la otra, incluidos nombres de dispositivo que identifican a personas o equipos. Si el requisito real es que un servicio concreto sea localizable, un registro de servicio publicado en DNS suele ser el cambio más pequeño, y revela un nombre en lugar de un torrente de ellos.

Tres cosas que necesita el multicast enrutado

El multicast enrutado necesita tres cosas trabajando juntas: receptores que se unan al grupo, enrutadores que mantengan estado de reenvío para él y un túnel que trate las direcciones de grupo como tráfico que transportar. Un túnel con una política que solo enumera subredes unicast descartará el tráfico del grupo en la frontera de cifrado, y por eso el primer síntoma suele ser silencio en vez de un error. Una interfaz basada en rutas, como un túnel GRE o VTI, transporta lo que la tabla de enrutamiento le envíe, lo que hace alcanzable el grupo una vez que existe el estado de multicast.

La alcanzabilidad de la fuente es la segunda mitad. Los protocolos de enrutamiento multicast como PIM construyen árboles de distribución comprobando que el camino de vuelta a la fuente es el esperado, así que una ruta unicast que apunta a otro sitio rompe el árbol incluso cuando la pertenencia al grupo es correcta. Instalar una ruta para el receptor no hace nada por esa comprobación, y ese es el error que produce un ping que funciona y un flujo que falla. Verifique primero el camino de retorno de la fuente, luego añada la pertenencia y solo después mire la aplicación.

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

Las dos primeras líneas muestran a qué se ha unido el host y qué reenvía el núcleo, la tercera muestra la pertenencia de la propia aplicación y la última la ruta unicast que usará la comprobación de camino inverso. Leerlas juntas distingue una aplicación que nunca se unió de una red que nunca reenvió.

Demuéstrelo con una fuente y un receptor

Antes de tocar una configuración, confirme que la aplicación funciona en un solo segmento. Si falla localmente, el enrutamiento multicast no es el problema y ningún cambio de túnel ayudará. Después repita con un receptor a través del túnel y observe los paquetes a ambos lados de la frontera de cifrado.

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

Los paquetes visibles dentro del túnel pero ausentes fuera apuntan a encapsulación o política; los paquetes visibles a ambos lados sin progreso de la aplicación apuntan a la pertenencia del receptor o a la vinculación de la aplicación. Mantenga las capturas cortas y filtradas, porque una captura multicast amplia en un segmento ocupado es sobre todo ruido.

Prefiera una dirección de servicio cuando solo necesita el servicio

El descubrimiento existe para encontrar algo que se mueve. Un servidor con un nombre estable no necesita descubrimiento, y una dirección documentada en DNS privado responde a la pregunta real del usuario sin extender un dominio de difusión por un enlace de área extensa. El mismo razonamiento se aplica a impresoras, electrodomésticos y servicios web internos. Un nombre en DNS es alcanzable desde cada sede que lo necesita mientras no anuncia nada a las sedes que no, y sigue funcionando cuando el dispositivo se sustituye por otro con una dirección distinta.

Cuando un protocolo requiere de verdad multicast, limítelo al grupo y a las sedes que lo necesitan, documente por qué y revise la decisión cuando la aplicación cambie. Extender el descubrimiento a todas partes es fácil una vez, y difícil de deshacer tras un año de dispositivos que dependen de ello en silencio.