Pourquoi le multicast ne traverse pas un VPN sans plan

Deux sites peuvent parfaitement s’atteindre en unicast et se comporter néanmoins comme si l’un d’eux ne voyait pas l’annonce de découverte de l’imprimante, le flux IPTV ou le battement de cœur du cluster. Ce n’est pas un tunnel cassé ; c’est la différence entre une destination et un groupe. La livraison multicast exige un modèle d’adhésion, un état de transfert le long du chemin et une interface disposée à porter le trafic, et rien de tout cela ne vient d’une route unicast. Aller du groupe de l’application à un récepteur qui fonctionne est le chemin le plus court vers une réponse.

Commencez par le groupe et l’application

Demandez quelle adresse de groupe l’application utilise et à quoi sert le trafic. Un protocole de découverte qui annonce des services, un flux de diffusion et les paquets de hello d’un protocole de routage sont trois problèmes différents avec trois réponses acceptables différentes. L’adresse de groupe elle-même indique la portée : les adresses du bloc de contrôle du réseau local ne sont pas destinées à être transférées hors du lien par un routage ordinaire, et les applications qui les utilisent supposent généralement un seul domaine de diffusion. Un flux de diffusion sur un groupe de portée globale est une conception différente d’un protocole de découverte qui attend de chaque appareil qu’il entende chaque requête, et seul le second se soucie de la taille du domaine de diffusion.

Décidez si l’exigence est le service ou le mécanisme de découverte, car ces réponses diffèrent en coût d’un ordre de grandeur. L’une demande une adresse qui ne change pas ; l’autre demande un domaine de diffusion étendu sur une liaison étendue avec tout ce qui en découle.

La découverte locale est censée s’arrêter

Le Multicast DNS décrit dans RFC 6762 est conçu autour d’un seul lien : les requêtes vont à un groupe fixe, les réponses sont envoyées au même groupe, et le protocole compte sur le fait que chaque participant entend tout le monde. Les routeurs ne transfèrent pas ce trafic par défaut, et c’est une décision de conception, pas un oubli. La frontière existe pour qu’un appareil d’un bâtiment ne puisse pas s’annoncer tranquillement dans un autre. Un tunnel qui semble corriger la découverte en transportant le groupe partout a supprimé cette frontière pour chaque application, pas seulement pour celle qui avait besoin d’aide.

Les répéteurs et les réflecteurs existent, et ce sont de vrais services avec de vraies conséquences : chaque nom annoncé sur un site devient visible sur l’autre, y compris les noms d’appareils qui identifient des personnes ou du matériel. Si l’exigence réelle est qu’un service précis soit trouvable, un enregistrement de service publié dans le DNS est généralement le plus petit changement, et il révèle un nom au lieu d’un flux de noms.

Trois choses dont le multicast routé a besoin

Le multicast routé a besoin de trois choses qui fonctionnent ensemble : des récepteurs qui rejoignent le groupe, des routeurs qui maintiennent un état de transfert pour lui et un tunnel qui traite les adresses de groupe comme du trafic à transporter. Un tunnel dont la politique n’énumère que des sous-réseaux unicast laissera tomber le trafic du groupe à la frontière du chiffrement, et c’est pourquoi le premier symptôme est souvent le silence plutôt qu’une erreur. Une interface fondée sur les routes, comme un tunnel GRE ou VTI, transporte ce que la table de routage y envoie, ce qui rend le groupe joignable dès que l’état multicast existe.

L’accessibilité de la source est la seconde moitié. Les protocoles de routage multicast comme PIM construisent des arbres de distribution en vérifiant que le chemin de retour vers la source est celui attendu, si bien qu’une route unicast qui pointe ailleurs casse l’arbre même lorsque l’adhésion au groupe est correcte. Installer une route pour le récepteur ne fait rien pour cette vérification, et c’est l’erreur qui produit un ping qui fonctionne et un flux qui échoue. Vérifiez d’abord le chemin de retour de la source, ajoutez ensuite l’adhésion, et seulement alors regardez l’application.

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

Les deux premières lignes montrent à quoi l’hôte s’est joint et ce que le noyau transfère, la troisième montre l’adhésion de l’application elle-même, et la dernière le chemin unicast que la vérification du chemin inverse utilisera. Les lire ensemble distingue une application qui ne s’est jamais jointe d’un réseau qui n’a jamais transféré.

Prouvez-le avec une source et un récepteur

Avant de toucher à une configuration, confirmez que l’application fonctionne sur un seul segment. Si elle échoue localement, le routage multicast n’est pas le problème et aucun changement de tunnel n’aidera. Répétez ensuite avec un récepteur à travers le tunnel et observez les paquets des deux côtés de la frontière de chiffrement.

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

Les paquets visibles dans le tunnel mais absents à l’extérieur indiquent une encapsulation ou une politique ; les paquets visibles des deux côtés sans progrès de l’application indiquent l’adhésion du récepteur ou la liaison de l’application. Gardez les captures courtes et filtrées, car une capture multicast large sur un segment chargé n’est surtout que du bruit.

Préférez une adresse de service quand seul le service compte

La découverte existe pour trouver quelque chose qui bouge. Un serveur au nom stable n’a pas besoin de découverte, et une adresse documentée dans un DNS privé répond à la vraie question de l’utilisateur sans étendre un domaine de diffusion sur une liaison étendue. Le même raisonnement vaut pour les imprimantes, les appareils et les services web internes. Un nom dans le DNS est joignable depuis chaque site qui en a besoin sans rien annoncer aux sites qui n’en ont pas besoin, et il continue de fonctionner quand l’appareil est remplacé par un autre doté d’une adresse différente.

Quand un protocole exige vraiment du multicast, limitez-le au groupe et aux sites qui en ont besoin, documentez pourquoi, et révisez la décision quand l’application change. Étendre la découverte partout est facile une fois, et difficile à défaire après un an d’appareils qui en dépendent discrètement.