OpenVPN replica el multicast a cada cliente, no a los suscriptores

"Admite multicast" responde a una pregunta de protocolo y deja intacta la pregunta de capacidad. Lo que importa en operación es cuántas copias emite el servidor por un paquete de grupo y qué túneles las transportan. Una aplicación suscrita que recibe el flujo solo demuestra que la entrega funciona en algún sitio. No demuestra que los clientes no interesados se hayan ahorrado el ancho de banda.

Tres preguntas dentro de una sola afirmación de funcionalidad

La pertenencia al grupo pregunta si el receptor se unió al grupo. La entrega por túnel pregunta si el paquete cruzó el túnel. La política de replicación pregunta cuántas copias hizo el servidor y a quién. Una declaración del proveedor puede ser cierta para la primera y muda sobre la tercera, y ahí es donde vive el coste.

Manténgalas separadas cuando dimensione un enlace. Solo la tercera pregunta fija el presupuesto de salida en el lado del servidor.

Qué hace el servidor en espacio de usuario con un paquete de grupo

En el servidor tradicional en espacio de usuario de OpenVPN 2.6, un paquete de broadcast o multicast que llega se clasifica en la ruta de entrada TUN/TAP y se entrega a la rutina de distribución de broadcast en lugar de a una búsqueda por grupo. Esa rutina recorre las instancias de cliente, omite al emisor y cualquier instancia detenida, aplica su comprobación de VLAN donde hay una configurada y encola una copia para cada cliente restante. Ningún paso de ese bucle consulta una tabla de pertenencia. Eso es replicación de estilo broadcast, y es todo el mecanismo.

Trátelo como una propiedad de esa ruta de código, no como una ley universal. Las rutas de datos aceleradas, otras implementaciones y distintas versiones pueden comportarse de otro modo, y nada de esto convierte TAP en un requisito ni en una reparación.

Presupueste las copias antes de medir nada

Tome la tasa de carga útil y multiplíquela por el número de clientes elegibles. Un flujo que envía un megabit por segundo a veinte clientes produce veinte megabits por segundo de carga útil que sale del servidor, antes de encapsulación, retransmisión y cualquier sobrecarga por cliente. Esa aritmética es un presupuesto, no una medición de su despliegue.

ip -s link show tun0

Lea el contador de bytes transmitidos antes y después de un intervalo fijo con un emisor conocido activo. Divida por el intervalo y compare con la tasa de carga útil multiplicada por el número de clientes. Un número cercano a la tasa de un solo flujo significa que la replicación está acotada; un número cercano a la tasa multiplicada significa que cada cliente recibe una copia.

El contador también incluye su propio tráfico de túnel, así que mantenga corta la ventana de prueba y el host tranquilo por lo demás. La precisión importa menos que el orden de magnitud, que es todo lo que necesita para distinguir una copia de veinte.

Una prueba con dos clientes que zanja la cuestión del alcance

Conecte un cliente que debería recibir el flujo y un segundo que no. Inicie el emisor y observe los contadores de túnel del segundo cliente durante el mismo intervalo. El crecimiento en el segundo cliente es prueba directa de una replicación amplia, diga lo que diga la lista de funciones.

Filtre la captura a la dirección del grupo para no leer tráfico no relacionado, y limítela a la interfaz del túnel. Capturar la interfaz física en un host ocupado produce un archivo que nadie puede interpretar y puede retener datos de usuario que no pretendía recoger.

Luego invierta los papeles. Si el resultado sigue al receptor y no al grupo, está ante algo consciente de la pertenencia, y la suposición anterior era errónea a su favor.

Elegir un diseño acotado en lugar de quitar límites

Cuando la distribución es demasiado amplia, la solución es un despliegue de distribución acotado y compatible, no borrar todos los controles que tenga. Las opciones incluyen acercar el punto de distribución a los receptores, usar un modelo de suscripción específico de la fuente que lleve la identidad de la fuente además del grupo, o dividir el flujo para que los sitios no interesados nunca estén en la misma frontera de distribución.

Mantenga la identidad de fuente y grupo separada del simple hecho de que un destino sea multicast. Un receptor que reconoce el grupo pero no la fuente es un suscriptor distinto de uno que pidió un canal concreto. Mezclar ambos convierte la planificación de capacidad posterior en conjeturas.

El modelo de canal multicast específico de la fuente es la referencia para esa distinción. Elija el diseño que elija, anote el conjunto de pares elegibles, el dueño de la replicación y el contador que leerá la próxima vez; ese registro es lo que convierte una sorpresa de ancho de banda en un coste conocido.