---
read_when:
    - در دسترس قرار دادن Gateway از طریق LAN، tailnet، Tailscale Serve، Funnel یا یک پروکسی معکوس
    - بازبینی استقرار پیش از مجاز کردن کاربران پیام‌رسانی واقعی
    - بازگردانی یک پیکربندی پرخطر دسترسی راه دور یا DM
sidebarTitle: Exposure runbook
summary: چک‌لیست پیش از اجرا و بازگشت قبل از در دسترس قرار دادن OpenClaw Gateway فراتر از loopback
title: راهنمای عملیاتی در معرض‌گذاری Gateway
x-i18n:
    generated_at: "2026-06-27T17:50:15Z"
    model: gpt-5.5
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: c5e94cc03b9d79a03eb16aa04bad0fd311b72f27f14182c036832382dbce3d0f
    source_path: gateway/security/exposure-runbook.md
    workflow: 16
---

<Warning>
Gateway را فقط زمانی در معرض دسترسی قرار دهید که بتوانید توضیح دهید چه کسانی
می‌توانند به آن برسند، چگونه احراز هویت می‌شوند، کدام عامل‌ها را می‌توانند
فعال کنند، و آن عامل‌ها از کدام ابزارها می‌توانند استفاده کنند. در صورت تردید،
به دسترسی فقط از طریق loopback برگردید و ممیزی را دوباره اجرا کنید.
</Warning>

این راهنمای عملیاتی، راهنمای گسترده‌تر [امنیت](/fa/gateway/security) را به یک
چک‌لیست عملیاتی برای دسترسی راه دور و در معرض قرار گرفتن پیام‌رسانی تبدیل می‌کند.

## الگوی در معرض قرار دادن را انتخاب کنید

باریک‌ترین الگویی را ترجیح دهید که نیاز گردش کار را برآورده می‌کند.

| الگو                       | زمانی توصیه می‌شود که                              | کنترل‌های الزامی                                                                                         |
| -------------------------- | --------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| Loopback + تونل SSH        | استفاده شخصی، دسترسی ادمین، اشکال‌زدایی            | `gateway.bind: "loopback"` را نگه دارید و `127.0.0.1:18789` را تونل کنید                                  |
| Loopback + Tailscale Serve | دسترسی شخصی tailnet به Control UI/WebSocket         | Gateway را فقط روی loopback نگه دارید؛ فقط برای سطوح پشتیبانی‌شده به سرآیندهای هویت Tailscale تکیه کنید |
| اتصال Tailnet/LAN          | شبکه خصوصی اختصاصی با دستگاه‌های شناخته‌شده        | احراز هویت Gateway، allowlist دیوار آتش، بدون بازفرستادن پورت عمومی                                      |
| پراکسی معکوس مورد اعتماد   | SSO/OIDC سازمانی در جلوی Gateway                    | احراز هویت `trusted-proxy`، `trustedProxies` سخت‌گیرانه، قواعد بازنویسی/حذف سرآیند، کاربران مجاز صریح    |
| اینترنت عمومی              | استقرارهای نادر و پرریسک                            | پراکسی آگاه از هویت، TLS، محدودیت نرخ، allowlistهای سخت‌گیرانه، نشست‌های غیر main ایزوله‌شده             |

از بازفرستادن مستقیم پورت عمومی به Gateway پرهیز کنید. اگر به دسترسی عمومی
نیاز دارید، یک پراکسی آگاه از هویت جلوی آن قرار دهید و پراکسی را تنها مسیر شبکه
به Gateway کنید.

## موجودی پیش از اجرا

پیش از تغییر bind، پراکسی، Tailscale، یا سیاست کانال، این موارد را ثبت کنید:

- میزبان Gateway، کاربر سیستم‌عامل، و دایرکتوری وضعیت.
- URL و حالت bind مربوط به Gateway.
- حالت احراز هویت، منبع توکن/گذرواژه، یا منبع هویت پراکسی مورد اعتماد.
- همه کانال‌های فعال و اینکه آیا DMها، گروه‌ها، یا webhookها را می‌پذیرند.
- عامل‌هایی که از فرستندگان غیرمحلی قابل دسترسی‌اند.
- پروفایل ابزار، حالت sandbox، و سیاست ابزارهای ارتقایافته برای هر عامل قابل دسترسی.
- اعتبارنامه‌های خارجی در دسترس آن عامل‌ها.
- محل پشتیبان برای `~/.openclaw/openclaw.json` و اعتبارنامه‌ها.

اگر بیش از یک نفر می‌تواند به ربات پیام بدهد، این را اختیار ابزار واگذارشده
مشترک در نظر بگیرید، نه ایزوله‌سازی میزبان برای هر کاربر.

## بررسی‌های مبنا

پیش از باز کردن دسترسی، این‌ها را اجرا کنید:

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

ابتدا یافته‌های بحرانی را رفع کنید. هشدارها فقط زمانی ممکن است قابل قبول باشند
که برای استقرار عمدی و مستند شده باشند.

برای اعتبارسنجی 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 },
  },
}
```

سپس هر بار فقط یک کنترل را گسترده‌تر کنید. برای مثال، پیش از فعال کردن ابزارهای
دارای توان نوشتن، یک allowlist مشخص برای کانال اضافه کنید، یا پیش از پذیرش
ترافیک راه دور Control UI یک پراکسی معکوس را فعال کنید.

مبنای سخت‌گیرانه `exec.security: "deny"` همه فراخوانی‌های exec را، از جمله
عیب‌یابی‌های بی‌خطر، مسدود می‌کند. اگر عیب‌یابی یا فرمان‌های کم‌ریسک لازم است،
این را فقط پس از انتخاب فرستندگان، عامل‌ها، فرمان‌ها، و حالت تأیید مشخصی که با
مدل تهدید شما همخوان است، سست‌تر کنید.

## در معرض قرار گرفتن DM و گروه

کانال‌های پیام‌رسانی سطوح ورودی غیرقابل اعتماد هستند. پیش از اجازه دادن به DMها
یا گروه‌ها:

- `dmPolicy: "pairing"` یا فهرست‌های سخت‌گیرانه `allowFrom` را ترجیح دهید.
- از `dmPolicy: "open"` پرهیز کنید، مگر اینکه هر فرستنده مورد اعتماد باشد.
- allowlistهای `"*"` را با دسترسی گسترده به ابزارها ترکیب نکنید.
- در گروه‌ها mention را الزامی کنید، مگر اینکه اتاق کاملا کنترل‌شده باشد.
- وقتی چند نفر می‌توانند به ربات DM بدهند، از `session.dmScope: "per-channel-peer"` استفاده کنید.
- کانال‌های مشترک را به عامل‌هایی هدایت کنید که ابزارهای حداقلی دارند و اعتبارنامه شخصی ندارند.

pairing فرستنده را برای فعال کردن ربات تأیید می‌کند. این کار آن فرستنده را به
یک مرز امنیتی میزبان جداگانه تبدیل نمی‌کند.

## بررسی‌های پراکسی معکوس

برای پراکسی‌های آگاه از هویت:

- پراکسی باید پیش از ارسال به Gateway کاربران را احراز هویت کند.
- دسترسی مستقیم به پورت Gateway باید با دیوار آتش یا سیاست شبکه مسدود شود.
- `gateway.trustedProxies` باید فقط IPهای منبع پراکسی را در بر داشته باشد.
- پراکسی باید سرآیندهای هویت و forwarding ارائه‌شده توسط کلاینت را حذف یا بازنویسی کند.
- وقتی پراکسی به بیش از یک مخاطب سرویس می‌دهد، `gateway.auth.trustedProxy.allowUsers` باید کاربران مورد انتظار را فهرست کند.
- حالت پراکسی loopback روی همان میزبان فقط زمانی باید از `allowLoopback` استفاده کند که فرایندهای محلی مورد اعتماد باشند و پراکسی مالک سرآیندهای هویت باشد.

پس از تغییرات پراکسی، `openclaw security audit --deep` را اجرا کنید. یافته‌های
trusted-proxy عمدا سیگنال بالایی دارند، چون پراکسی به مرز احراز هویت تبدیل می‌شود.

## بازبینی ابزار و sandbox

پیش از در معرض قرار دادن یک عامل برای فرستندگان راه دور:

- تأیید کنید کدام نشست‌ها روی میزبان اجرا می‌شوند و کدام‌ها در sandbox.
- اجرای میزبان را رد کنید یا برای آن تأیید بخواهید.
- ابزارهای ارتقایافته را غیرفعال نگه دارید، مگر اینکه یک فرستنده مشخص و مورد اعتماد به آن‌ها نیاز داشته باشد.
- برای سطوح پیام‌رسانی باز یا نیمه‌باز، از ابزارهای مرورگر، canvas، Node، Cron، Gateway، و session-spawn پرهیز کنید.
- bind mountها را محدود نگه دارید و از مسیرهای اعتبارنامه، home، سوکت Docker، و سیستم پرهیز کنید.
- برای مرزهای اعتماد با تفاوت معنادار، از gatewayها، کاربران سیستم‌عامل، یا میزبان‌های جداگانه استفاده کنید.

اگر کاربران راه دور کاملا مورد اعتماد نیستند، ایزوله‌سازی باید از استقرارهای
جداگانه بیاید، نه فقط از promptها یا برچسب‌های نشست.

## اعتبارسنجی پس از تغییر

پس از هر تغییر در معرض‌سازی:

1. `openclaw security audit --deep` را دوباره اجرا کنید.
2. یک اتصال مجاز موفق را آزمایش کنید.
3. آزمایش کنید که یک فرستنده یا نشست مرورگر غیرمجاز رد می‌شود.
4. تأیید کنید لاگ‌ها اسرار را redact می‌کنند.
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 و اعتبارنامه‌های integration آسیب‌دیده را rotate کنید.
3. `"*"` و فرستندگان غیرمنتظره را از allowlistها حذف کنید.
4. لاگ‌های ممیزی اخیر، تاریخچه اجرا، فراخوانی‌های ابزار، و تغییرات پیکربندی را بازبینی کنید.
5. `openclaw security audit --deep` را دوباره اجرا کنید.
6. دسترسی را با باریک‌ترین الگویی که نیاز گردش کار را برآورده می‌کند دوباره فعال کنید.

## چک‌لیست بازبینی

- Gateway فقط روی loopback باقی می‌ماند، مگر اینکه دلیل مستندی وجود داشته باشد.
- دسترسی غیر loopback احراز هویت، دیوار آتش، و نبود مسیر مستقیم عمومی دارد.
- استقرارهای trusted-proxy دارای IPهای پراکسی و کنترل‌های سرآیند سخت‌گیرانه هستند.
- DMها به‌صورت پیش‌فرض از pairing یا allowlistها استفاده می‌کنند، نه دسترسی باز.
- گروه‌ها به mention یا allowlistهای صریح نیاز دارند.
- کانال‌های مشترک به اعتبارنامه‌های شخصی دسترسی پیدا نمی‌کنند.
- نشست‌های غیر main در حالت sandbox اجرا می‌شوند.
- اجرای میزبان و ابزارهای ارتقایافته رد می‌شوند یا پشت تأیید قرار دارند.
- لاگ‌ها اسرار را redact می‌کنند.
- یافته‌های بحرانی ممیزی رفع شده‌اند.
- مراحل بازگشت آزمایش و مستند شده‌اند.