ROS 1-onderwerpen via een VPN: volg het aangekondigde eindpunt

Uw werkstation bereikt de ROS 1-master via de tunnel en toont toch een lege onderwerpenlijst. Dat patroon is gebruikelijk omdat masterregistratie en onderwerptransport twee verschillende gesprekken zijn, en alleen het eerste loopt via de master. De checklist hieronder doorloopt het tweede gesprek: het eindpunt dat een publisher aankondigt, het adres dat een subscriber moet kunnen bereiken en de toestemming die het paar laat praten. Alles hier geldt alleen voor de oude ROS 1, waarvan het Noetic-supportvenster in mei 2025 eindigde.

Stap 1: bewijs dat de masterverbinding niet de onderwerpverbinding is

Begin met scheiden wat werkt van wat niet werkt. Een geslaagde rostopic list bewijst dat uw shell de XMLRPC-poort van de master bereikt en dat de master onderwerpen kent; het zegt niets over de vraag of een subscriber de publisher kan bereiken. De drie opdrachten hieronder maken dat verschil zichtbaar, en ze zijn allemaal alleen-lezen.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

De uitvoer van rostopic info noemt de node-URI van de publisher, dat is een XMLRPC-adres op de host van de publisher. Dat adres is het adres dat uw subscriber hierna aanroept, dus het moet bereikbaar zijn vanaf waar de subscriber ook draait. Als het naar een interface wijst die alleen op het eigen LAN van de robot bestaat, slaagt de masterzoektocht en komen de gegevens nooit aan.

Stap 2: lees het aangekondigde eindpunt uit de node zelf

ROS 1 kiest zijn aangekondigde hostidentiteit uit ROS_IP of ROS_HOSTNAME wanneer een van beide is ingesteld, en valt anders terug op de naamresolutie van de host zelf. Onderzoek de omgeving van het proces dat daadwerkelijk is gestart, want een systemd-unit, een container of een tweede terminal kan een andere waarde dragen dan de shell waarin uw test werkte.

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

Een hostnaamaankondiging werkt alleen als elke peer die naam oplost naar het bedoelde bereikbare adres. Als die naam alleen binnen het eigen netwerk van de robot wordt opgelost, heeft een werkstation aan de andere kant van de tunnel geen manier om hem te gebruiken, en een VPN die geen DNS-suffix pusht maakt de mismatch erger. ROS_IP op het tunneladres zetten is de kleinere wijziging wanneer de topologie gerouteerd is. Wat u ook kiest, leg het voor beide kanten vast, want een publisher en een subscriber die het over identiteit oneens zijn, onderhandelen en kunnen daarna niet verbinden.

Stop hier als de aangekondigde URI een adres gebruikt dat geen enkele peer kan routeren. Geen enkele firewall-inspanning herstelt een naam die naar de verkeerde interface wordt opgelost.

Stap 3: maak het aangekondigde adres oplosbaar en gerouteerd

Test met de URI in de hand de bereikbaarheid vanaf de host van de subscriber in plaats van vanaf de robot. De TCPROS-poort wordt tijdens de onderhandeling gekozen, dus de nuttige vroege test is de XMLRPC-poort en de nuttige late test is de opgezette socket. Een route die maar in één richting bestaat is een veelvoorkomende fout op gerouteerde VPN's, en de terugweg telt even zwaar als de heenweg.

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

Een gerouteerde TUN-interface draagt deze IP-gesprekken zonder het Ethernet-segment van de robot uit te breiden, wat een externe operator meestal wil. Als iets in de stack in plaats daarvan afhankelijk is van broadcast of multicast, moet die eis apart worden beoordeeld; de tunnel naar TAP omzetten om één hulpmiddel tevreden te stellen, verbreedt het netwerk voor elke deelnemer.

Stop hier als de route of de terugweg ontbreekt. Een publisher die op zijn eigen host antwoordt maar niet vanaf het werkstation bereikbaar is, heeft een routeringsprobleem, geen ROS-probleem.

Stap 4: sta het gesprek tussen peers toe en bekijk één onderwerp

Open alleen de poorten die het onderhandelde gesprek nodig heeft, en beperk elke regel tot de aangekondigde deelnemers. De listener van de master is geen relay voor onderwerplading, dus alleen die toestaan laat het eindpunt van de publisher gesloten. Houd de ROS-listeners op de grens van de privé-VPN in plaats van ze aan het publieke internet bloot te stellen.

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

Bekijk één onschadelijk onderwerp van de echte publisher naar de echte subscriber en bevestig zowel het aangekondigde eindpunt als de antwoordweg. Eén bericht bewijst dat de weg werkt; een stabiel tempo bewijst dat hij open blijft. Houd actuatorbesturing en veiligheidscontroles buiten deze test die alleen over het netwerk gaat, want een werkend onderwerp certificeert geen werkende robot. Leg de ROS-versie en het waargenomen eindpuntpaar vast, zodat de volgende persoon een topologiewijziging van een regressie kan onderscheiden.

De checklist is klaar wanneer de aangekondigde URI vanaf de subscriber bereikbaar is, de onderhandelde poort alleen voor die peer open is, één aangekondigd onderwerp stroomt en de omgevingswaarden voor beide hosts zijn vastgelegd. De oude ROS 1 krijgt op dit gebied geen correcties meer, dus het verslag is het deel dat blijft werken nadat de mensen wisselen.