Gateway

खोज और ट्रांसपोर्ट

OpenClaw में खोज से जुड़ी दो परस्पर संबंधित लेकिन अलग समस्याएँ हैं:

  1. ऑपरेटर रिमोट कंट्रोल: macOS मेनू बार ऐप द्वारा किसी अन्य स्थान पर चल रहे Gateway को नियंत्रित करना।
  2. Node पेयरिंग: iOS/Android (और भविष्य के Node) द्वारा Gateway खोजना और सुरक्षित रूप से पेयर करना।

सभी नेटवर्क खोज/विज्ञापन Node Gateway में होते हैं (openclaw gateway); क्लाइंट (Mac ऐप, iOS) केवल उपभोक्ता हैं।

शब्दावली

  • Gateway: एक दीर्घकालिक प्रक्रिया जो स्थिति (सत्र, पेयरिंग, Node रजिस्ट्री) की स्वामी होती है और चैनल चलाती है। अधिकतर सेटअप प्रति होस्ट एक का उपयोग करते हैं; अलग-अलग कई Gateway वाले सेटअप संभव हैं।
  • Gateway WS (कंट्रोल प्लेन): डिफ़ॉल्ट रूप से 127.0.0.1:18789 पर WebSocket एंडपॉइंट; इसे gateway.bind के माध्यम से LAN/tailnet से बाइंड करें।
  • डायरेक्ट WS ट्रांसपोर्ट: LAN/tailnet की ओर उपलब्ध Gateway WS एंडपॉइंट (SSH के बिना)।
  • SSH ट्रांसपोर्ट (फ़ॉलबैक): SSH के माध्यम से 127.0.0.1:18789 फ़ॉरवर्ड करके रिमोट कंट्रोल।
  • पुराना TCP ब्रिज (हटाया गया): पुराना Node ट्रांसपोर्ट (देखें ब्रिज प्रोटोकॉल); अब खोज के लिए विज्ञापित नहीं किया जाता और मौजूदा बिल्ड का हिस्सा नहीं है।

प्रोटोकॉल विवरण: Gateway प्रोटोकॉल, ब्रिज प्रोटोकॉल (पुराना)

डायरेक्ट और SSH दोनों क्यों मौजूद हैं

  • डायरेक्ट WS समान नेटवर्क और tailnet के भीतर सर्वश्रेष्ठ उपयोगकर्ता अनुभव देता है: Bonjour के माध्यम से LAN पर स्वतः खोज, Gateway के स्वामित्व वाले पेयरिंग टोकन और ACL, और शेल एक्सेस की आवश्यकता नहीं।
  • SSH सार्वभौमिक फ़ॉलबैक है: जहाँ भी आपके पास SSH एक्सेस हो, वहाँ काम करता है, यहाँ तक कि असंबंधित नेटवर्कों के बीच भी; multicast/mDNS समस्याओं के बावजूद काम करता है और SSH के अलावा किसी नए इनबाउंड पोर्ट की आवश्यकता नहीं होती।

खोज इनपुट

1) Bonjour / DNS-SD

Multicast Bonjour सर्वोत्तम प्रयास के आधार पर काम करता है और नेटवर्कों के पार नहीं जाता। OpenClaw कॉन्फ़िगर किए गए वाइड-एरिया DNS-SD डोमेन के माध्यम से उसी Gateway बीकन को ब्राउज़ करने का समर्थन भी करता है, ताकि खोज समान LAN पर local. और विभिन्न नेटवर्कों में खोज के लिए कॉन्फ़िगर किए गए unicast DNS-SD डोमेन—दोनों को कवर कर सके।

बंडल किया गया bonjour Plugin सक्षम होने पर Gateway Bonjour के माध्यम से अपने WS एंडपॉइंट का विज्ञापन करता है; क्लाइंट ब्राउज़ करके "Gateway चुनें" सूची दिखाते हैं, फिर चुने गए एंडपॉइंट को संग्रहीत करते हैं।

समस्या निवारण और बीकन विवरण: Bonjour

सेवा बीकन का विवरण

  • सेवा प्रकार: _openclaw-gw._tcp (Gateway ट्रांसपोर्ट बीकन)।

  • TXT कुंजियाँ (गोपनीय नहीं):

    कुंजी टिप्पणियाँ
    role=gateway हमेशा मौजूद रहती है।
    transport=gateway हमेशा मौजूद रहती है।
    displayName=<name> ऑपरेटर द्वारा कॉन्फ़िगर किया गया प्रदर्शन नाम।
    lanHost=<hostname>.local केवल LAN mDNS विज्ञापनकर्ता; वाइड-एरिया DNS-SD द्वारा नहीं लिखा जाता।
    gatewayPort=18789 Gateway WS + HTTP पोर्ट।
    gatewayTls=1 केवल TLS सक्षम होने पर।
    gatewayTlsSha256=<sha256> केवल TLS सक्षम होने और फ़िंगरप्रिंट उपलब्ध होने पर।
    tailnetDns=<magicdns> वैकल्पिक संकेत; Tailscale उपलब्ध होने पर स्वतः पहचाना जाता है।
    sshPort=<port> केवल discovery.mdns.mode="full" होने पर मौजूद; डिफ़ॉल्ट "minimal" मोड में छोड़ दिया जाता है (SSH डिफ़ॉल्ट रूप से 22 का उपयोग करता है), LAN विज्ञापनकर्ता और वाइड-एरिया DNS-SD दोनों पर।
    cliPath=<path> sshPort के समान discovery.mdns.mode="full" गेट; CLI पथ के लिए रिमोट इंस्टॉलेशन संकेत।

    भविष्य के कैनवास होस्ट पोर्ट के लिए Plugin खोज अनुबंध में canvasPort TXT कुंजी परिभाषित है, लेकिन कोई मौजूदा कोड पथ इसका मान सेट नहीं करता, इसलिए आज यह कभी उत्सर्जित नहीं होती।

सुरक्षा संबंधी टिप्पणियाँ:

  • Bonjour/mDNS TXT रिकॉर्ड अप्रमाणित होते हैं। क्लाइंट को TXT मानों को केवल उपयोगकर्ता अनुभव संबंधी संकेत मानना चाहिए।
  • रूटिंग (होस्ट/पोर्ट) में TXT द्वारा दिए गए lanHost, tailnetDns, या gatewayPort के बजाय रिज़ॉल्व किए गए सेवा एंडपॉइंट (SRV + A/AAAA) को प्राथमिकता देनी चाहिए।
  • TLS पिनिंग में विज्ञापित gatewayTlsSha256 को पहले से संग्रहीत पिन को ओवरराइड करने की अनुमति कभी नहीं देनी चाहिए।
  • जब भी चुना गया रूट सुरक्षित/TLS-आधारित हो, iOS/Android Node को पहली बार पिन संग्रहीत करने से पहले स्पष्ट "इस फ़िंगरप्रिंट पर भरोसा करें" पुष्टि (आउट-ऑफ़-बैंड सत्यापन) की आवश्यकता होनी चाहिए।

सक्षम, अक्षम और ओवरराइड करना:

  • openclaw plugins enable bonjour LAN multicast विज्ञापन सक्षम करता है।
  • openclaw.json में discovery.mdns.mode mDNS प्रसारण नियंत्रित करता है: "minimal" (डिफ़ॉल्ट), "full" (LAN बीकन और किसी भी वाइड-एरिया DNS-SD ज़ोन—दोनों में cliPath/sshPort जोड़ता है), या "off" (mDNS अक्षम करता है)।
  • OPENCLAW_DISABLE_BONJOUR=1 विज्ञापन को बलपूर्वक अक्षम करता है; discovery.mdns.mode="off" इसे स्वतंत्र रूप से अक्षम करता है। OPENCLAW_DISABLE_BONJOUR=0 एक स्पष्ट ऑप्ट-इन है, जो पहचाने गए कंटेनर (Docker, containerd, Kubernetes, LXC) के भीतर Plugin के स्वतः अक्षम होने को ओवरराइड करता है; यह discovery.mdns.mode="off" को ओवरराइड नहीं करता। बंडल किया गया bonjour Plugin macOS होस्ट (enabledByDefaultOnPlatforms: ["darwin"]) पर स्वतः शुरू होता है और पहचाने गए कंटेनरों के भीतर स्वतः अक्षम हो जाता है; Linux, Windows और अन्य कंटेनरीकृत डिप्लॉयमेंट के लिए स्पष्ट plugins enable bonjour आवश्यक है।
  • ~/.openclaw/openclaw.json में gateway.bind Gateway बाइंड मोड नियंत्रित करता है।
  • OPENCLAW_SSH_PORT विज्ञापित SSH पोर्ट को ओवरराइड करता है (केवल discovery.mdns.mode="full" होने पर प्रभावी)।
  • OPENCLAW_TAILNET_DNS एक tailnetDns संकेत (MagicDNS) प्रकाशित करता है।
  • OPENCLAW_CLI_PATH विज्ञापित CLI पथ को ओवरराइड करता है।

2) Tailnet (नेटवर्कों के पार)

अलग-अलग भौतिक नेटवर्कों पर स्थित Gateway के लिए Bonjour उपयोगी नहीं होगा। अनुशंसित डायरेक्ट लक्ष्य Tailscale MagicDNS नाम (प्राथमिक) या स्थिर tailnet IP है।

यदि Gateway को पता चलता है कि वह Tailscale के अंतर्गत चल रहा है, तो वह क्लाइंट के लिए वैकल्पिक संकेत के रूप में tailnetDns प्रकाशित करता है (वाइड-एरिया बीकन सहित)। Gateway खोज के लिए macOS ऐप कच्चे Tailscale IP के बजाय MagicDNS नामों को प्राथमिकता देता है, जो tailnet IP बदलने पर भी विश्वसनीय रहता है (Node पुनः आरंभ, CGNAT पुनः असाइनमेंट), क्योंकि MagicDNS स्वतः मौजूदा IP पर रिज़ॉल्व होता है।

मोबाइल Node पेयरिंग के लिए, खोज संकेत tailnet/सार्वजनिक रूट पर ट्रांसपोर्ट सुरक्षा को कभी शिथिल नहीं करते:

  • iOS/Android को अब भी पहली बार tailnet/सार्वजनिक कनेक्शन के लिए सुरक्षित पथ (wss:// या Tailscale Serve/Funnel) की आवश्यकता होती है।
  • खोजा गया कच्चा tailnet IP एक रूटिंग संकेत है, प्लेनटेक्स्ट रिमोट ws:// के उपयोग की अनुमति नहीं।
  • निजी LAN डायरेक्ट-कनेक्ट ws:// समर्थित रहता है।
  • मोबाइल Node पर सबसे सरल Tailscale पथ के लिए Tailscale Serve का उपयोग करें, ताकि खोज और सेटअप दोनों समान सुरक्षित MagicDNS एंडपॉइंट पर रिज़ॉल्व हों।

3) मैन्युअल / SSH लक्ष्य

जब कोई डायरेक्ट रूट उपलब्ध न हो (या डायरेक्ट अक्षम हो), तो क्लाइंट लूपबैक Gateway पोर्ट को फ़ॉरवर्ड करके हमेशा SSH के माध्यम से कनेक्ट कर सकते हैं। देखें रिमोट एक्सेस

ट्रांसपोर्ट चयन (क्लाइंट नीति)

  1. यदि पेयर किया गया डायरेक्ट एंडपॉइंट कॉन्फ़िगर और पहुँच योग्य है, तो उसका उपयोग करें।
  2. अन्यथा, यदि खोज को local. या कॉन्फ़िगर किए गए वाइड-एरिया डोमेन पर कोई Gateway मिलता है, तो एक टैप में "इस Gateway का उपयोग करें" विकल्प दें और इसे डायरेक्ट एंडपॉइंट के रूप में सहेजें।
  3. अन्यथा, यदि tailnet DNS/IP कॉन्फ़िगर है, तो डायरेक्ट का प्रयास करें। tailnet/सार्वजनिक रूट पर मोबाइल Node के लिए डायरेक्ट का अर्थ सुरक्षित एंडपॉइंट है, प्लेनटेक्स्ट रिमोट ws:// नहीं।
  4. अन्यथा, SSH पर फ़ॉलबैक करें।

पेयरिंग और प्रमाणीकरण (डायरेक्ट ट्रांसपोर्ट)

Node/क्लाइंट प्रवेश के लिए Gateway ही सत्य का स्रोत है:

  • पेयरिंग अनुरोध Gateway में बनाए/स्वीकृत/अस्वीकृत किए जाते हैं (देखें Gateway पेयरिंग)।
  • Gateway प्रमाणीकरण (टोकन/कीपेयर), स्कोप/ACL (यह हर विधि के लिए कच्चा प्रॉक्सी नहीं है) और दर सीमाएँ लागू करता है।

घटक के अनुसार उत्तरदायित्व

  • Gateway: खोज बीकन का विज्ञापन करता है, पेयरिंग निर्णयों का स्वामी होता है और WS एंडपॉइंट होस्ट करता है।
  • macOS ऐप: Gateway चुनने में आपकी सहायता करता है, पेयरिंग संकेत दिखाता है और SSH का उपयोग केवल फ़ॉलबैक के रूप में करता है।
  • iOS/Android Node: सुविधा के लिए Bonjour ब्राउज़ करते हैं और पेयर किए गए Gateway WS से कनेक्ट होते हैं।

संबंधित

Was this useful?
On this page

On this page