Temes de ROS 1 per VPN: seguiu el punt final anunciat

La vostra estació de treball arriba al master de ROS 1 pel túnel i encara mostra una llista de temes buida. Aquest patró és habitual perquè el registre al master i el transport de temes són dues converses diferents, i només la primera passa pel master. La llista de comprovació següent recorre la segona conversa: el punt final que anuncia un publicador, l’adreça a la qual ha d’arribar un subscriptor i el permís que permet que la parella parli. Tot això es limita al ROS 1 antic, la finestra de suport del qual per a Noetic va acabar el maig de 2025.

Pas 1: demostreu que la connexió amb el master no és la connexió amb el tema

Comenceu separant el que funciona del que no. Un rostopic list correcte demostra que la vostra shell pot arribar al port XMLRPC del master i que el master coneix temes; no diu res sobre si un subscriptor pot arribar al publicador. Les tres ordres següents fan visible la distinció, i totes són només de lectura.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

La sortida de rostopic info indica l’URI del node del publicador, que és una adreça XMLRPC a l’amfitrió del publicador. Aquesta adreça és la que el vostre subscriptor cridarà després, així que ha de ser abastable des d’on s’executi el subscriptor. Si apunta a una interfície que només existeix a la LAN del mateix robot, la cerca al master té èxit i les dades no arriben mai.

Pas 2: llegiu el punt final anunciat des del mateix node

ROS 1 tria la seva identitat d’amfitrió anunciada a partir de ROS_IP o ROS_HOSTNAME quan un dels dos està definit, i en cas contrari recorre a la resolució de noms pròpia de l’amfitrió. Inspeccioneu l’entorn del procés que realment s’ha iniciat, perquè una unitat de systemd, un contenidor o un segon terminal poden portar un valor diferent del de la shell on va funcionar la vostra prova.

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

Un anunci de nom d’amfitrió només funciona si cada parell resol aquest nom a l’adreça abastable prevista. Si aquest nom només es resol dins de la xarxa pròpia del robot, una estació de treball a l’altre costat del túnel no té manera d’utilitzar-lo, i una VPN que no empeny cap sufix DNS empitjora la discrepància. Definir ROS_IP amb l’adreça del túnel és el canvi més petit quan la topologia és encaminada. Tant si trieu un com l’altre, anoteu-ho per als dos extrems, perquè un publicador i un subscriptor que no coincideixen en la identitat negociaran i després no podran connectar.

Atureu-vos aquí si l’URI anunciat utilitza una adreça a la qual cap parell no pot encaminar. Cap quantitat de feina de tallafoc no arreglarà un nom que es resol a la interfície equivocada.

Pas 3: feu que l’adreça anunciada sigui resoluble i encaminada

Amb l’URI a la mà, proveu l’abastabilitat des de l’amfitrió del subscriptor i no des del robot. El port TCPROS es tria durant la negociació, així que la prova inicial útil és el port XMLRPC i la prova posterior útil és el sòcol establert. Una ruta que només existeix en una direcció és una fallada habitual a les VPN encaminades, i el camí de tornada importa tant com el d’anada.

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

Una interfície TUN encaminada transporta aquestes converses IP sense ampliar el segment Ethernet del robot, que normalment és el que vol un operador remot. Si alguna cosa de la pila depèn en canvi de broadcast o multicast, aquest requisit s’ha d’avaluar a part; convertir el túnel en TAP per satisfer una sola eina amplia la xarxa per a tots els participants.

Atureu-vos aquí si falta la ruta o el camí de tornada. Un publicador que respon al seu propi amfitrió però no és abastable des de l’estació de treball té un problema d’encaminament, no un problema de ROS.

Pas 4: permeteu la conversa entre parells i observeu un tema

Obriu només els ports que necessita la conversa negociada i limiteu cada regla als participants declarats. L’oient del master no és un relé per a la càrrega dels temes, així que permetre només aquest deixa el punt final del publicador tancat. Manteniu els oients de ROS a la frontera de la VPN privada en lloc d’exposar-los a internet públic.

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

Observeu un tema inofensiu del publicador real al subscriptor real i confirmeu tant el punt final anunciat com el camí de resposta. Un sol missatge demostra que el camí funciona; una taxa estable demostra que es manté obert. Manteniu el control dels actuadors i les comprovacions de seguretat fora d’aquesta prova només de xarxa, perquè un tema que funciona no certifica un robot que funciona. Anoteu la versió de ROS i la parella de punts finals que heu observat, perquè la propera persona pugui distingir un canvi de topologia d’una regressió.

La llista de comprovació s’acaba quan l’URI anunciat és abastable des del subscriptor, el port negociat està obert només per a aquell parell, un tema declarat flueix i els valors d’entorn estan escrits per als dos amfitrions. El ROS 1 antic no rebrà correccions en aquesta àrea, així que el registre és la part que continua funcionant després que canviï la gent.