Sujets ROS 1 sur un VPN : suivre le point de terminaison annoncé

Votre poste de travail atteint le master ROS 1 via le tunnel et affiche toujours une liste de sujets vide. Ce schéma est courant car l’enregistrement auprès du master et le transport des sujets sont deux conversations différentes, et seule la première passe par le master. La liste de vérification ci-dessous parcourt la seconde conversation : le point de terminaison qu’un éditeur annonce, l’adresse qu’un abonné doit pouvoir atteindre et l’autorisation qui laisse le couple se parler. Tout ici ne concerne que l’ancien ROS 1, dont la fenêtre de support Noetic s’est terminée en mai 2025.

Étape 1 : prouvez que la connexion au master n’est pas la connexion aux sujets

Commencez par séparer ce qui fonctionne de ce qui ne fonctionne pas. Un rostopic list réussi prouve que votre shell atteint le port XMLRPC du master et que le master connaît des sujets ; il ne dit rien sur la capacité d’un abonné à atteindre l’éditeur. Les trois commandes ci-dessous rendent la distinction visible, et toutes sont en lecture seule.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

La sortie de rostopic info nomme l’URI du nœud de l’éditeur, qui est une adresse XMLRPC sur l’hôte de l’éditeur. Cette adresse est celle que votre abonné appellera ensuite, elle doit donc être joignable depuis partout où l’abonné s’exécute. Si elle pointe vers une interface qui n’existe que sur le LAN du robot lui-même, la recherche auprès du master réussit et les données n’arrivent jamais.

Étape 2 : lisez le point de terminaison annoncé depuis le nœud lui-même

ROS 1 choisit son identité d’hôte annoncée dans ROS_IP ou ROS_HOSTNAME quand l’une des deux est définie, et retombe sinon sur la résolution de noms de l’hôte lui-même. Inspectez l’environnement du processus réellement lancé, car une unité systemd, un conteneur ou un second terminal peut porter une valeur différente de celle du shell où votre test a fonctionné.

echo "$ROS_IP" "$ROS_HOSTNAME"
rosnode info /talker
getent hosts robot-host

Une annonce de nom d’hôte ne fonctionne que si chaque pair résout ce nom vers l’adresse joignable prévue. Si ce nom ne se résout qu’à l’intérieur du réseau propre du robot, un poste de travail de l’autre côté du tunnel n’a aucun moyen de l’utiliser, et un VPN qui ne pousse aucun suffixe DNS aggrave la discordance. Définir ROS_IP sur l’adresse du tunnel est le plus petit changement lorsque la topologie est routée. Quel que soit votre choix, consignez-le pour les deux extrémités, car un éditeur et un abonné qui ne s’accordent pas sur l’identité vont négocier puis échouer à se connecter.

Arrêtez-vous ici si l’URI annoncée utilise une adresse vers laquelle aucun pair ne peut router. Aucun travail sur le pare-feu ne corrigera un nom qui se résout vers la mauvaise interface.

Étape 3 : rendez l’adresse annoncée résoluble et routée

L’URI en main, testez la joignabilité depuis l’hôte de l’abonné plutôt que depuis le robot. Le port TCPROS est choisi pendant la négociation, donc le test précoce utile est le port XMLRPC et le test tardif utile est la socket établie. Une route qui n’existe que dans un sens est une défaillance courante sur les VPN routés, et le chemin de retour compte autant que le chemin aller.

ip route get 10.70.0.2
nc -vz 10.70.0.2 33911
ss -tnp dst 10.70.0.2

Une interface TUN routée transporte ces conversations IP sans étendre le segment Ethernet du robot, ce qui est généralement ce que veut un opérateur distant. Si quelque chose dans la pile dépend plutôt de la diffusion ou du multicast, cette exigence doit être évaluée séparément ; convertir le tunnel en TAP pour satisfaire un seul outil élargit le réseau pour chaque participant.

Arrêtez-vous ici si la route ou le chemin de retour manque. Un éditeur qui répond sur son propre hôte mais n’est pas joignable depuis le poste de travail a un problème de routage, pas un problème ROS.

Étape 4 : autorisez la conversation entre pairs et observez un sujet

N’ouvrez que les ports dont la conversation négociée a besoin, et limitez chaque règle aux participants déclarés. L’écouteur du master n’est pas un relais pour la charge utile des sujets, donc l’autoriser seul laisse le point de terminaison de l’éditeur fermé. Gardez les écouteurs ROS à la frontière du VPN privé au lieu de les exposer à l’internet public.

rostopic hz /chatter
rostopic echo -n1 /chatter
rosnode ping /talker

Observez un sujet inoffensif de l’éditeur réel vers l’abonné réel et confirmez à la fois le point de terminaison annoncé et le chemin de réponse. Un seul message prouve que le chemin fonctionne ; un débit stable prouve qu’il reste ouvert. Gardez le contrôle des actionneurs et les vérifications de sécurité hors de ce test purement réseau, car un sujet qui fonctionne ne certifie pas un robot qui fonctionne. Consignez la version de ROS et la paire de points de terminaison observée, afin que la personne suivante puisse distinguer un changement de topologie d’une régression.

La liste de vérification est terminée lorsque l’URI annoncée est joignable depuis l’abonné, que le port négocié est ouvert pour ce pair uniquement, qu’un sujet déclaré circule et que les valeurs d’environnement sont écrites pour les deux hôtes. L’ancien ROS 1 ne recevra pas de corrections dans ce domaine, donc le registre est la partie qui continue de fonctionner après le changement de personnes.