---
read_when:
    - Gateway को LAN, tailnet, Tailscale Serve, Funnel या रिवर्स प्रॉक्सी के माध्यम से उपलब्ध कराना
    - वास्तविक मैसेजिंग उपयोगकर्ताओं को अनुमति देने से पहले डिप्लॉयमेंट की समीक्षा करना
    - जोखिमपूर्ण रिमोट एक्सेस या DM कॉन्फ़िगरेशन को वापस पूर्ववत करना
sidebarTitle: Exposure runbook
summary: OpenClaw Gateway को लूपबैक से बाहर उपलब्ध कराने से पहले प्री-फ़्लाइट और रोलबैक चेकलिस्ट
title: Gateway एक्सपोज़र रनबुक
x-i18n:
    generated_at: "2026-07-27T17:58:56Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: fb8e66af57e804325afc91281122b822183337177c734efe065c5fc18b175e72
    source_path: gateway/security/exposure-runbook.md
    workflow: 16
---

<Warning>
Gateway को केवल तभी उजागर करें, जब आप यह स्पष्ट कर सकें कि उस तक कौन पहुँच सकता है, उनका
प्रमाणीकरण कैसे किया जाता है, वे किन एजेंटों को सक्रिय कर सकते हैं, और वे एजेंट किन टूल का
उपयोग कर सकते हैं। संदेह होने पर, केवल लूपबैक पहुँच पर वापस जाएँ और ऑडिट दोबारा चलाएँ।
</Warning>

यह रनबुक व्यापक [सुरक्षा](/hi/gateway/security) मार्गदर्शन को दूरस्थ पहुँच और मैसेजिंग
एक्सपोज़र के लिए ऑपरेटर चेकलिस्ट में बदलती है।

## एक्सपोज़र पैटर्न चुनें

वर्कफ़्लो को पूरा करने वाला सबसे सीमित पैटर्न चुनें।

| पैटर्न                    | कब अनुशंसित है                                | आवश्यक नियंत्रण                                                                                                               |
| -------------------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| लूपबैक + SSH टनल      | व्यक्तिगत उपयोग, एडमिन पहुँच, डीबगिंग           | `gateway.bind: "loopback"` बनाए रखें और `127.0.0.1:18789` को टनल करें                                                                    |
| लूपबैक + Tailscale Serve | Control UI/WebSocket तक व्यक्तिगत टेलनेट पहुँच | Gateway को केवल लूपबैक पर रखें; Tailscale पहचान हेडर केवल Control UI WebSocket सतह को प्रमाणित करते हैं, अन्य प्रमाणीकरण पथों को नहीं |
| टेलनेट/LAN बाइंड           | ज्ञात डिवाइसों वाला समर्पित निजी नेटवर्क    | Gateway प्रमाणीकरण, फ़ायरवॉल अनुमत-सूची, कोई सार्वजनिक पोर्ट-फ़ॉरवर्ड नहीं                                                                        |
| विश्वसनीय रिवर्स प्रॉक्सी      | Gateway के सामने संगठन का SSO/OIDC       | `trusted-proxy` प्रमाणीकरण, सख्त `trustedProxies`, हेडर ओवरराइट/हटाने के नियम, स्पष्ट रूप से अनुमत उपयोगकर्ता                             |
| सार्वजनिक इंटरनेट            | दुर्लभ, उच्च-जोखिम वाले डिप्लॉयमेंट                     | पहचान-सचेत प्रॉक्सी, TLS, दर सीमाएँ, सख्त अनुमत-सूचियाँ, सैंडबॉक्स किए गए गैर-मुख्य सत्र                                          |

Gateway पर सीधे सार्वजनिक पोर्ट-फ़ॉरवर्डिंग से बचें। यदि सार्वजनिक पहुँच
आवश्यक हो, तो उसके सामने पहचान-सचेत प्रॉक्सी रखें और प्रॉक्सी को
Gateway तक पहुँचने वाला एकमात्र नेटवर्क पथ बनाएँ।

## प्रारंभिक इन्वेंट्री

बाइंड, प्रॉक्सी, Tailscale या चैनल नीति बदलने से पहले इन्हें दर्ज करें:

- Gateway होस्ट, OS उपयोगकर्ता और स्थिति डायरेक्टरी (डिफ़ॉल्ट `~/.openclaw`)।
- Gateway URL और बाइंड मोड (`gateway.bind`; डिफ़ॉल्ट पोर्ट `18789`)।
- प्रमाणीकरण मोड, टोकन/पासवर्ड स्रोत या विश्वसनीय प्रॉक्सी पहचान स्रोत।
- प्रत्येक सक्षम चैनल और क्या वह DM, समूह या Webhook स्वीकार करता है।
- गैर-स्थानीय प्रेषकों की पहुँच में आने वाले एजेंट।
- प्रत्येक पहुँच योग्य एजेंट की टूल प्रोफ़ाइल, सैंडबॉक्स मोड और उन्नत टूल नीति।
- उन एजेंटों के लिए उपलब्ध बाहरी क्रेडेंशियल।
- `~/.openclaw/openclaw.json` और क्रेडेंशियल के बैकअप का स्थान।

यदि एक से अधिक व्यक्ति बॉट को संदेश भेज सकते हैं, तो इसे प्रति-उपयोगकर्ता होस्ट
अलगाव नहीं, बल्कि टूल के साझा प्रत्यायोजित अधिकार के रूप में मानें।

## आधारभूत जाँच

पहुँच खोलने से पहले चलाएँ:

```bash
openclaw doctor
openclaw security audit
openclaw security audit --deep
openclaw health
```

पहले गंभीर निष्कर्षों का समाधान करें। चेतावनियाँ केवल तभी स्वीकार करें, जब वे डिप्लॉयमेंट के लिए
जानबूझकर रखी गई और दस्तावेज़ीकृत हों। प्रत्येक `checkId` का अर्थ और उसकी सुधार कुंजी जानने के लिए
[सुरक्षा ऑडिट जाँच](/hi/gateway/security/audit-checks) देखें।

दूरस्थ CLI सत्यापन के लिए, क्रेडेंशियल स्पष्ट रूप से पास करें:

```bash
openclaw gateway probe --url ws://127.0.0.1:18789 --token "$OPENCLAW_GATEWAY_TOKEN"
```

यह न मानें कि स्थानीय कॉन्फ़िगरेशन के क्रेडेंशियल किसी स्पष्ट दूरस्थ URL पर लागू होते हैं।

## न्यूनतम सुरक्षित आधाररेखा

उजागर किए गए डिप्लॉयमेंट के शुरुआती बिंदु के रूप में इस संरचना का उपयोग करें:

```json5
{
  gateway: {
    bind: "loopback",
    auth: {
      mode: "token",
      token: "replace-with-a-long-random-token",
    },
  },
  session: {
    dmScope: "per-channel-peer",
  },
  agents: {
    defaults: {
      sandbox: { mode: "non-main" },
    },
  },
  tools: {
    profile: "messaging",
    exec: { security: "deny", ask: "always" },
    elevated: { enabled: false },
  },
}
```

एक बार में एक नियंत्रण का विस्तार करें: लिखने में सक्षम टूल सक्रिय करने से पहले
किसी विशिष्ट चैनल की अनुमत-सूची जोड़ें, या दूरस्थ Control UI ट्रैफ़िक स्वीकार करने से पहले
रिवर्स प्रॉक्सी सक्रिय करें।

`tools.exec.security: "deny"` सभी exec कॉल को अवरुद्ध करता है, जिनमें अहानिकर
निदान भी शामिल हैं। यदि निदान या कम-जोखिम वाले कमांड आवश्यक हों, तो इसे केवल
उन विशिष्ट प्रेषकों, एजेंटों, कमांड और अनुमोदन मोड को चुनने के बाद शिथिल करें,
जो आपके खतरा मॉडल के अनुरूप हों।

## DM और समूह एक्सपोज़र

मैसेजिंग चैनल अविश्वसनीय इनपुट सतहें हैं। DM या समूहों को अनुमति देने से पहले:

- `dmPolicy: "open"` की बजाय `dmPolicy: "pairing"` या सख्त `allowFrom` सूची को प्राथमिकता दें।
- `"*"` अनुमत-सूचियों को व्यापक टूल पहुँच के साथ संयोजित न करें।
- जब तक कक्ष कड़े नियंत्रण में न हो, समूहों में उल्लेख आवश्यक करें।
- जब कई लोग बॉट को DM भेज सकते हों, तो `session.dmScope: "per-channel-peer"` (या
  बहु-अकाउंट चैनलों के लिए `"per-account-channel-peer"`) सेट करें, ताकि DM सत्र
  संदर्भ साझा न करें।
- साझा चैनलों को न्यूनतम टूल और बिना व्यक्तिगत
  क्रेडेंशियल वाले एजेंटों तक रूट करें।

पेयरिंग प्रेषक को बॉट सक्रिय करने की अनुमति देती है। यह उस प्रेषक को
अलग होस्ट सुरक्षा सीमा नहीं बनाती।

## रिवर्स प्रॉक्सी जाँच

पहचान-सचेत प्रॉक्सी के लिए:

- प्रॉक्सी को Gateway पर फ़ॉरवर्ड करने से पहले उपयोगकर्ताओं को प्रमाणित करना आवश्यक है।
- फ़ायरवॉल या नेटवर्क नीति को Gateway पोर्ट तक सीधी पहुँच अवरुद्ध करनी चाहिए।
- `gateway.trustedProxies` में केवल प्रॉक्सी स्रोत IP सूचीबद्ध होने चाहिए।
- प्रॉक्सी को क्लाइंट द्वारा दिए गए पहचान और फ़ॉरवर्डिंग
  हेडर हटाने या ओवरराइट करने चाहिए।
- जब प्रॉक्सी एक से अधिक
  ऑडियंस को सेवा देती हो, तब `gateway.auth.trustedProxy.allowUsers` सेट करें।
- `gateway.auth.trustedProxy.allowLoopback` का उपयोग केवल उसी-होस्ट प्रॉक्सी के लिए करें,
  जहाँ स्थानीय प्रक्रियाएँ विश्वसनीय हों और पहचान हेडर प्रॉक्सी के नियंत्रण में हों।

प्रॉक्सी परिवर्तनों के बाद `openclaw security audit --deep` चलाएँ। विश्वसनीय-प्रॉक्सी
निष्कर्ष अत्यधिक महत्वपूर्ण संकेत हैं, क्योंकि प्रॉक्सी प्रमाणीकरण
सीमा बन जाती है।

## टूल और सैंडबॉक्स समीक्षा

किसी एजेंट को दूरस्थ प्रेषकों के लिए उजागर करने से पहले:

- पुष्टि करें कि कौन-से सत्र होस्ट पर और कौन-से सैंडबॉक्स में चलते हैं।
- होस्ट exec को अस्वीकार करें या उसके लिए अनुमोदन आवश्यक करें।
- जब तक किसी विशिष्ट, विश्वसनीय प्रेषक को उनकी आवश्यकता न हो, उन्नत टूल अक्षम रखें।
- खुली या अर्ध-खुली मैसेजिंग सतहों के लिए ब्राउज़र, कैनवास, Node, Cron, Gateway और सत्र-स्पॉन टूल से बचें।
- बाइंड माउंट सीमित रखें; क्रेडेंशियल, होम, Docker सॉकेट और सिस्टम
  पथों से बचें।
- काफी भिन्न विश्वास सीमाओं के लिए अलग Gateway, OS उपयोगकर्ता या होस्ट
  उपयोग करें।

यदि दूरस्थ उपयोगकर्ता पूरी तरह विश्वसनीय नहीं हैं, तो अलगाव अलग
डिप्लॉयमेंट से आना चाहिए, केवल प्रॉम्प्ट या सत्र लेबल से नहीं।

## परिवर्तन के बाद सत्यापन

प्रत्येक एक्सपोज़र परिवर्तन के बाद:

1. `openclaw security audit --deep` दोबारा चलाएँ।
2. पुष्टि करें कि अधिकृत कनेक्शन सफलतापूर्वक जुड़ता है।
3. पुष्टि करें कि अनधिकृत प्रेषक या ब्राउज़र सत्र को अस्वीकार किया जाता है।
4. पुष्टि करें कि लॉग सीक्रेट छिपाते हैं।
5. पुष्टि करें कि DM/समूह रूटिंग केवल इच्छित एजेंट तक पहुँचती है।
6. पुष्टि करें कि उच्च-प्रभाव वाले टूल अनुमोदन माँगते हैं या अस्वीकार किए जाते हैं।
7. स्वीकार की गई शेष चेतावनियों का दस्तावेज़ीकरण करें।

जब तक वर्तमान एक्सपोज़र परिवर्तन समझ में न आ जाए, अगले परिवर्तन पर
आगे न बढ़ें।

## रोलबैक योजना

यदि Gateway अत्यधिक उजागर हो सकता है:

```json5
{
  gateway: {
    bind: "loopback",
  },
  channels: {
    whatsapp: { dmPolicy: "disabled" },
    telegram: { dmPolicy: "disabled" },
    discord: { dmPolicy: "disabled" },
    slack: { dmPolicy: "disabled" },
  },
  tools: {
    exec: { security: "deny", ask: "always" },
    elevated: { enabled: false },
  },
}
```

फिर:

1. सार्वजनिक फ़ॉरवर्डिंग, Tailscale Funnel या रिवर्स प्रॉक्सी रूट रोकें।
2. Gateway टोकन/पासवर्ड और प्रभावित एकीकरण क्रेडेंशियल रोटेट करें।
3. अनुमत-सूचियों से `"*"` और अनपेक्षित प्रेषकों को हटाएँ।
4. हाल के ऑडिट लॉग, रन इतिहास, टूल कॉल और कॉन्फ़िगरेशन परिवर्तनों की समीक्षा करें।
5. `openclaw security audit --deep` दोबारा चलाएँ।
6. वर्कफ़्लो को पूरा करने वाले सबसे सीमित पैटर्न के साथ पहुँच दोबारा सक्रिय करें।

## समीक्षा चेकलिस्ट

- जब तक कोई दस्तावेज़ीकृत कारण न हो, Gateway केवल लूपबैक पर रहता है।
- गैर-लूपबैक पहुँच में प्रमाणीकरण और फ़ायरवॉल सुरक्षा है तथा कोई सीधा सार्वजनिक रूट नहीं है।
- विश्वसनीय-प्रॉक्सी डिप्लॉयमेंट में सख्त प्रॉक्सी IP और हेडर नियंत्रण हैं।
- DM डिफ़ॉल्ट रूप से खुली पहुँच के बजाय पेयरिंग या अनुमत-सूचियों का उपयोग करते हैं।
- समूहों में उल्लेख या स्पष्ट अनुमत-सूचियाँ आवश्यक हैं।
- साझा चैनलों की पहुँच व्यक्तिगत क्रेडेंशियल तक नहीं है।
- गैर-मुख्य सत्र सैंडबॉक्स मोड में चलते हैं।
- होस्ट exec और उन्नत टूल अस्वीकृत हैं या अनुमोदन द्वारा नियंत्रित हैं।
- लॉग सीक्रेट छिपाते हैं।
- गंभीर ऑडिट निष्कर्षों का समाधान किया गया है।
- रोलबैक चरणों का परीक्षण और दस्तावेज़ीकरण किया गया है।