Topik ROS 1 lewat VPN: ikuti endpoint yang diumumkan

Workstation Anda menjangkau master ROS 1 melalui terowongan dan tetap menampilkan daftar topik yang kosong. Pola itu umum karena registrasi master dan pengangkutan topik adalah dua percakapan berbeda, dan hanya yang pertama melewati master. Daftar periksa di bawah menelusuri percakapan kedua: endpoint yang diumumkan penerbit, alamat yang harus dapat dijangkau pelanggan, dan izin yang membuat pasangan itu dapat berbicara. Semua di sini hanya berlaku untuk ROS 1 lama, yang jendela dukungan Noetic-nya berakhir pada Mei 2025.

Langkah 1: buktikan bahwa koneksi master bukan koneksi topik

Mulailah dengan memisahkan apa yang berfungsi dari apa yang tidak. rostopic list yang berhasil membuktikan bahwa shell Anda dapat menjangkau port XMLRPC master dan bahwa master mengetahui topik; itu tidak mengatakan apa pun tentang apakah pelanggan dapat menjangkau penerbit. Tiga perintah di bawah membuat perbedaan itu terlihat, dan semuanya hanya-baca.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

Keluaran rostopic info menyebut URI node penerbit, yaitu alamat XMLRPC di host penerbit. Alamat itulah yang akan dipanggil pelanggan Anda berikutnya, jadi alamat itu harus dapat dijangkau dari mana pun pelanggan berjalan. Jika alamat itu menunjuk ke antarmuka yang hanya ada di LAN robot itu sendiri, pencarian master berhasil dan data tidak pernah tiba.

Langkah 2: baca endpoint yang diumumkan dari node itu sendiri

ROS 1 memilih identitas host yang diumumkannya dari ROS_IP atau ROS_HOSTNAME bila salah satunya disetel, dan jika tidak kembali ke resolusi nama host itu sendiri. Periksa lingkungan proses yang benar-benar dijalankan, karena unit systemd, kontainer, atau terminal kedua dapat membawa nilai berbeda dari shell tempat uji Anda berhasil.

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

Pengumuman nama host hanya berfungsi jika setiap peer menyelesaikan nama itu ke alamat tujuan yang dapat dijangkau. Jika nama itu hanya diselesaikan di dalam jaringan robot sendiri, workstation di sisi lain terowongan tidak punya cara untuk memakainya, dan VPN yang tidak mendorong sufiks DNS apa pun membuat ketidakcocokan makin buruk. Menyetel ROS_IP ke alamat terowongan adalah perubahan yang lebih kecil ketika topologinya dirutekan. Apa pun yang Anda pilih, catatlah untuk kedua ujung, karena penerbit dan pelanggan yang tidak sepakat soal identitas akan bernegosiasi lalu gagal terhubung.

Berhenti di sini jika URI yang diumumkan memakai alamat yang tidak dapat dirutekan peer mana pun. Tidak ada pekerjaan firewall yang bisa memperbaiki nama yang diselesaikan ke antarmuka yang salah.

Langkah 3: buat alamat yang diumumkan dapat diselesaikan dan dirutekan

Dengan URI di tangan, uji keterjangkauan dari host pelanggan, bukan dari robot. Port TCPROS dipilih selama negosiasi, jadi uji awal yang berguna adalah port XMLRPC dan uji akhir yang berguna adalah soket yang telah terbentuk. Rute yang hanya ada di satu arah adalah kegagalan umum pada VPN yang dirutekan, dan jalur balik sama pentingnya dengan jalur maju.

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

Antarmuka TUN yang dirutekan membawa percakapan IP ini tanpa memperluas segmen Ethernet robot, yang biasanya diinginkan operator jarak jauh. Jika sesuatu di tumpukan bergantung pada siaran atau multicast, persyaratan itu harus dievaluasi sendiri; mengubah terowongan menjadi TAP demi memenuhi satu alat memperlebar jaringan bagi setiap peserta.

Berhenti di sini jika rute atau jalur balik tidak ada. Penerbit yang menjawab di hostnya sendiri tetapi tidak dapat dijangkau dari workstation memiliki masalah perutean, bukan masalah ROS.

Langkah 4: izinkan percakapan peer dan amati satu topik

Buka hanya port yang dibutuhkan percakapan yang dinegosiasikan, dan batasi setiap aturan pada peserta yang dinyatakan. Pendengar master bukan relai untuk muatan topik, jadi mengizinkannya saja membuat endpoint penerbit tetap tertutup. Pertahankan pendengar ROS di batas VPN privat alih-alih mengeksposnya ke internet publik.

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

Amati satu topik jinak dari penerbit nyata ke pelanggan nyata dan pastikan endpoint yang diumumkan serta jalur balasan. Satu pesan membuktikan jalur itu berfungsi; laju yang stabil membuktikan jalur itu tetap terbuka. Jauhkan kendali aktuator dan pemeriksaan keselamatan dari uji yang hanya soal jaringan ini, karena topik yang berfungsi tidak menyertifikasi robot yang berfungsi. Catat versi ROS dan pasangan endpoint yang Anda amati, agar orang berikutnya dapat membedakan perubahan topologi dari regresi.

Daftar periksa selesai ketika URI yang diumumkan dapat dijangkau dari pelanggan, port yang dinegosiasikan terbuka hanya untuk peer itu, satu topik yang dinyatakan mengalir, dan nilai lingkungan tercatat untuk kedua host. ROS 1 lama tidak akan menerima perbaikan di bidang ini, jadi catatan adalah bagian yang tetap berfungsi setelah orang-orang berganti.