SSM sur OpenVPN : suivre une source et un groupe de bout en bout

Choisissez un flux et un récepteur, puis suivez cette paire à chaque saut au lieu de tester le multicast comme une catégorie. Une conception propre à la source échoue exactement à l’un de quatre endroits : le récepteur ne s’est jamais joint, le routeur a rejeté le paquet sur son chemin inverse, le noyau n’a aucun état, ou le tunnel n’a jamais livré de copie. Travailler dans cet ordre coûte des minutes par saut et vous dit lequel des quatre vous avez réellement.

Fixez d’abord la source, le groupe et le récepteur

Notez trois valeurs avant de toucher au moindre appareil : l’adresse source qui enverra, l’adresse de groupe que le récepteur rejoindra et le sous-réseau où vit le récepteur. Pour un flux IPv4 illustratif, une source 10.50.0.10 et un groupe 232.20.30.40 sont le type de paire qui convient à une conception propre à la source. Tout ce qui est plus vague que ces trois valeurs ne peut pas être testé.

La plage 232/8 est réservée au multicast propre à la source, et le modèle est décrit dans RFC 4607. Si votre groupe se situe hors de cette plage alors que vous croyez faire tourner du SSM, arrêtez-vous et confirmez ce que le déploiement veut réellement, car l’adhésion du récepteur et la décision de transfert du routeur dépendent toutes deux de la cohérence du modèle.

Vérifiez que le récepteur s’est joint à la source

Un rapport d’adhésion portant sur le seul groupe n’est pas une adhésion propre à la source. Demandez au récepteur quelle source il a demandée, et sur le routeur du premier saut regardez l’état du groupe pour voir si une liste de sources apparaît. Si le rapport ne porte aucune source, le routeur le traitera comme une adhésion à n’importe quelle source et toute la conception se dégrade silencieusement en quelque chose que vous n’aviez pas prévu.

Sur un récepteur Linux, vérifiez ce à quoi la socket s’est réellement abonnée et ce que le noyau a enregistré. Le fichier de configuration de l’application n’est pas une preuve ; la table d’adhésion en est une. Lisez-la pendant que le récepteur tourne réellement, car une entrée peut subsister brièvement après la sortie du processus qui l’a créée. Une entrée périmée d’un test antérieur est une source fiable de fausse assurance.

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

Si l’adhésion est présente avec la source attendue, passez aux routeurs. Si elle manque, aucune configuration de tunnel n’aidera, car il n’y a rien à transférer.

Vérifiez le chemin inverse avant de regarder le tunnel

Le routage multicast effectue une vérification du chemin inverse, et un paquet qui arrive sur une interface autre que celle vers laquelle pointe la route unicast est abandonné. C’est la raison la plus courante pour laquelle un flux clairement émis n’atteint jamais le saut suivant, et cela ne produit aucune erreur utile au niveau applicatif.

Sur le routeur tourné vers la source, comparez la route vers la source avec l’interface sur laquelle les paquets arrivent réellement. Sur le routeur tourné vers le récepteur, faites de même pour le sous-réseau propre du récepteur et confirmez que la liste des interfaces sortantes inclut le lien vers celui-ci. Une incohérence dans un sens ou dans l’autre est une défaillance RPF, pas une défaillance d’adhésion.

Confirmez ensuite que le TTL de la source est assez grand pour survivre aux sauts routés que vous avez conçus. Un flux qui fonctionne sur le premier routeur et meurt sur le second est souvent une question de TTL plutôt qu’une question de politique.

Lisez l’état multicast du noyau plutôt que la configuration

La configuration vous dit ce que vous avez demandé ; le noyau vous dit ce qui se passe. À chaque saut Linux, lisez les entrées de routage multicast et confirmez qu’une liste d’interfaces entrantes et sortantes existe pour la paire exacte de source et de groupe. Une entrée pour le groupe avec une source générique est un autre objet, et elle n’expliquera pas un flux propre à la source.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Les démons de routage gardent leur propre vue au-dessus de cet état, et la commande qui l’affiche dépend de l’implémentation installée. Le principe est constant : demandez au démon son entrée amont pour la paire, puis demandez au noyau si une entrée de transfert existe. Un démon qui croit transférer alors que le noyau n’a aucune entrée est un problème de portée de configuration sur cet hôte.

Quand les deux ne concordent pas, réparez l’hôte et non le VPN. Rien en aval ne peut compenser un saut qui ne transfère pas le flux dont vous avez parlé. Notez la paire, l’interface entrante et la liste sortante pour chaque saut pendant que le flux fonctionne. Cet enregistrement transforme la prochaine défaillance en comparaison au lieu d’une nouvelle enquête.

Décidez comment le tunnel réplique réellement

C’est ici que le multicast sur un VPN cesse d’être routinier. Un tunnel point à point livre un paquet à l’unique pair de l’autre extrémité, donc une copie atteint exactement un client. Un segment ponté se comporte davantage comme un lien partagé, parce que le tunnel transporte la trame et le pont décide de ce qu’il inonde. Ce sont des modèles de livraison différents, et une conception qui suppose le second tout en faisant tourner le premier semblera fonctionner pour un récepteur et échouera pour le suivant.

Pour plus d’un récepteur derrière un serveur multipoint, la réplication doit être conçue explicitement. Installer une route multicast sur la passerelle n’apprend pas au serveur VPN quels pairs doivent recevoir une copie, et aucune route côté client ne prend cette décision à sa place. Là où l’exigence est de nombreux récepteurs, utilisez une réplication prise en charge ou une alternative choisie délibérément, et notez laquelle vous avez retenue.

Enfin, vérifiez au niveau du récepteur avec une observation étroite : la source, le groupe et le port exacts, sur l’interface que vous attendez, pendant qu’un récepteur autorisé est joint. SSM sélectionne un émetteur, et la sélection n’est ni une authentification de cet émetteur ni une autorisation pour un autre trafic multicast de traverser la même politique.