Temas de ROS 1 por VPN: siga o punto final anunciado

A súa estación de traballo chega ao master de ROS 1 polo túnel e aínda mostra unha lista de temas baleira. Ese patrón é habitual porque o rexistro no master e o transporte de temas son dúas conversas distintas, e só a primeira pasa polo master. A lista de comprobación seguinte percorre a segunda conversa: o punto final que anuncia un publicador, o enderezo ao que debe chegar un subscritor e o permiso que deixa falar á parella. Todo aquí limítase ao ROS 1 antigo, cuxa xanela de soporte de Noetic rematou en maio de 2025.

Paso 1: demostre que a conexión co master non é a conexión co tema

Comece separando o que funciona do que non. Un rostopic list correcto demostra que a súa shell pode chegar ao porto XMLRPC do master e que o master coñece temas; non di nada sobre se un subscritor pode chegar ao publicador. Os tres comandos seguintes fan visible a distinción, e todos son de só lectura.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

A saída de rostopic info indica o URI do nodo do publicador, que é un enderezo XMLRPC no host do publicador. Ese enderezo é o que o seu subscritor chamará despois, así que debe ser alcanzable desde onde se execute o subscritor. Se apunta a unha interface que só existe na LAN do propio robot, a busca no master ten éxito e os datos nunca chegan.

Paso 2: lea o punto final anunciado desde o propio nodo

ROS 1 escolle a súa identidade de host anunciada a partir de ROS_IP ou ROS_HOSTNAME cando un dos dous está definido, e doutro xeito recorre á resolución de nomes propia do host. Inspeccione a contorna do proceso que realmente se lanzou, porque unha unidade de systemd, un contedor ou un segundo terminal poden levar un valor distinto do da shell onde funcionou a súa proba.

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

Un anuncio de nome de host só funciona se cada par resolve ese nome cara ao enderezo alcanzable previsto. Se ese nome só se resolve dentro da rede propia do robot, unha estación de traballo ao outro lado do túnel non ten forma de usalo, e unha VPN que non empuxa ningún sufixo DNS empeora a discrepancia. Definir ROS_IP co enderezo do túnel é o cambio máis pequeno cando a topoloxía é encamiñada. Elixa o que elixa, anóteo para ambos os extremos, porque un publicador e un subscritor que non coinciden na identidade negociarán e despois non poderán conectar.

Detéñase aquí se o URI anunciado usa un enderezo ao que ningún par pode encamiñar. Ningunha cantidade de traballo no cortafogos arranxará un nome que se resolve cara á interface equivocada.

Paso 3: faga que o enderezo anunciado sexa resoluble e encamiñado

Co URI na man, probe a alcanzabilidade desde o host do subscritor en lugar de desde o robot. O porto TCPROS escóllese durante a negociación, así que a proba temperá útil é o porto XMLRPC e a proba tardía útil é o socket establecido. Unha ruta que só existe nunha dirección é un fallo habitual nas VPN encamiñadas, e o camiño de volta importa tanto como o de ida.

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

Unha interface TUN encamiñada transporta estas conversas IP sen ampliar o segmento Ethernet do robot, que adoita ser o que quere un operador remoto. Se algo da pila depende en cambio de broadcast ou multicast, ese requisito debe avaliarse por separado; converter o túnel en TAP para satisfacer unha soa ferramenta amplía a rede para todos os participantes.

Detéñase aquí se falta a ruta ou o camiño de volta. Un publicador que responde no seu propio host pero non é alcanzable desde a estación de traballo ten un problema de encamiñamento, non un problema de ROS.

Paso 4: permita a conversa entre pares e observe un tema

Abra só os portos que necesita a conversa negociada e limite cada regra aos participantes declarados. O oínte do master non é un relé para a carga dos temas, así que permitir só ese deixa pechado o punto final do publicador. Manteña os oíntes de ROS na fronteira da VPN privada en lugar de expoñelos a internet público.

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

Observe un tema inofensivo desde o publicador real ata o subscritor real e confirme tanto o punto final anunciado como o camiño de resposta. Unha soa mensaxe demostra que o camiño funciona; unha taxa estable demostra que segue aberto. Manteña o control de actuadores e as comprobacións de seguridade fóra desta proba só de rede, porque un tema que funciona non certifica un robot que funciona. Anote a versión de ROS e o par de puntos finais que observou, para que a seguinte persoa poida distinguir un cambio de topoloxía dunha regresión.

A lista de comprobación remata cando o URI anunciado é alcanzable desde o subscritor, o porto negociado está aberto só para ese par, un tema declarado flúe e os valores de contorna están escritos para ambos os hosts. O ROS 1 antigo non recibirá correccións nesta área, así que o rexistro é a parte que segue funcionando despois de que cambien as persoas.