SSM sobre OpenVPN: seguir una fuente y un grupo de principio a fin

Elija un flujo y un receptor, y luego siga ese par por cada salto en lugar de probar el multicast como una categoría. Un diseño específico de fuente falla exactamente en uno de cuatro lugares: el receptor nunca se unió, el enrutador rechazó el paquete en su ruta inversa, el núcleo no tiene estado, o el túnel nunca entregó una copia. Trabajar en ese orden cuesta minutos por salto y le dice cuál de los cuatro tiene realmente.

Fije primero la fuente, el grupo y el receptor

Anote tres valores antes de tocar cualquier dispositivo: la dirección de origen que enviará, la dirección de grupo a la que se unirá el receptor y la subred en la que vive el receptor. Para un flujo IPv4 ilustrativo, una fuente 10.50.0.10 y un grupo 232.20.30.40 son el tipo de par que encaja en un diseño específico de fuente. Cualquier cosa más vaga que esos tres valores no se puede probar.

El rango 232/8 está reservado para multicast específico de fuente, y el modelo se describe en RFC 4607. Si su grupo está fuera de ese rango mientras cree que ejecuta SSM, deténgase y confirme qué pretende realmente el despliegue, porque la unión del receptor y la decisión de reenvío del enrutador dependen ambas de que el modelo sea coherente.

Compruebe que el receptor se ha unido a la fuente

Un informe de membresía solo para el grupo no es una unión específica de fuente. Pregunte al receptor qué fuente solicitó, y en el enrutador del primer salto mire el estado del grupo para ver si aparece una lista de fuentes. Si el informe no lleva ninguna fuente, el enrutador lo tratará como una unión a cualquier fuente y todo el diseño se degrada en silencio hacia algo que no había planificado.

En un receptor Linux, compruebe a qué se suscribió realmente el socket y qué registró el núcleo. El archivo de configuración de la aplicación no es una prueba; la tabla de membresía sí lo es. Léala mientras el receptor está realmente en ejecución, porque una entrada puede persistir brevemente después de que salga el proceso que la creó. Una entrada obsoleta de una prueba anterior es una fuente fiable de falsa confianza.

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

Si la unión está presente con la fuente esperada, pase a los enrutadores. Si falta, ninguna configuración de túnel ayudará, porque no hay nada que reenviar.

Verifique la ruta inversa antes de mirar el túnel

El enrutamiento multicast realiza una comprobación de ruta inversa, y un paquete que llega por una interfaz distinta de la que indica la ruta unicast se descarta. Es la razón más común por la que un flujo que claramente se está enviando nunca llega al siguiente salto, y no produce ningún error útil a nivel de aplicación.

En el enrutador que mira hacia la fuente, compare la ruta hacia la fuente con la interfaz por la que llegan realmente los paquetes. En el enrutador que mira hacia el receptor, haga lo mismo para la subred propia del receptor y confirme que la lista de interfaces de salida incluye el enlace hacia ella. Una discrepancia en cualquier dirección es un fallo de RPF, no un fallo de membresía.

Después confirme que el TTL de la fuente es lo bastante grande para sobrevivir a los saltos enrutados que ha diseñado. Un flujo que funciona en el primer enrutador y muere en el segundo suele ser una cuestión de TTL y no de política.

Lea el estado multicast del núcleo en lugar de la configuración

La configuración le dice lo que pidió; el núcleo le dice lo que ocurre. En cada salto Linux, lea las entradas de enrutamiento multicast y confirme que existe una lista de interfaces de entrada y de salida para el par exacto de fuente y grupo. Una entrada para el grupo con una fuente comodín es un objeto distinto y no explicará un flujo específico de fuente.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Los demonios de enrutamiento mantienen su propia visión sobre ese estado, y el comando que la imprime depende de qué implementación esté instalada. El principio es constante: pregunte al demonio por su entrada upstream para el par y luego pregunte al núcleo si existe una entrada de reenvío. Un demonio que cree que reenvía mientras el núcleo no tiene entrada es un problema de alcance de configuración en ese host.

Cuando los dos no coinciden, arregle el host y no la VPN. Nada aguas abajo puede compensar un salto que no reenvía el flujo por el que preguntó. Anote el par, la interfaz de entrada y la lista de salida para cada salto mientras el flujo funciona. Ese registro convierte el siguiente fallo en una comparación en lugar de una investigación nueva.

Decida cómo replica realmente el túnel

Aquí es donde el multicast sobre una VPN deja de ser rutinario. Un túnel punto a punto entrega un paquete al único par del otro extremo, así que una copia llega exactamente a un cliente. Un segmento puenteado se comporta más bien como un enlace compartido, porque el túnel transporta la trama y el puente decide qué inundar. Son modelos de entrega distintos, y un diseño que asume el segundo mientras ejecuta el primero parecerá funcionar para un receptor y fallará para el siguiente.

Para más de un receptor a través de un servidor multipunto, la replicación debe diseñarse explícitamente. Instalar una ruta multicast en la puerta de enlace no enseña al servidor VPN qué pares deben recibir una copia, y ninguna ruta del lado del cliente toma esa decisión por él. Donde el requisito es muchos receptores, use replicación soportada o una alternativa elegida deliberadamente, y anote cuál eligió.

Por último, verifique en el receptor con una observación estrecha: la fuente, el grupo y el puerto exactos, en la interfaz que espera, mientras un receptor autorizado está unido. SSM selecciona un remitente, y la selección no es autenticación de ese remitente ni permiso para que otro tráfico multicast cruce la misma política.