---
read_when:
    - การเปิดให้เข้าถึง Gateway ผ่าน LAN, tailnet, Tailscale Serve, Funnel หรือพร็อกซีย้อนกลับ
    - กำลังตรวจสอบการปรับใช้ก่อนอนุญาตให้ผู้ใช้ส่งข้อความจริง
    - การย้อนกลับการกำหนดค่าการเข้าถึงระยะไกลหรือข้อความส่วนตัวที่มีความเสี่ยง
sidebarTitle: Exposure runbook
summary: รายการตรวจสอบก่อนเริ่มใช้งานและการย้อนกลับก่อนเปิดเผย OpenClaw Gateway ออกนอก loopback
title: คู่มือการเปิดเผย Gateway
x-i18n:
    generated_at: "2026-06-27T17:38:41Z"
    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-only แล้วรันการตรวจสอบอีกครั้ง
</Warning>

Runbook นี้แปลงคำแนะนำ [ความปลอดภัย](/th/gateway/security) ที่กว้างขึ้นให้เป็นเช็กลิสต์สำหรับผู้ปฏิบัติงานสำหรับการเข้าถึงระยะไกลและการเปิดรับการส่งข้อความ

## เลือกรูปแบบการเปิดเผย

ควรใช้รูปแบบที่แคบที่สุดซึ่งตอบโจทย์เวิร์กโฟลว์

| รูปแบบ                    | แนะนำเมื่อ                                | การควบคุมที่ต้องมี                                                                                   |
| -------------------------- | ----------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| Loopback + SSH tunnel      | การใช้งานส่วนตัว, การเข้าถึงของผู้ดูแลระบบ, การดีบัก           | คง `gateway.bind: "loopback"` ไว้และสร้าง tunnel ไปยัง `127.0.0.1:18789`                                        |
| Loopback + Tailscale Serve | การเข้าถึง Control UI/WebSocket ผ่าน tailnet ส่วนตัว | คง Gateway ให้เป็น loopback-only; พึ่งพา header ระบุตัวตนของ Tailscale เฉพาะสำหรับพื้นผิวที่รองรับเท่านั้น          |
| Tailnet/LAN bind           | เครือข่ายส่วนตัวเฉพาะที่มีอุปกรณ์ที่รู้จัก    | การยืนยันตัวตนของ Gateway, allowlist ของไฟร์วอลล์, ไม่มีการ forward พอร์ตสาธารณะ                                            |
| Trusted reverse proxy      | SSO/OIDC ขององค์กรอยู่หน้า Gateway       | การยืนยันตัวตนแบบ `trusted-proxy`, `trustedProxies` ที่เข้มงวด, กฎ overwrite/strip header, ผู้ใช้ที่อนุญาตอย่างชัดเจน |
| อินเทอร์เน็ตสาธารณะ            | การปรับใช้ที่พบไม่บ่อยและมีความเสี่ยงสูง                     | proxy ที่รับรู้ตัวตน, TLS, rate limits, allowlists ที่เข้มงวด, เซสชัน non-main ที่อยู่ใน sandbox              |

หลีกเลี่ยงการ forward พอร์ตสาธารณะไปยัง Gateway โดยตรง หากคุณต้องการการเข้าถึงสาธารณะ ให้วาง proxy ที่รับรู้ตัวตนไว้ข้างหน้า และทำให้ proxy เป็นเส้นทางเครือข่ายเดียวไปยัง Gateway

## รายการตรวจสอบก่อนดำเนินการ

บันทึกสิ่งเหล่านี้ก่อนเปลี่ยนนโยบาย bind, proxy, Tailscale หรือ channel:

- โฮสต์ Gateway, ผู้ใช้ OS และไดเรกทอรีสถานะ
- URL ของ Gateway และโหมด bind
- โหมดการยืนยันตัวตน, แหล่ง token/password หรือแหล่งตัวตนของ trusted proxy
- channel ทั้งหมดที่เปิดใช้งานและระบุว่ายอมรับ DM, กลุ่ม หรือ webhooks หรือไม่
- เอเจนต์ที่ผู้ส่งที่ไม่ใช่ local เข้าถึงได้
- โปรไฟล์เครื่องมือ, โหมด sandbox และนโยบายเครื่องมือแบบยกระดับสำหรับเอเจนต์แต่ละตัวที่เข้าถึงได้
- ข้อมูลประจำตัวภายนอกที่เอเจนต์เหล่านั้นเข้าถึงได้
- ตำแหน่งสำรองสำหรับ `~/.openclaw/openclaw.json` และข้อมูลประจำตัว

หากมีมากกว่าหนึ่งคนที่ส่งข้อความถึงบอตได้ ให้ถือว่านี่เป็นสิทธิ์การใช้เครื่องมือที่มอบหมายร่วมกัน ไม่ใช่การแยกโฮสต์แบบรายผู้ใช้

## การตรวจสอบพื้นฐาน

รันคำสั่งเหล่านี้ก่อนเปิดการเข้าถึง:

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

แก้ไขผลการตรวจสอบระดับ critical ก่อน คำเตือนอาจยอมรับได้เฉพาะเมื่อเป็นความตั้งใจและมีเอกสารกำกับสำหรับการปรับใช้นั้น

สำหรับการตรวจสอบ CLI ระยะไกล ให้ส่งข้อมูลประจำตัวอย่างชัดเจน:

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

อย่าถือว่าข้อมูลประจำตัวใน config local จะใช้กับ URL ระยะไกลที่ระบุอย่างชัดเจน

## baseline ขั้นต่ำที่ปลอดภัย

ใช้รูปแบบนี้เป็นจุดเริ่มต้นสำหรับการปรับใช้ที่เปิดเผย:

```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 ของ channel ที่เจาะจงก่อนเปิดใช้งานเครื่องมือที่เขียนได้ หรือเปิดใช้งาน reverse proxy ก่อนยอมรับทราฟฟิก Control UI ระยะไกล

baseline `exec.security: "deny"` ที่เข้มงวดจะบล็อกการเรียก exec ทั้งหมด รวมถึงการวินิจฉัยที่ไม่เป็นอันตราย หากต้องใช้การวินิจฉัยหรือคำสั่งที่มีความเสี่ยงต่ำ ให้ผ่อนคลายค่านี้เฉพาะหลังจากเลือกผู้ส่ง เอเจนต์ คำสั่ง และโหมดการอนุมัติที่ตรงกับโมเดลภัยคุกคามของคุณแล้ว

## การเปิดรับ DM และกลุ่ม

channel การส่งข้อความเป็นพื้นผิวรับ input ที่ไม่น่าเชื่อถือ ก่อนอนุญาต DM หรือกลุ่ม:

- ควรใช้ `dmPolicy: "pairing"` หรือรายการ `allowFrom` ที่เข้มงวด
- หลีกเลี่ยง `dmPolicy: "open"` เว้นแต่ว่าผู้ส่งทุกคนเชื่อถือได้
- อย่ารวม allowlist `"*"` กับการเข้าถึงเครื่องมือแบบกว้าง
- กำหนดให้มี mention ในกลุ่ม เว้นแต่ว่าห้องจะถูกควบคุมอย่างเข้มงวด
- ใช้ `session.dmScope: "per-channel-peer"` เมื่อหลายคนสามารถส่ง DM ถึงบอตได้
- กำหนดเส้นทาง channel ที่ใช้ร่วมกันไปยังเอเจนต์ที่มีเครื่องมือน้อยที่สุดและไม่มีข้อมูลประจำตัวส่วนตัว

การ pairing อนุมัติให้ผู้ส่งทริกเกอร์บอตได้ แต่ไม่ได้ทำให้ผู้ส่งนั้นเป็นขอบเขตความปลอดภัยของโฮสต์ที่แยกต่างหาก

## การตรวจสอบ reverse proxy

สำหรับ proxy ที่รับรู้ตัวตน:

- proxy ต้องยืนยันตัวตนผู้ใช้ก่อนส่งต่อไปยัง Gateway
- การเข้าถึงพอร์ต Gateway โดยตรงต้องถูกบล็อกด้วยไฟร์วอลล์หรือนโยบายเครือข่าย
- `gateway.trustedProxies` ต้องมีเฉพาะ IP ต้นทางของ proxy เท่านั้น
- proxy ต้อง strip หรือ overwrite header ระบุตัวตนและ forwarding ที่ client ส่งมา
- `gateway.auth.trustedProxy.allowUsers` ควรระบุผู้ใช้ที่คาดไว้เมื่อ proxy ให้บริการมากกว่าหนึ่งกลุ่มผู้ชม
- โหมด proxy loopback บนโฮสต์เดียวกันควรใช้ `allowLoopback` เฉพาะเมื่อ process local เชื่อถือได้และ proxy เป็นเจ้าของ header ระบุตัวตน

รัน `openclaw security audit --deep` หลังเปลี่ยน proxy ผลการตรวจสอบ trusted-proxy ตั้งใจให้มีสัญญาณสูง เพราะ proxy กลายเป็นขอบเขตการยืนยันตัวตน

## การตรวจสอบเครื่องมือและ sandbox

ก่อนเปิดเผยเอเจนต์ให้ผู้ส่งระยะไกล:

- ยืนยันว่าเซสชันใดรันบน host เทียบกับ sandbox
- ปฏิเสธหรือกำหนดให้ต้องอนุมัติสำหรับ host exec
- ปิดใช้งานเครื่องมือแบบยกระดับไว้ เว้นแต่ว่าผู้ส่งที่เจาะจงและเชื่อถือได้จำเป็นต้องใช้
- หลีกเลี่ยงเครื่องมือ browser, canvas, node, cron, gateway และ session-spawn สำหรับพื้นผิวการส่งข้อความที่เปิดหรือกึ่งเปิด
- จำกัด bind mount ให้แคบ และหลีกเลี่ยงข้อมูลประจำตัว, home, Docker socket และ path ระบบ
- ใช้ gateways, ผู้ใช้ OS หรือ hosts แยกกันสำหรับขอบเขตความเชื่อถือที่แตกต่างกันอย่างมีนัยสำคัญ

หากผู้ใช้ระยะไกลไม่ได้เชื่อถือได้ทั้งหมด การแยกต้องมาจากการปรับใช้แยกกัน ไม่ใช่จาก prompt หรือ label ของเซสชันเท่านั้น

## การตรวจสอบหลังการเปลี่ยนแปลง

หลังจากการเปลี่ยนแปลงการเปิดเผยแต่ละครั้ง:

1. รัน `openclaw security audit --deep` อีกครั้ง
2. ทดสอบการเชื่อมต่อที่ได้รับอนุญาตสำเร็จ
3. ทดสอบว่าผู้ส่งหรือเซสชันเบราว์เซอร์ที่ไม่ได้รับอนุญาตถูกปฏิเสธ
4. ยืนยันว่า log ปกปิดความลับ
5. ยืนยันว่าการกำหนดเส้นทาง DM/กลุ่มเข้าถึงเฉพาะเอเจนต์ที่ตั้งใจไว้
6. ยืนยันว่าเครื่องมือที่มีผลกระทบสูงขอการอนุมัติหรือถูกปฏิเสธ
7. บันทึกคำเตือนคงเหลือที่ยอมรับไว้

อย่าดำเนินการเปลี่ยนแปลงการเปิดเผยถัดไปจนกว่าจะเข้าใจการเปลี่ยนแปลงปัจจุบัน

## แผน rollback

หาก 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. หยุด public forwarding, Tailscale Funnel หรือเส้นทาง reverse proxy
2. หมุนเวียน token/password ของ Gateway และข้อมูลประจำตัวของ integration ที่ได้รับผลกระทบ
3. ลบ `"*"` และผู้ส่งที่ไม่คาดคิดออกจาก allowlists
4. ตรวจสอบ audit logs, run history, tool calls และ config changes ล่าสุด
5. รัน `openclaw security audit --deep` อีกครั้ง
6. เปิดใช้งานการเข้าถึงอีกครั้งด้วยรูปแบบที่แคบที่สุดซึ่งตอบโจทย์เวิร์กโฟลว์

## เช็กลิสต์การตรวจทาน

- Gateway ยังคงเป็น loopback-only เว้นแต่จะมีเหตุผลที่บันทึกไว้
- การเข้าถึงแบบ non-loopback มีการยืนยันตัวตน ไฟร์วอลล์ และไม่มีเส้นทางตรงสาธารณะ
- การปรับใช้ trusted-proxy มี IP ของ proxy และการควบคุม header ที่เข้มงวด
- DM ใช้ pairing หรือ allowlists ไม่ใช่การเข้าถึงแบบเปิดเป็นค่าเริ่มต้น
- กลุ่มต้องมี mention หรือ allowlists ที่ชัดเจน
- channel ที่ใช้ร่วมกันไม่เข้าถึงข้อมูลประจำตัวส่วนตัว
- เซสชัน non-main รันในโหมด sandbox
- host exec และเครื่องมือแบบยกระดับถูกปฏิเสธหรือถูก gate ด้วยการอนุมัติ
- log ปกปิดความลับ
- ผลการตรวจสอบระดับ critical ได้รับการแก้ไขแล้ว
- ขั้นตอน rollback ได้รับการทดสอบและบันทึกไว้