OpenVPN diffuse le multicast vers chaque client, pas vers les abonnés

"Prend en charge le multicast" répond à une question de protocole et laisse la question de capacité intacte. Ce qui compte en exploitation, c’est le nombre de copies que le serveur émet pour un paquet de groupe et les tunnels qui les transportent. Une application abonnée qui reçoit le flux prouve seulement que la livraison fonctionne quelque part. Elle ne prouve pas que les clients non concernés ont été épargnés par la bande passante.

Trois questions à l’intérieur d’une seule promesse de fonction

L’appartenance au groupe demande si le récepteur a rejoint le groupe. La livraison par tunnel demande si le paquet a traversé le tunnel. La politique de réplication demande combien de copies le serveur a faites et à qui. Une déclaration de fournisseur peut être vraie pour la première et muette sur la troisième, et c’est là que vit le coût.

Gardez-les séparées lorsque vous dimensionnez un lien. Seule la troisième question fixe le budget sortant côté serveur.

Ce que le serveur en espace utilisateur fait d’un paquet de groupe

Dans le serveur traditionnel en espace utilisateur d’OpenVPN 2.6, un paquet de diffusion ou multicast entrant est classé dans le chemin d’entrée TUN/TAP et remis à la routine de diffusion plutôt qu’à une recherche par groupe. Cette routine parcourt les instances clientes, saute l’émetteur et toute instance arrêtée, applique son contrôle VLAN là où il est configuré et met une copie en file pour chaque client restant. Aucune étape de cette boucle ne consulte une table d’appartenance. C’est de la réplication de style diffusion, et c’est tout le mécanisme.

Considérez cela comme une propriété de ce chemin de code, non comme une loi universelle. Les chemins de données accélérés, d’autres implémentations et différentes versions peuvent se comporter autrement, et rien de tout cela ne fait de TAP une exigence ni une réparation.

Budgétez les copies avant de mesurer quoi que ce soit

Prenez le débit utile et multipliez-le par le nombre de clients éligibles. Un flux qui envoie un mégabit par seconde à vingt clients produit vingt mégabits par seconde de charge utile quittant le serveur, avant encapsulation, retransmission et toute surcharge par client. Cette arithmétique est un budget, pas une mesure de votre déploiement.

ip -s link show tun0

Lisez le compteur d’octets émis avant et après un intervalle fixe avec un émetteur connu actif. Divisez par l’intervalle et comparez au débit utile multiplié par le nombre de clients. Un nombre proche du débit d’un seul flux signifie que la réplication est limitée ; un nombre proche du débit multiplié signifie que chaque client reçoit une copie.

Le compteur inclut aussi votre propre trafic de tunnel, gardez donc la fenêtre de test courte et l’hôte silencieux par ailleurs. La précision compte moins que l’ordre de grandeur, et c’est tout ce qu’il vous faut pour distinguer une copie de vingt.

Un test à deux clients qui tranche la question de la portée

Connectez un client qui devrait recevoir le flux et un second qui ne devrait pas. Lancez l’émetteur, puis observez les compteurs de tunnel du second client sur le même intervalle. Une croissance chez le second client est la preuve directe d’une réplication large, quoi qu’ait dit la fiche produit.

Filtrez la capture sur l’adresse du groupe pour ne pas lire du trafic sans rapport, et limitez-la à l’interface du tunnel. Capturer l’interface physique sur un hôte occupé produit un fichier que personne ne peut interpréter et peut conserver des données utilisateur que vous ne vouliez pas collecter.

Inversez ensuite les rôles. Si le résultat suit le récepteur plutôt que le groupe, vous regardez quelque chose qui tient compte de l’appartenance, et l’hypothèse précédente était fausse en votre faveur.

Choisir un design limité au lieu de supprimer les limites

Quand la diffusion est trop large, le correctif est un dispositif de distribution limité et pris en charge, pas la suppression de tous les contrôles dont vous disposez. Les options incluent rapprocher le point de distribution des récepteurs, utiliser un modèle d’abonnement spécifique à la source qui porte l’identité de la source en plus du groupe, ou scinder le flux pour que les sites non concernés ne se trouvent jamais sur la même frontière de distribution.

Gardez l’identité de la source et du groupe distincte du simple fait qu’une destination est multicast. Un récepteur qui reconnaît le groupe mais pas la source est un abonné différent de celui qui a demandé un canal précis. Mélanger les deux transforme la planification de capacité ultérieure en conjecture.

Le modèle de canal multicast spécifique à la source est la référence pour cette distinction. Quel que soit le design choisi, notez l’ensemble des pairs éligibles, le responsable de la réplication et le compteur que vous lirez la prochaine fois ; ce registre est ce qui transforme une surprise de bande passante en coût connu.