VIGIL MESH

Documentation

Configurer le multicast et les groupes

Le multicast traverse un réseau VIGIL-MESH comme sur un même câble : un paquet émis vers un groupe atteint tous les membres qui écoutent ce groupe, où qu'ils se trouvent. Il n'y a presque rien à configurer — les abonnements sont détectés automatiquement par un querier IGMPv3/MLDv2 local, la diffusion est chiffrée sous des clés d'émetteur à rotation, et un contrôle de tempête à double étage borne le débit pour éviter qu'une découverte trop bavarde ne sature le maillage. Cette page décrit les quelques réglages qui comptent réellement ; la mécanique interne (mDNS, SSDP, DDS/ROS 2) est détaillée dans /docs/multicast-avance.

Groupes multicast

Un groupe multicast rassemble les membres intéressés par une même diffusion. Côté applicatif, rien ne change par rapport à un LAN classique : une application s'abonne à une adresse de groupe, émet ou reçoit sur ce groupe, et VIGIL se charge de répliquer les paquets vers les seuls membres abonnés. Vous n'avez pas de table de groupes à tenir à la main.

La diffusion link-local est traitée de la même façon : le réseau VIGIL se comporte comme un unique lien logique, si bien que le broadcast et le multicast link-local franchissent le maillage sans être routés naïvement. Le modèle « un réseau = un lien logique » sur lequel repose ce comportement est décrit dans /docs/l2-multicast.

  • Un groupe est identifié applicativement par son adresse multicast ; côté relais, il n'apparaît que sous la forme d'un identifiant opaque.
  • La réplication est ciblée : un paquet destiné à un groupe n'est envoyé qu'aux membres réellement abonnés à ce groupe, jamais à tout le réseau.
  • Un même réseau peut porter de nombreux groupes simultanés — découverte de services, annonces métier, jeux en réseau local — sans configuration croisée.

Abonnements automatiques (querier IGMPv3/MLDv2, zéro configuration)

Vous n'avez aucun abonnement à déclarer manuellement. L'agent joue le rôle de querier IGMPv3 (IPv4) et MLDv2 (IPv6) local sur l'interface TUN de chaque machine. Quand une application s'abonne à un groupe, la pile IP du système d'exploitation l'annonce exactement comme sur n'importe quel réseau, et l'agent le détecte immédiatement.

Ces abonnements sont ensuite propagés dans le maillage, de sorte que la diffusion n'est répliquée que vers les membres réellement intéressés. Il n'y a ni liste de groupes à maintenir, ni configuration par machine : le système d'exploitation fait le travail d'abonnement, l'agent l'écoute et en tire la carte des membres à servir.

  1. 1
    Une application s'abonne à un groupeElle rejoint une adresse multicast comme sur un LAN ordinaire ; aucun paramétrage VIGIL n'est requis.
  2. 2
    Le querier local détecte l'abonnementL'agent, querier IGMPv3/MLDv2 sur l'interface TUN, relève l'annonce émise par la pile IP du système.
  3. 3
    L'abonnement se propage dans le maillageLe membre est désormais compté parmi les récepteurs du groupe, et ne reçoit que le trafic des groupes auxquels il est effectivement abonné.

Contrôle de tempête

La diffusion est puissante mais dangereuse : mal bornée, elle dégénère en tempête de broadcast. VIGIL applique un contrôle de tempête à double étage — par émetteur et par réseau — complété par des garde-fous structurels qui empêchent les boucles. Ce sont les principaux plafonds à connaître si un déploiement génère beaucoup de trafic multicast.

ÉtagePlafondCe qu'il protège
Par émetteur200 paquets/s et 512 kbit/s (token bucket)Un émetteur emballé est étranglé à sa source, en émission comme au fan-out.
Par réseau (vigie)2 000 paquets/s répliqués au totalLe réseau reste plafonné quel que soit le nombre d'émetteurs.
Anti-boucleAucune réémission par les récepteurs + déduplication stricteAucune boucle ne peut se former, aucun paquet dupliqué n'est délivré deux fois.
  • Par émetteur : un token bucket de 200 paquets/s et 512 kbit/s, appliqué à la fois à l'émission et à la réplication (fan-out).
  • Par réseau, côté vigie : un plafond global de 2 000 paquets/s répliqués, indépendant du nombre d'émetteurs.
  • Jamais d'écho : un récepteur ne réémet jamais un paquet de diffusion reçu, ce qui interdit structurellement les boucles.
  • Déduplication stricte sur le quadruplet (groupe, index d'émetteur, époque, compteur) : un paquet dupliqué par le maillage n'est délivré qu'une seule fois.

Sécurité de la diffusion

Diffuser en clair à travers un relais mutualisé serait un contresens. Chaque émetteur multicast possède sa propre clé d'émetteur (sender key) : une clé symétrique ChaCha20-Poly1305 de 32 octets, propre à cet émetteur et à une époque donnée. Elle est distribuée aux membres autorisés via les sessions chiffrées de bout en bout — jamais par le relais.

La clé tourne à trois occasions : à la révocation d'un membre du groupe, au redémarrage de l'émetteur, et au plus tard toutes les 24 heures. Un membre qui a quitté le groupe ne peut donc plus déchiffrer les diffusions suivantes. Côté relais, l'identifiant du groupe n'est qu'un haché opaque (BLAKE2s) : la vigie réplique le paquet vers les bons récepteurs sur la foi de cet identifiant, sans savoir à quel groupe applicatif il correspond ni accéder à son contenu.

ÉlémentCe qui protègeQui y a accès
Clé d'émetteurChaCha20-Poly1305, 32 octets, rotation à la révocation / au redémarrage / sous 24 hLes membres autorisés du groupe
Identifiant de groupeHaché opaque BLAKE2sLe relais, pour aiguiller — sans lire le contenu
Contenu du paquetChiffré de bout en boutÉmetteur et récepteurs autorisés uniquement
Lire ensuiteConfigurer MagicDNS

In English

Multicast crosses a VIGIL-MESH network as if on one wire: a packet sent to a group reaches every member subscribed to that group, wherever they are. Subscriptions are picked up automatically by a local IGMPv3/MLDv2 querier, so there is nothing to declare per machine.

Each sender uses its own rotating 32-byte ChaCha20-Poly1305 sender key, and the group id is an opaque BLAKE2s hash, so the relay fans packets out without reading them. A two-stage storm control (200 pps and 512 kbit/s per sender, 2000 pps per network, no echo, strict dedup) keeps the mesh stable under chatty discovery.