ROS 1-emner over en VPN: følg det annoncerede endepunkt

Din arbejdsstation når ROS 1-masteren gennem tunnelen og viser stadig en tom emneliste. Det mønster er almindeligt, fordi masterregistrering og emnetransport er to forskellige samtaler, og kun den første går gennem masteren. Tjeklisten nedenfor går gennem den anden samtale: det endepunkt, en udgiver annoncerer, den adresse, en abonnent skal kunne nå, og den tilladelse, der lader parret tale sammen. Alt her gælder kun den gamle ROS 1, hvis Noetic-supportvindue sluttede i maj 2025.

Trin 1: bevis, at masterforbindelsen ikke er emneforbindelsen

Begynd med at skille det, der virker, fra det, der ikke gør. En vellykket rostopic list beviser, at din shell kan nå masterens XMLRPC-port, og at masteren kender emner; den siger intet om, hvorvidt en abonnent kan nå udgiveren. De tre kommandoer nedenfor gør forskellen synlig, og alle er skrivebeskyttede.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

Outputtet fra rostopic info angiver udgiverens node-URI, som er en XMLRPC-adresse på udgiverens vært. Det er den adresse, din abonnent kalder næste gang, så den skal være nåbar fra hvor som helst abonnenten kører. Hvis den peger på et interface, der kun findes på robottens eget LAN, lykkes masteropslaget, og dataene kommer aldrig frem.

Trin 2: læs det annoncerede endepunkt fra noden selv

ROS 1 vælger sin annoncerede værtidentitet ud fra ROS_IP eller ROS_HOSTNAME, når en af dem er sat, og falder ellers tilbage på værtens egen navneopløsning. Undersøg miljøet for den proces, der faktisk blev startet, fordi en systemd-unit, en container eller en anden terminal kan have en anden værdi end den shell, hvor din test virkede.

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

En værtsnavneannoncering virker kun, hvis hver peer opløser det navn til den tilsigtede nåbare adresse. Hvis det navn kun opløses inde i robottens eget netværk, har en arbejdsstation på den anden side af tunnelen ingen måde at bruge det på, og en VPN, der ikke skubber noget DNS-suffiks, gør uoverensstemmelsen værre. At sætte ROS_IP til tunneladressen er den mindre ændring, når topologien er rutet. Uanset hvad du vælger, skal du skrive det ned for begge ender, fordi en udgiver og en abonnent, der er uenige om identitet, vil forhandle og derefter ikke kunne forbinde.

Stop her, hvis den annoncerede URI bruger en adresse, som ingen peer kan rute til. Ingen mængde firewallarbejde retter et navn, der opløses til det forkerte interface.

Trin 3: gør den annoncerede adresse opløselig og rutet

Med URI'en i hånden testes nåbarhed fra abonnentens vært i stedet for fra robotten. TCPROS-porten vælges under forhandlingen, så den nyttige tidlige test er XMLRPC-porten, og den nyttige senere test er den etablerede socket. En rute, der kun findes i én retning, er en almindelig fejl på rutede VPN'er, og returvejen betyder lige så meget som vejen 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-interface bærer disse IP-samtaler uden at udvide robottens Ethernet-segment, hvilket normalt er det, en fjernoperatør ønsker. Hvis noget i stakken i stedet afhænger af broadcast eller multicast, skal det krav vurderes for sig; at konvertere tunnelen til TAP for at tilfredsstille ét værktøj udvider netværket for hver deltager.

Stop her, hvis ruten eller returvejen mangler. En udgiver, der svarer på sin egen vært, men ikke kan nås fra arbejdsstationen, har et ruteproblem, ikke et ROS-problem.

Trin 4: tillad peer-samtalen og se ét emne

Åbn kun de porte, som den forhandlede samtale har brug for, og afgræns hver regel til de erklærede deltagere. Masterens lytter er ikke et relay for emnenytteslast, så tilladelse alene til den lader udgiverens endepunkt være lukket. Hold ROS-lytterne på den private VPN-grænse i stedet for at eksponere dem mod det offentlige internet.

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

Se ét harmløst emne fra den rigtige udgiver til den rigtige abonnent, og bekræft både det annoncerede endepunkt og svarvejen. En enkelt besked beviser, at vejen virker; en stabil frekvens beviser, at den forbliver åben. Hold aktuatorstyring og sikkerhedstjek uden for denne test, der kun handler om netværket, fordi et fungerende emne ikke certificerer en fungerende robot. Skriv ROS-versionen og det endepunktpar, du observerede, så den næste person kan skelne en topologiændring fra en regression.

Tjeklisten er færdig, når den annoncerede URI er nåbar fra abonnenten, den forhandlede port kun er åben for den peer, ét erklæret emne flyder, og miljøværdierne er skrevet ned for begge værter. Gammel ROS 1 får ikke rettelser på dette område, så registreringen er den del, der bliver ved med at virke, efter at folkene skifter.