ROS 1-Themen über ein VPN: dem angekündigten Endpunkt folgen

Ihre Workstation erreicht den ROS 1-Master über den Tunnel und zeigt trotzdem eine leere Themenliste. Dieses Muster ist verbreitet, weil Masterregistrierung und Thementransport zwei verschiedene Gespräche sind, und nur das erste läuft über den Master. Die folgende Checkliste geht das zweite Gespräch durch: den Endpunkt, den ein Publisher ankündigt, die Adresse, die ein Subscriber erreichen muss, und die Berechtigung, die dem Paar das Sprechen erlaubt. Alles hier bezieht sich nur auf das alte ROS 1, dessen Noetic-Supportfenster im Mai 2025 endete.

Schritt 1: Beweisen Sie, dass die Master-Verbindung nicht die Themen-Verbindung ist

Beginnen Sie damit, zu trennen, was funktioniert, von dem, was nicht funktioniert. Ein erfolgreiches rostopic list beweist, dass Ihre Shell den XMLRPC-Port des Masters erreicht und dass der Master Themen kennt; es sagt nichts darüber aus, ob ein Subscriber den Publisher erreichen kann. Die drei Befehle unten machen den Unterschied sichtbar, und alle sind nur lesend.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

Die Ausgabe von rostopic info nennt die Node-URI des Publishers, also eine XMLRPC-Adresse auf dem Host des Publishers. Diese Adresse wird Ihr Subscriber als Nächstes aufrufen, also muss sie von überall erreichbar sein, wo der Subscriber läuft. Wenn sie auf eine Schnittstelle zeigt, die nur im eigenen LAN des Roboters existiert, gelingt die Master-Suche, und die Daten kommen nie an.

Schritt 2: Den angekündigten Endpunkt am Knoten selbst ablesen

ROS 1 wählt seine angekündigte Host-Identität aus ROS_IP oder ROS_HOSTNAME, wenn eine davon gesetzt ist, und fällt andernfalls auf die Namensauflösung des Hosts selbst zurück. Prüfen Sie die Umgebung des Prozesses, der tatsächlich gestartet wurde, denn eine systemd-Unit, ein Container oder ein zweites Terminal kann einen anderen Wert tragen als die Shell, in der Ihr Test funktioniert hat.

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

Eine Hostnamen-Ankündigung funktioniert nur, wenn jeder Peer diesen Namen auf die beabsichtigte erreichbare Adresse auflöst. Löst sich dieser Name nur im eigenen Netz des Roboters auf, hat eine Workstation auf der anderen Tunnelseite keine Möglichkeit, ihn zu nutzen, und ein VPN, das kein DNS-Suffix schiebt, verschärft die Diskrepanz. ROS_IP auf die Tunneladresse zu setzen ist die kleinere Änderung, wenn die Topologie geroutet ist. Was auch immer Sie wählen, halten Sie es für beide Enden fest, denn ein Publisher und ein Subscriber, die sich über die Identität uneinig sind, verhandeln und können sich dann nicht verbinden.

Halten Sie hier an, wenn die angekündigte URI eine Adresse verwendet, die kein Peer erreichen kann. Kein Firewall-Aufwand behebt einen Namen, der sich zur falschen Schnittstelle auflöst.

Schritt 3: Die angekündigte Adresse auflösbar und geroutet machen

Testen Sie mit der URI in der Hand die Erreichbarkeit vom Host des Subscribers statt vom Roboter. Der TCPROS-Port wird während der Aushandlung gewählt, also ist der nützliche frühe Test der XMLRPC-Port und der nützliche späte Test der aufgebaute Socket. Eine Route, die nur in eine Richtung existiert, ist ein häufiger Fehler auf gerouteten VPNs, und der Rückweg zählt genauso viel wie der Hinweg.

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

Eine geroutete TUN-Schnittstelle trägt diese IP-Gespräche, ohne das Ethernet-Segment des Roboters auszudehnen, was ein Fernbediener normalerweise will. Wenn etwas im Stack stattdessen von Broadcast oder Multicast abhängt, muss diese Anforderung gesondert bewertet werden; den Tunnel zu TAP zu machen, um ein Werkzeug zufriedenzustellen, erweitert das Netz für jeden Teilnehmer.

Halten Sie hier an, wenn die Route oder der Rückweg fehlt. Ein Publisher, der auf seinem eigenen Host antwortet, aber von der Workstation nicht erreichbar ist, hat ein Routingproblem, kein ROS-Problem.

Schritt 4: Das Peer-Gespräch erlauben und ein Thema beobachten

Öffnen Sie nur die Ports, die das ausgehandelte Gespräch braucht, und beschränken Sie jede Regel auf die erklärten Teilnehmer. Der Listener des Masters ist kein Relay für Themennutzlast, also lässt die Freigabe nur für ihn den Endpunkt des Publishers geschlossen. Halten Sie die ROS-Listener an der Grenze des privaten VPN, statt sie dem öffentlichen Internet auszusetzen.

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

Beobachten Sie ein harmloses Thema vom echten Publisher zum echten Subscriber und bestätigen Sie sowohl den angekündigten Endpunkt als auch den Antwortweg. Eine einzelne Nachricht beweist, dass der Weg funktioniert; eine stabile Rate beweist, dass er offen bleibt. Halten Sie Aktuatorsteuerung und Sicherheitsprüfungen aus diesem reinen Netzwerktest heraus, denn ein funktionierendes Thema zertifiziert keinen funktionierenden Roboter. Notieren Sie die ROS-Version und das beobachtete Endpunktpaar, damit die nächste Person eine Topologieänderung von einer Regression unterscheiden kann.

Die Checkliste ist fertig, wenn die angekündigte URI vom Subscriber erreichbar ist, der ausgehandelte Port nur für diesen Peer offen ist, ein erklärtes Thema fließt und die Umgebungswerte für beide Hosts notiert sind. Altes ROS 1 wird in diesem Bereich keine Korrekturen mehr erhalten, also ist die Aufzeichnung der Teil, der weiter funktioniert, nachdem die Menschen wechseln.