Теми ROS 1 через VPN: дотримуйтесь оголошеної кінцевої точки

Реєстрація в master ROS 1 не передає дані тем. Прочитайте оголошений URI вузла, зробіть цю адресу маршрутизованою, потім дозвольте порт публікатора.

Ваша робоча станція досягає master ROS 1 через тунель і все одно показує порожній список тем. Ця картина звична, бо реєстрація в master і передавання тем — це дві різні розмови, і через master проходить лише перша. Контрольний список нижче проходить другу розмову: кінцеву точку, яку оголошує публікатор, адресу, до якої має дістатися передплатник, і дозвіл, що дає парі змогу говорити. Усе тут стосується лише старого ROS 1, вікно підтримки Noetic якого завершилося в травні 2025.

Крок 1: доведіть, що з'єднання з master — не з'єднання з темою

Почніть із відокремлення того, що працює, від того, що не працює. Успішний rostopic list доводить, що ваша оболонка досягає порту XMLRPC master і що master знає про теми; він нічого не каже про те, чи може передплатник дістатися публікатора. Три команди нижче роблять цю різницю видимою, і всі вони лише для читання.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

Вивід rostopic info називає URI вузла публікатора, тобто адресу XMLRPC на хості публікатора. Саме цю адресу ваш передплатник викличе наступною, тому вона має бути доступною звідусіль, де працює передплатник. Якщо вона вказує на інтерфейс, що існує лише в локальній мережі самого робота, пошук у master успішний, а дані так і не надходять.

Крок 2: прочитайте оголошену кінцеву точку з самого вузла

ROS 1 вибирає оголошену ідентичність хоста з ROS_IP або ROS_HOSTNAME, коли одну з них задано, а інакше повертається до власного розв'язання імен хоста. Перегляньте середовище процесу, який справді було запущено, бо unit systemd, контейнер або другий термінал можуть нести інше значення, ніж оболонка, у якій працював ваш тест.

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

Оголошення імені хоста працює лише тоді, коли кожен партнер розв'язує це ім'я в потрібну доступну адресу. Якщо це ім'я розв'язується лише всередині власної мережі робота, робоча станція з іншого боку тунелю ніяк не може його використати, а VPN, який не передає жодного суфікса DNS, робить невідповідність ще гіршою. Коли топологія маршрутизована, встановлення ROS_IP на адресу тунелю — менша зміна. Що б ви не обрали, запишіть це для обох кінців, бо публікатор і передплатник, які розходяться в ідентичності, проведуть переговори і потім не зможуть підключитися.

Зупиніться тут, якщо оголошений URI використовує адресу, до якої жоден партнер не може прокласти маршрут. Жодна робота з міжмережевим екраном не виправить ім'я, що розв'язується в неправильний інтерфейс.

Крок 3: зробіть оголошену адресу розв'язуваною та маршрутизованою

Маючи URI в руках, перевіряйте доступність з хоста передплатника, а не з робота. Порт TCPROS вибирається під час переговорів, тому корисна рання перевірка — це порт XMLRPC, а корисна пізня перевірка — встановлений сокет. Маршрут, що існує лише в одному напрямку, — часта несправність у маршрутизованих VPN, і зворотний шлях важливий не менше за прямий.

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

Маршрутизований інтерфейс TUN несе ці IP-розмови, не розширюючи сегмент Ethernet робота, чого зазвичай і хоче віддалений оператор. Якщо щось у стеку залежить натомість від широкомовлення або multicast, цю вимогу треба оцінювати окремо; перетворення тунелю на TAP заради одного інструмента розширює мережу для кожного учасника.

Зупиніться тут, якщо маршрут або зворотний шлях відсутній. У публікатора, який відповідає на своєму хості, але недоступний з робочої станції, проблема маршрутизації, а не проблема ROS.

Крок 4: дозвольте розмову партнерів і спостерігайте одну тему

Відкрийте лише ті порти, які потрібні узгодженій розмові, і обмежте кожне правило оголошеними учасниками. Слухач master не є ретранслятором корисного навантаження тем, тому дозвіл лише для нього залишає кінцеву точку публікатора закритою. Тримайте слухачів ROS на межі приватного VPN, а не виставляйте їх у публічний інтернет.

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

Спостерігайте одну безпечну тему від справжнього публікатора до справжнього передплатника і підтвердьте і оголошену кінцеву точку, і шлях відповіді. Одне повідомлення доводить, що шлях працює; стала частота доводить, що він залишається відкритим. Тримайте керування приводами та перевірки безпеки поза цим тестом, що стосується лише мережі, бо робоча тема не засвідчує робочого робота. Запишіть версію ROS і спостережувану пару кінцевих точок, щоб наступна людина могла відрізнити зміну топології від регресії.

Контрольний список завершено, коли оголошений URI доступний з передплатника, узгоджений порт відкритий лише для цього партнера, одна оголошена тема тече і значення середовища записані для обох хостів. Старий ROS 1 не отримає виправлень у цій галузі, тому запис — та частина, що продовжує працювати після зміни людей.

Схожі статті