ROS 1-onderwerpe oor ’n VPN: volg die geadverteerde eindpunt

Jou werkstasie bereik die ROS 1-meester oor die tonnel en wys steeds ’n leë lys onderwerpe. Daardie patroon is algemeen omdat meesterregistrasie en onderwerpvervoer twee verskillende gesprekke is, en net die eerste een gaan deur die meester. Die kontrolelys hieronder volg die tweede gesprek: die eindpunt wat ’n publiseerder adverteer, die adres wat ’n intekenaar moet kan bereik, en die toestemming wat die paar laat praat. Alles hier geld net vir die ouer ROS 1, wie se Noetic-ondersteuningsvenster in Mei 2025 geëindig het.

Stap 1: bewys dat die meesterverbinding nie die onderwerpverbinding is

Begin deur te skei wat werk van wat nie werk nie. ’n Geslaagde rostopic list bewys dat jou dop die meester se XMLRPC-poort kan bereik en dat die meester van onderwerpe weet; dit sê niks oor of ’n intekenaar die publiseerder kan bereik nie. Die drie opdragte hieronder maak die onderskeid sigbaar, en almal is net-lees.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

Die uitvoer van rostopic info noem die publiseerder se nodus-URI, wat ’n XMLRPC-adres op die publiseerder se gasheer is. Daardie adres is die een wat jou intekenaar volgende sal roep, so dit moet bereikbaar wees van waar die intekenaar ook al loop. As dit na ’n koppelvlak wys wat net op die robot se eie LAN bestaan, slaag die meester-soektog en kom die data nooit aan nie.

Stap 2: lees die geadverteerde eindpunt by die nodus self

ROS 1 kies sy geadverteerde gasheeridentiteit uit ROS_IP of ROS_HOSTNAME wanneer een van hulle gestel is, en val andersins terug op die gasheer se eie naamresolusie. Ondersoek die omgewing van die proses wat werklik begin is, want ’n systemd-eenheid, ’n houer of ’n tweede terminaal kan ’n ander waarde dra as die dop waar jou toets gewerk het.

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

’n Gasheernaam-advertensie werk net as elke eweknie daardie naam na die bedoelde bereikbare adres oplos. As daardie naam net binne die robot se eie netwerk oplos, het ’n werkstasie aan die ander kant van die tonnel geen manier om dit te gebruik nie, en ’n VPN wat geen DNS-agtervoegsel stoot nie maak die wanverhouding erger. Om ROS_IP op die tonneladres te stel is die kleiner verandering wanneer die topologie gerouteer is. Watter een jy ook kies, teken dit vir beide kante aan, want ’n publiseerder en ’n intekenaar wat oor identiteit verskil, sal onderhandel en dan nie kan koppel nie.

Stop hier as die geadverteerde URI ’n adres gebruik wat geen eweknie kan routeer nie. Geen hoeveelheid firewall-werk sal ’n naam regstel wat na die verkeerde koppelvlak oplos nie.

Stap 3: maak die geadverteerde adres oplosbaar en gerouteer

Met die URI in die hand, toets bereikbaarheid vanaf die intekenaar se gasheer eerder as vanaf die robot. Die TCPROS-poort word tydens onderhandeling gekies, so die nuttige vroeë toets is die XMLRPC-poort en die nuttige latere toets is die gevestigde sok. ’n Roete wat net in een rigting bestaan is ’n algemene fout op gerouteerde VPN's, en die terugpad maak net soveel saak soos die voorpad.

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

’n Gerouteerde TUN-koppelvlak dra hierdie IP-gesprekke sonder om die robot se Ethernet-segment te verleng, wat gewoonlik is wat ’n afgeleë operateur wil hê. As iets in die stapel eerder van uitsending of multicast afhang, moet daardie vereiste op sy eie geëvalueer word; om die tonnel na TAP te omskep om een gereedskap te bevredig, verbreed die netwerk vir elke deelnemer.

Stop hier as die roete of die terugpad ontbreek. ’n Publiseerder wat op sy eie gasheer antwoord maar nie van die werkstasie bereik kan word nie, het ’n roeteprobleem, nie ’n ROS-probleem nie.

Stap 4: laat die eweknie-gesprek toe en kyk na een onderwerp

Maak net die poorte oop wat die onderhandelde gesprek nodig het, en beperk elke reël tot die verklaarde deelnemers. Die meester se luisteraar is nie ’n aflos vir onderwerpladings nie, so om net dit toe te laat laat die publiseerder se eindpunt gesluit. Hou die ROS-luisteraars op die private VPN-grens in plaas daarvan om hulle aan die publieke internet bloot te stel.

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

Kyk na een onskadelike onderwerp van die werklike publiseerder na die werklike intekenaar en bevestig beide die geadverteerde eindpunt en die antwoordpad. ’n Enkele boodskap bewys die pad werk; ’n bestendige tempo bewys dit bly oop. Hou aandrywerbeheer en veiligheidskontroles buite hierdie toets wat net die netwerk raak, want ’n werkende onderwerp sertifiseer nie ’n werkende robot nie. Teken die ROS-weergawe en die eindpuntpaar aan wat jy waargeneem het, sodat die volgende persoon ’n topologieverandering van ’n regressie kan onderskei.

Die kontrolelys is klaar wanneer die geadverteerde URI vanaf die intekenaar bereikbaar is, die onderhandelde poort net vir daardie eweknie oop is, een verklaarde onderwerp vloei, en die omgewingswaardes vir beide gashere neergeskryf is. Ouer ROS 1 sal geen regstellings in hierdie area ontvang nie, so die rekord is die deel wat bly werk nadat die mense verander.