ROS 1-emner over en VPN: følg det annonserte endepunktet
En ROS 1-masterregistrering frakter ikke emnedata. Les den annonserte node-URI-en, gjør den adressen rutbar, og tillat deretter porten til utgiveren.
Arbeidsstasjonen din når ROS 1-masteren gjennom tunnelen og viser fortsatt en tom emneliste. Det mønsteret er vanlig fordi masterregistrering og emnetransport er to forskjellige samtaler, og bare den første går gjennom masteren. Sjekklisten nedenfor går gjennom den andre samtalen: endepunktet en utgiver annonserer, adressen en abonnent må kunne nå, og tillatelsen som lar paret snakke sammen. Alt her gjelder bare den gamle ROS 1, hvis Noetic-støttevindu ble avsluttet i mai 2025.
Trinn 1: bevis at masterforbindelsen ikke er emneforbindelsen
Begynn med å skille det som virker fra det som ikke virker. En vellykket rostopic list beviser at skallet ditt når XMLRPC-porten til masteren og at masteren kjenner emnene; det sier ingenting om hvorvidt en abonnent kan nå utgiveren. De tre kommandoene nedenfor gjør forskjellen synlig, og alle er skrivebeskyttet.
echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter
Utdataene fra rostopic info navngir node-URI-en til utgiveren, som er en XMLRPC-adresse på verten til utgiveren. Det er adressen abonnenten din vil kalle neste gang, så den må være nåbar fra hvor som helst abonnenten kjører. Hvis den peker på et grensesnitt som bare finnes på robotens eget LAN, lykkes mastersøket, og dataene kommer aldri frem.
Trinn 2: les det annonserte endepunktet fra noden selv
ROS 1 velger sin annonserte vertsidentitet fra ROS_IP eller ROS_HOSTNAME når en av dem er satt, og faller ellers tilbake på vertens egen navneoppslag. Undersøk miljøet til prosessen som faktisk ble startet, fordi en systemd-enhet, en container eller en annen terminal kan bære en annen verdi enn skallet der testen din virket.
echo "$ROS_IP" "$ROS_HOSTNAME"
rosnode info /talker
getent hosts robot-host
En vertsnavnannonse virker bare hvis hver peer slår opp det navnet til den tiltenkte nåbare adressen. Hvis det navnet bare slås opp inne i robotens eget nettverk, har en arbeidsstasjon på den andre siden av tunnelen ingen måte å bruke det på, og en VPN som ikke skyver noe DNS-suffiks gjør avviket verre. Å sette ROS_IP til tunneladressen er den minste endringen når topologien er rutet. Uansett hva du velger, skriv det ned for begge ender, fordi en utgiver og en abonnent som er uenige om identitet vil forhandle og deretter ikke kunne koble til.
Stopp her hvis den annonserte URI-en bruker en adresse som ingen peer kan rute til. Ingen mengde brannmurarbeid retter et navn som slås opp til feil grensesnitt.
Trinn 3: gjør den annonserte adressen oppslåelig og rutet
Med URI-en i hånden tester du nåbarhet fra verten til abonnenten i stedet for fra roboten. TCPROS-porten velges under forhandlingen, så den nyttige tidlige testen er XMLRPC-porten, og den nyttige sene testen er den etablerte sockelen. En rute som bare finnes i én retning er en vanlig feil på rutede VPN-er, og returveien betyr like mye som veien frem.
ip route get 10.70.0.2
nc -vz 10.70.0.2 33911
ss -tnp dst 10.70.0.2
Et rutet TUN-grensesnitt bærer disse IP-samtalene uten å utvide Ethernet-segmentet til roboten, som vanligvis er det en fjernoperatør ønsker. Hvis noe i stakken i stedet er avhengig av kringkasting eller multicast, må det kravet vurderes separat; å gjøre tunnelen om til TAP for å tilfredsstille ett verktøy utvider nettverket for hver deltaker.
Stopp her hvis ruten eller returveien mangler. En utgiver som svarer på sin egen vert, men ikke kan nås fra arbeidsstasjonen, har et ruteproblem, ikke et ROS-problem.
Trinn 4: tillat peer-samtalen og se på ett emne
Åpne bare portene den forhandlede samtalen trenger, og begrens hver regel til de erklærte deltakerne. Lytteren til masteren er ikke en videresender for emnenyttelast, så å tillate bare den lar endepunktet til utgiveren være lukket. Hold ROS-lytterne på grensen til det private VPN-et i stedet for å eksponere dem mot det offentlige internettet.
rostopic hz /chatter
rostopic echo -n1 /chatter
rosnode ping /talker
Se på ett ufarlig emne fra den virkelige utgiveren til den virkelige abonnenten og bekreft både det annonserte endepunktet og svarveien. Én melding beviser at veien virker; en jevn rate beviser at den holder seg åpen. Hold aktuatorstyring og sikkerhetskontroller utenfor denne testen som bare handler om nettverket, fordi et fungerende emne ikke sertifiserer en fungerende robot. Skriv ned ROS-versjonen og endepunktparet du observerte, slik at neste person kan skille en topologiendring fra en regresjon.
Sjekklisten er ferdig når den annonserte URI-en er nåbar fra abonnenten, den forhandlede porten er åpen bare for den peeren, ett erklært emne flyter, og miljøverdiene er skrevet ned for begge vertene. Gammel ROS 1 vil ikke få rettelser på dette området, så registreringen er den delen som fortsetter å virke etter at folkene byttes ut.