VPN을 통한 ROS 1 토픽: 광고된 엔드포인트를 따르세요
ROS 1 master 등록은 토픽 데이터를 전달하지 않습니다. 광고된 노드 URI를 읽고, 그 주소를 라우팅 가능하게 만든 다음, 퍼블리셔의 포트를 허용하십시오.
워크스테이션이 터널을 통해 ROS 1 master에 도달하지만 토픽 목록은 여전히 비어 있습니다. 이 패턴이 흔한 이유는 master 등록과 토픽 전송이 서로 다른 두 대화이고, master를 거치는 것은 첫 번째뿐이기 때문입니다. 아래 체크리스트는 두 번째 대화를 따라갑니다: 퍼블리셔가 광고하는 엔드포인트, 서브스크라이버가 도달할 수 있어야 하는 주소, 그리고 둘이 대화할 수 있게 하는 권한입니다. 여기의 모든 내용은 Noetic 지원 기간이 2025년 오월에 끝난 구형 ROS 1에만 해당합니다.
1단계: master 연결이 토픽 연결이 아님을 증명하십시오
무엇이 작동하고 무엇이 작동하지 않는지 분리하는 것부터 시작하십시오. 성공한 rostopic list는 셸이 master의 XMLRPC 포트에 도달할 수 있고 master가 토픽을 알고 있음을 증명할 뿐, 서브스크라이버가 퍼블리셔에 도달할 수 있는지는 말해주지 않습니다. 아래 세 명령은 그 차이를 드러내며, 모두 읽기 전용입니다.
echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter
rostopic info의 출력은 퍼블리셔의 노드 URI를 알려주며, 이는 퍼블리셔의 호스트에 있는 XMLRPC 주소입니다. 바로 그 주소를 서브스크라이버가 다음에 호출하므로, 서브스크라이버가 어디서 실행되든 그곳에서 도달할 수 있어야 합니다. 그 주소가 로봇 자체의 LAN에만 존재하는 인터페이스를 가리킨다면 master 조회는 성공하지만 데이터는 결코 도착하지 않습니다.
2단계: 광고된 엔드포인트를 노드 자체에서 읽으십시오
ROS 1은 ROS_IP 또는 ROS_HOSTNAME 중 하나가 설정되어 있으면 그곳에서 광고할 호스트 신원을 선택하고, 그렇지 않으면 호스트 자체의 이름 해석으로 돌아갑니다. 실제로 실행된 프로세스의 환경을 확인해야 합니다, systemd 유닛, 컨테이너 또는 두 번째 터미널은 테스트가 통했던 셸과 다른 값을 지닐 수 있기 때문입니다.
echo "$ROS_IP" "$ROS_HOSTNAME"
rosnode info /talker
getent hosts robot-host
호스트 이름 광고는 모든 피어가 그 이름을 의도한 도달 가능 주소로 해석할 때만 작동합니다. 그 이름이 로봇 자체 네트워크 안에서만 해석된다면, 터널 반대편의 워크스테이션은 그것을 사용할 방법이 없고, DNS 접미사를 밀어 넣지 않는 VPN은 그 불일치를 더 악화시킵니다. 토폴로지가 라우팅된다면 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 대화를 실어 나르며, 이는 보통 원격 운영자가 원하는 바입니다. 스택의 무언가가 대신 브로드캐스트나 multicast에 의존한다면 그 요구 사항은 따로 평가해야 합니다, 한 도구를 만족시키려고 터널을 TAP으로 바꾸면 모든 참가자에게 네트워크가 넓어지기 때문입니다.
경로나 돌아오는 경로가 없으면 여기서 멈추십시오. 자기 호스트에서는 응답하지만 워크스테이션에서 도달할 수 없는 퍼블리셔는 라우팅 문제를 가진 것이지 ROS 문제가 아닙니다.
4단계: 피어 대화를 허용하고 토픽 하나를 관찰하십시오
협상된 대화에 필요한 포트만 열고, 각 규칙을 선언된 참가자로 한정하십시오. master의 리스너는 토픽 페이로드의 중계자가 아니므로 그것만 허용하면 퍼블리셔의 엔드포인트는 닫힌 채로 남습니다. ROS 리스너를 공용 인터넷에 노출하는 대신 사설 VPN 경계에 두십시오.
rostopic hz /chatter
rostopic echo -n1 /chatter
rosnode ping /talker
실제 퍼블리셔에서 실제 서브스크라이버로 무해한 토픽 하나를 관찰하고 광고된 엔드포인트와 응답 경로를 모두 확인하십시오. 메시지 하나가 경로가 작동함을 증명하고, 안정적인 속도가 그것이 열린 채로 유지됨을 증명합니다. 액추에이터 제어와 안전 점검은 이 네트워크 전용 시험 밖에 두십시오, 토픽이 작동한다고 해서 로봇이 작동하는 것이 인증되지는 않기 때문입니다. 관찰한 ROS 버전과 엔드포인트 쌍을 기록해, 다음 사람이 토폴로지 변경과 회귀를 구분할 수 있게 하십시오.
광고된 URI에 서브스크라이버에서 도달할 수 있고, 협상된 포트가 그 피어에만 열려 있으며, 선언된 토픽 하나가 흐르고, 두 호스트의 환경 값이 기록되면 체크리스트가 끝납니다. 구형 ROS 1은 이 영역에서 수정을 받지 않으므로, 기록이야말로 사람이 바뀐 뒤에도 계속 작동하는 부분입니다.