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

Su estación de trabajo llega al maestro de ROS 1 por el túnel y aun así muestra una lista de temas vacía. Ese patrón es habitual porque el registro en el maestro y el transporte de temas son dos conversaciones distintas, y solo la primera pasa por el maestro. La lista de comprobación siguiente recorre la segunda conversación: el punto final que anuncia un publicador, la dirección a la que debe llegar un suscriptor y el permiso que permite que la pareja hable. Todo aquí se limita al ROS 1 antiguo, cuya ventana de soporte de Noetic terminó en mayo de 2025.

Paso 1: demuestre que la conexión con el maestro no es la conexión con el tema

Empiece separando lo que funciona de lo que no. Un rostopic list correcto demuestra que su shell puede llegar al puerto XMLRPC del maestro y que el maestro conoce temas; no dice nada sobre si un suscriptor puede llegar al publicador. Los tres comandos siguientes hacen visible la distinción, y todos son de solo lectura.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

La salida de rostopic info indica el URI del nodo del publicador, que es una dirección XMLRPC en el host del publicador. Esa dirección es la que su suscriptor llamará después, así que debe ser alcanzable desde donde se ejecute el suscriptor. Si apunta a una interfaz que solo existe en la LAN del propio robot, la búsqueda en el maestro tiene éxito y los datos nunca llegan.

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

ROS 1 elige su identidad de host anunciada a partir de ROS_IP o ROS_HOSTNAME cuando uno de los dos está definido, y en caso contrario recurre a la resolución de nombres propia del host. Inspeccione el entorno del proceso que realmente se lanzó, porque una unidad de systemd, un contenedor o un segundo terminal pueden llevar un valor distinto del de la shell donde funcionó su prueba.

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

Un anuncio de nombre de host solo funciona si cada par resuelve ese nombre a la dirección alcanzable prevista. Si ese nombre solo se resuelve dentro de la red propia del robot, una estación de trabajo al otro lado del túnel no tiene forma de usarlo, y una VPN que no empuja ningún sufijo DNS empeora la discrepancia. Definir ROS_IP con la dirección del túnel es el cambio más pequeño cuando la topología es enrutada. Elija lo que elija, anótelo para ambos extremos, porque un publicador y un suscriptor que no coinciden en la identidad negociarán y luego no podrán conectar.

Deténgase aquí si el URI anunciado usa una dirección a la que ningún par puede enrutar. Ninguna cantidad de trabajo en el cortafuegos arreglará un nombre que se resuelve a la interfaz equivocada.

Paso 3: haga que la dirección anunciada sea resoluble y enrutada

Con el URI en la mano, pruebe la alcanzabilidad desde el host del suscriptor en lugar de desde el robot. El puerto TCPROS se elige durante la negociación, así que la prueba temprana útil es el puerto XMLRPC y la prueba tardía útil es el socket establecido. Una ruta que solo existe en una dirección es un fallo habitual en las VPN enrutadas, y el camino de vuelta importa tanto como el de ida.

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

Una interfaz TUN enrutada transporta estas conversaciones IP sin ampliar el segmento Ethernet del robot, que suele ser lo que quiere un operador remoto. Si algo de la pila depende en cambio de broadcast o multicast, ese requisito debe evaluarse por separado; convertir el túnel en TAP para satisfacer una sola herramienta amplía la red para todos los participantes.

Deténgase aquí si falta la ruta o el camino de vuelta. Un publicador que responde en su propio host pero no es alcanzable desde la estación de trabajo tiene un problema de enrutamiento, no un problema de ROS.

Paso 4: permita la conversación entre pares y observe un tema

Abra solo los puertos que necesita la conversación negociada y limite cada regla a los participantes declarados. El oyente del maestro no es un relé para la carga de los temas, así que permitir solo ese deja cerrado el punto final del publicador. Mantenga los oyentes de ROS en el límite de la VPN privada en lugar de exponerlos a internet público.

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

Observe un tema inofensivo desde el publicador real hasta el suscriptor real y confirme tanto el punto final anunciado como el camino de respuesta. Un solo mensaje demuestra que el camino funciona; una tasa estable demuestra que sigue abierto. Mantenga el control de actuadores y las comprobaciones de seguridad fuera de esta prueba solo de red, porque un tema que funciona no certifica un robot que funciona. Anote la versión de ROS y el par de puntos finales que observó, para que la siguiente persona pueda distinguir un cambio de topología de una regresión.

La lista de comprobación termina cuando el URI anunciado es alcanzable desde el suscriptor, el puerto negociado está abierto solo para ese par, un tema declarado fluye y los valores de entorno están escritos para ambos hosts. El ROS 1 antiguo no recibirá correcciones en esta área, así que el registro es la parte que sigue funcionando después de que cambien las personas.