> ## Documentation Index
> Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Gateway एक्सपोज़र रनबुक

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

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

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

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

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

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

## प्री-फ़्लाइट इन्वेंटरी

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

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

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

## बेसलाइन जांच

एक्सेस खोलने से पहले ये चलाएं:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw doctor
openclaw security audit
openclaw security audit --deep
openclaw health
```

पहले गंभीर निष्कर्षों को हल करें। चेतावनियां केवल तब स्वीकार्य हो सकती हैं जब वे
जानबूझकर हों और डिप्लॉयमेंट के लिए दस्तावेजीकृत हों।

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

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw gateway probe --url ws://127.0.0.1:18789 --token "$OPENCLAW_GATEWAY_TOKEN"
```

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

## न्यूनतम सुरक्षित बेसलाइन

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

```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}}
{
  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 ट्रैफ़िक
स्वीकार करने से पहले रिवर्स प्रॉक्सी सक्षम करें।

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

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

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

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

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

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

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

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

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

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

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

* पुष्टि करें कि कौन से सेशन होस्ट पर चलते हैं और कौन से सैंडबॉक्स में।
* होस्ट exec को अस्वीकार करें या उसके लिए अनुमोदन आवश्यक करें।
* जब तक किसी विशिष्ट, विश्वसनीय प्रेषक को उनकी जरूरत न हो, एलिवेटेड टूल अक्षम रखें।
* खुले या अर्ध-खुले मैसेजिंग सतहों के लिए ब्राउज़र, कैनवास, node, cron, gateway, और session-spawn टूल से बचें।
* बाइंड माउंट संकीर्ण रखें और क्रेडेंशियल, होम, Docker सॉकेट, और सिस्टम पथों से बचें।
* भौतिक रूप से अलग भरोसे की सीमाओं के लिए अलग gateways, OS उपयोगकर्ता, या होस्ट का उपयोग करें।

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

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

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

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

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

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

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

```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}}
{
  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 और एलिवेटेड टूल अस्वीकार किए जाते हैं या अनुमोदन-गेटेड हैं।
* लॉग सीक्रेट्स को रिडैक्ट करते हैं।
* गंभीर ऑडिट निष्कर्ष हल किए गए हैं।
* रोलबैक चरणों का परीक्षण और दस्तावेजीकरण किया गया है।