ROS 1-ämnen över ett VPN: följ den annonserade slutpunkten

Din arbetsstation når ROS 1-mastern via tunneln och visar ändå en tom ämneslista. Det mönstret är vanligt eftersom masterregistrering och ämnestransport är två olika samtal, och bara det första går genom mastern. Checklistan nedan går igenom det andra samtalet: slutpunkten som en utgivare annonserar, adressen som en prenumerant måste kunna nå och behörigheten som låter paret prata. Allt här gäller bara den gamla ROS 1, vars Noetic-supportfönster avslutades i maj 2025.

Steg 1: bevisa att masteranslutningen inte är ämnesanslutningen

Börja med att skilja det som fungerar från det som inte fungerar. En lyckad rostopic list bevisar att ditt skal når masterns XMLRPC-port och att mastern känner till ämnen; den säger ingenting om huruvida en prenumerant kan nå utgivaren. De tre kommandona nedan gör skillnaden synlig, och alla är skrivskyddade.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

Utdata från rostopic info namnger utgivarens nod-URI, vilket är en XMLRPC-adress på utgivarens värd. Det är adressen som din prenumerant kommer att anropa härnäst, så den måste vara nåbar från var prenumeranten än körs. Om den pekar på ett gränssnitt som bara finns på robotens eget LAN lyckas mastersökningen och data kommer aldrig fram.

Steg 2: läs den annonserade slutpunkten från noden själv

ROS 1 väljer sin annonserade värdidentitet från ROS_IP eller ROS_HOSTNAME när någon av dem är satt, och faller annars tillbaka på värdens egen namnmatchning. Undersök miljön för den process som faktiskt startades, eftersom en systemd-enhet, en container eller en andra terminal kan bära ett annat värde än skalet där ditt test fungerade.

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

En värdnamnsannons fungerar bara om varje peer slår upp namnet till den avsedda nåbara adressen. Om namnet bara slås upp inne i robotens eget nätverk har en arbetsstation på andra sidan tunneln ingen möjlighet att använda det, och en VPN som inte skickar någon DNS-suffix gör avvikelsen värre. Att sätta ROS_IP till tunneladressen är den mindre ändringen när topologin är routad. Vad du än väljer, skriv ned det för båda ändarna, eftersom en utgivare och en prenumerant som är oense om identiteten kommer att förhandla och sedan inte kunna ansluta.

Stanna här om den annonserade URI:n använder en adress som ingen peer kan routa till. Inget brandväggsarbete reparerar ett namn som slås upp till fel gränssnitt.

Steg 3: gör den annonserade adressen uppslagningsbar och routad

Med URI:n i handen testar du nåbarheten från prenumerantens värd i stället för från roboten. TCPROS-porten väljs under förhandlingen, så det användbara tidiga testet är XMLRPC-porten och det användbara sena testet är den etablerade socketen. En rutt som bara finns i en riktning är ett vanligt fel på routade VPN:er, och returvägen betyder lika mycket som vägen fram.

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

Ett routat TUN-gränssnitt transporterar dessa IP-samtal utan att utöka robotens Ethernet-segment, vilket en fjärroperatör oftast vill. Om något i stacken i stället beror på broadcast eller multicast måste det kravet bedömas separat; att göra om tunneln till TAP för att tillfredsställa ett enda verktyg vidgar nätet för varje deltagare.

Stanna här om rutten eller returvägen saknas. En utgivare som svarar på sin egen värd men inte kan nås från arbetsstationen har ett routingproblem, inte ett ROS-problem.

Steg 4: tillåt peer-samtalet och observera ett ämne

Öppna bara de portar som det förhandlade samtalet behöver, och begränsa varje regel till de deklarerade deltagarna. Masternalyssnaren är inte en vidarebefordrare för ämnesnyttolast, så att bara tillåta den lämnar utgivarens slutpunkt stängd. Håll ROS-lyssnarna vid gränsen för det privata VPN:et i stället för att exponera dem mot det publika internet.

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

Observera ett ofarligt ämne från den verkliga utgivaren till den verkliga prenumeranten och bekräfta både den annonserade slutpunkten och svarsvägen. Ett enda meddelande bevisar att vägen fungerar; en jämn frekvens bevisar att den hålls öppen. Håll aktuatorstyrning och säkerhetskontroller utanför detta test som bara handlar om nätverket, eftersom ett fungerande ämne inte certifierar en fungerande robot. Skriv ned ROS-versionen och det observerade slutpunktsparet, så att nästa person kan skilja en topologiändring från en regression.

Checklistan är klar när den annonserade URI:n är nåbar från prenumeranten, den förhandlade porten är öppen bara för den peeren, ett deklarerat ämne flödar och miljövärdet är nedskrivet för båda värdarna. Gammal ROS 1 kommer inte att få rättningar på detta område, så registreringen är den del som fortsätter att fungera efter att människorna byts ut.