Tópicos do ROS 1 por VPN: siga o endpoint anunciado

A sua estação de trabalho alcança o master do ROS 1 pelo túnel e continua a mostrar uma lista de tópicos vazia. Esse padrão é comum porque o registo no master e o transporte de tópicos são duas conversas diferentes, e só a primeira passa pelo master. A lista de verificação abaixo percorre a segunda conversa: o endpoint que um publicador anuncia, o endereço que um subscritor tem de conseguir alcançar e a permissão que deixa o par falar. Tudo aqui aplica-se apenas ao ROS 1 antigo, cuja janela de suporte do Noetic terminou em maio de 2025.

Passo 1: prove que a ligação ao master não é a ligação ao tópico

Comece por separar o que funciona do que não funciona. Um rostopic list bem-sucedido prova que a sua shell alcança a porta XMLRPC do master e que o master conhece tópicos; não diz nada sobre se um subscritor consegue alcançar o publicador. Os três comandos abaixo tornam essa distinção visível, e todos são apenas de leitura.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

A saída de rostopic info indica o URI do nó do publicador, que é um endereço XMLRPC no anfitrião do publicador. É esse o endereço que o seu subscritor vai chamar a seguir, por isso tem de ser alcançável de onde quer que o subscritor corra. Se apontar para uma interface que só existe na LAN do próprio robô, a procura no master é bem-sucedida e os dados nunca chegam.

Passo 2: leia o endpoint anunciado a partir do próprio nó

O ROS 1 escolhe a identidade de anfitrião anunciada a partir de ROS_IP ou ROS_HOSTNAME quando um deles está definido, e caso contrário recorre à resolução de nomes do próprio anfitrião. Inspecione o ambiente do processo que foi realmente lançado, porque uma unidade systemd, um contentor ou um segundo terminal podem transportar um valor diferente do da shell onde o seu teste funcionou.

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

Um anúncio de nome de anfitrião só funciona se cada par resolver esse nome para o endereço alcançável pretendido. Se esse nome só for resolvido dentro da rede do próprio robô, uma estação de trabalho do outro lado do túnel não tem forma de o usar, e uma VPN que não empurra qualquer sufixo DNS piora a discrepância. Definir ROS_IP para o endereço do túnel é a alteração mais pequena quando a topologia é encaminhada. Escolha o que escolher, registe-o para as duas extremidades, porque um publicador e um subscritor que discordam sobre a identidade vão negociar e depois não conseguem ligar-se.

Pare aqui se o URI anunciado usar um endereço para o qual nenhum par consegue encaminhar. Nenhum trabalho na firewall corrige um nome que é resolvido para a interface errada.

Passo 3: torne o endereço anunciado resolvível e encaminhado

Com o URI na mão, teste a alcançabilidade a partir do anfitrião do subscritor e não a partir do robô. A porta TCPROS é escolhida durante a negociação, por isso o teste inicial útil é a porta XMLRPC e o teste tardio útil é o socket estabelecido. Uma rota que só existe num sentido é uma falha comum em VPN encaminhadas, e o caminho de volta conta 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

Uma interface TUN encaminhada transporta estas conversas IP sem ampliar o segmento Ethernet do robô, que é normalmente o que um operador remoto quer. Se algo na pilha depender antes de broadcast ou multicast, esse requisito tem de ser avaliado à parte; converter o túnel em TAP para satisfazer uma única ferramenta alarga a rede a todos os participantes.

Pare aqui se faltar a rota ou o caminho de volta. Um publicador que responde no seu próprio anfitrião mas não é alcançável a partir da estação de trabalho tem um problema de encaminhamento, não um problema de ROS.

Passo 4: permita a conversa entre pares e observe um tópico

Abra apenas as portas de que a conversa negociada precisa, e limite cada regra aos participantes declarados. O ouvinte do master não é um relé para a carga dos tópicos, por isso permitir só esse deixa o endpoint do publicador fechado. Mantenha os ouvintes do ROS na fronteira da VPN privada em vez de os expor à internet pública.

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

Observe um tópico inofensivo do publicador real para o subscritor real e confirme tanto o endpoint anunciado como o caminho de resposta. Uma única mensagem prova que o caminho funciona; uma taxa estável prova que se mantém aberto. Mantenha o controlo dos atuadores e as verificações de segurança fora deste teste apenas de rede, porque um tópico a funcionar não certifica um robô a funcionar. Registe a versão do ROS e o par de endpoints observado, para que a próxima pessoa consiga distinguir uma mudança de topologia de uma regressão.

A lista de verificação termina quando o URI anunciado é alcançável a partir do subscritor, a porta negociada está aberta apenas para esse par, um tópico declarado flui e os valores de ambiente estão escritos para os dois anfitriões. O ROS 1 antigo não vai receber correções nesta área, por isso o registo é a parte que continua a funcionar depois de as pessoas mudarem.