---
read_when:
    - การเปิดให้เข้าถึง Gateway ผ่าน LAN, tailnet, Tailscale Serve, Funnel หรือพร็อกซีย้อนกลับ
    - ตรวจสอบการติดตั้งใช้งานก่อนอนุญาตให้ผู้ใช้จริงส่งข้อความ
    - การย้อนกลับการกำหนดค่าการเข้าถึงระยะไกลหรือ DM ที่มีความเสี่ยง
sidebarTitle: Exposure runbook
summary: รายการตรวจสอบก่อนดำเนินการและการย้อนกลับ ก่อนเปิดให้เข้าถึง Gateway ของ OpenClaw จากภายนอก local loopback
title: คู่มือปฏิบัติการสำหรับการเปิดให้เข้าถึง Gateway
x-i18n:
    generated_at: "2026-07-12T16:09:59Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: fb8e66af57e804325afc91281122b822183337177c734efe065c5fc18b175e72
    source_path: gateway/security/exposure-runbook.md
    workflow: 16
---

<Warning>
เปิดให้เข้าถึง Gateway เฉพาะหลังจากที่คุณสามารถอธิบายได้ว่าใครเข้าถึงได้บ้าง ผู้ใช้เหล่านั้น
ผ่านการยืนยันตัวตนอย่างไร สามารถเรียกใช้เอเจนต์ใดได้บ้าง และเอเจนต์เหล่านั้นสามารถ
ใช้เครื่องมือใดได้บ้าง หากไม่แน่ใจ ให้กลับไปใช้การเข้าถึงผ่าน local loopback เท่านั้นและเรียกใช้การตรวจสอบอีกครั้ง
</Warning>

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

## เลือกรูปแบบการเปิดให้เข้าถึง

เลือกรูปแบบที่จำกัดที่สุดซึ่งยังตอบโจทย์เวิร์กโฟลว์

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

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

## รายการข้อมูลก่อนเริ่มดำเนินการ

บันทึกข้อมูลต่อไปนี้ก่อนเปลี่ยนนโยบายการผูกเครือข่าย พร็อกซี Tailscale หรือช่องทาง:

- โฮสต์ของ Gateway ผู้ใช้ระบบปฏิบัติการ และไดเรกทอรีสถานะ (ค่าเริ่มต้นคือ `~/.openclaw`)
- URL ของ Gateway และโหมดการผูกเครือข่าย (`gateway.bind`; พอร์ตเริ่มต้นคือ `18789`)
- โหมดการยืนยันตัวตน แหล่งที่มาของโทเค็น/รหัสผ่าน หรือแหล่งข้อมูลประจำตัวจากพร็อกซีที่เชื่อถือได้
- ช่องทางที่เปิดใช้งานทั้งหมด และแต่ละช่องทางรับข้อความส่วนตัว กลุ่ม หรือ Webhook หรือไม่
- เอเจนต์ที่ผู้ส่งซึ่งไม่ได้อยู่ในเครื่องสามารถเข้าถึงได้
- โปรไฟล์เครื่องมือ โหมดแซนด์บ็อกซ์ และนโยบายเครื่องมือที่มีสิทธิ์ระดับสูงสำหรับเอเจนต์แต่ละตัวที่เข้าถึงได้
- ข้อมูลประจำตัวภายนอกที่เอเจนต์เหล่านั้นใช้งานได้
- ตำแหน่งสำรองข้อมูลสำหรับ `~/.openclaw/openclaw.json` และข้อมูลประจำตัว

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

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

เรียกใช้คำสั่งต่อไปนี้ก่อนเปิดให้เข้าถึง:

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

แก้ไขผลการตรวจสอบระดับวิกฤตก่อน ยอมรับคำเตือนเฉพาะเมื่อเป็นสิ่งที่ตั้งใจไว้และ
มีเอกสารกำกับสำหรับการติดตั้งใช้งานนั้น ดู [การตรวจสอบในการตรวจสอบความปลอดภัย](/th/gateway/security/audit-checks)
เพื่อดูความหมายของแต่ละ `checkId` และคีย์สำหรับการแก้ไข

สำหรับการตรวจสอบ 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"` บล็อกการเรียกใช้คำสั่งทั้งหมด รวมถึง
คำสั่งวินิจฉัยที่ไม่เป็นอันตราย หากจำเป็นต้องใช้คำสั่งวินิจฉัยหรือคำสั่งที่มีความเสี่ยงต่ำ ให้ผ่อนปรนค่านี้เฉพาะ
หลังจากเลือกผู้ส่ง เอเจนต์ คำสั่ง และโหมดการอนุมัติที่เฉพาะเจาะจง
ซึ่งตรงกับแบบจำลองภัยคุกคามของคุณแล้ว

## การเปิดรับข้อความส่วนตัวและกลุ่ม

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

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

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

## การตรวจสอบรีเวิร์สพร็อกซี

สำหรับพร็อกซีที่รับรู้ข้อมูลประจำตัว:

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

เรียกใช้ `openclaw security audit --deep` หลังเปลี่ยนแปลงพร็อกซี ผลการตรวจสอบ
พร็อกซีที่เชื่อถือได้มีความสำคัญสูง เนื่องจากพร็อกซีจะกลายเป็นขอบเขต
การยืนยันตัวตน

## การทบทวนเครื่องมือและแซนด์บ็อกซ์

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

- ยืนยันว่าเซสชันใดทำงานบนโฮสต์และเซสชันใดทำงานในแซนด์บ็อกซ์
- ปฏิเสธหรือกำหนดให้ต้องอนุมัติการเรียกใช้คำสั่งบนโฮสต์
- ปิดใช้เครื่องมือที่มีสิทธิ์ระดับสูงไว้ เว้นแต่ผู้ส่งที่เฉพาะเจาะจงและเชื่อถือได้จำเป็นต้องใช้
- หลีกเลี่ยงเครื่องมือเบราว์เซอร์ แคนวาส Node Cron Gateway และการสร้างเซสชัน สำหรับพื้นผิวรับส่งข้อความ
  แบบเปิดหรือกึ่งเปิด
- จำกัดขอบเขตไดเรกทอรีที่เมานต์ให้แคบ หลีกเลี่ยงพาธข้อมูลประจำตัว โฮม Docker socket และพาธ
  ของระบบ
- ใช้ Gateway ผู้ใช้ระบบปฏิบัติการ หรือโฮสต์แยกกัน สำหรับขอบเขตความเชื่อถือ
  ที่แตกต่างกันอย่างมีนัยสำคัญ

หากผู้ใช้ระยะไกลไม่ได้รับความเชื่อถืออย่างสมบูรณ์ การแยกต้องมาจากการติดตั้งใช้งาน
ที่แยกกัน ไม่ใช่อาศัยเพียงพรอมต์หรือป้ายกำกับเซสชัน

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

หลังการเปลี่ยนแปลงการเปิดให้เข้าถึงแต่ละครั้ง:

1. เรียกใช้ `openclaw security audit --deep` อีกครั้ง
2. ยืนยันว่าการเชื่อมต่อที่ได้รับอนุญาตสำเร็จ
3. ยืนยันว่าผู้ส่งหรือเซสชันเบราว์เซอร์ที่ไม่ได้รับอนุญาตถูกปฏิเสธ
4. ยืนยันว่าบันทึกปกปิดข้อมูลลับ
5. ยืนยันว่าการกำหนดเส้นทางข้อความส่วนตัว/กลุ่มเข้าถึงเฉพาะเอเจนต์ที่ตั้งใจไว้
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 ยังคงเข้าถึงได้ผ่าน loopback เท่านั้น เว้นแต่จะมีเหตุผลที่จัดทำเป็นเอกสาร
- การเข้าถึงที่ไม่ใช่ loopback มีการยืนยันตัวตน ไฟร์วอลล์ และไม่มีเส้นทางสาธารณะโดยตรง
- การติดตั้งใช้งานพร็อกซีที่เชื่อถือได้กำหนด IP ของพร็อกซีและการควบคุมเฮดเดอร์อย่างเคร่งครัด
- ข้อความส่วนตัวใช้การจับคู่หรือรายการอนุญาต ไม่ใช่การเข้าถึงแบบเปิดโดยค่าเริ่มต้น
- กลุ่มกำหนดให้ต้องกล่าวถึงหรือมีรายการอนุญาตอย่างชัดเจน
- ช่องทางที่ใช้ร่วมกันไม่สามารถเข้าถึงข้อมูลประจำตัวส่วนบุคคล
- เซสชันที่ไม่ใช่เซสชันหลักทำงานในโหมดแซนด์บ็อกซ์
- การเรียกใช้คำสั่งบนโฮสต์และเครื่องมือที่มีสิทธิ์ระดับสูงถูกปฏิเสธหรืออยู่ภายใต้การอนุมัติ
- บันทึกปกปิดข้อมูลลับ
- ผลการตรวจสอบระดับวิกฤตได้รับการแก้ไขแล้ว
- ขั้นตอนการย้อนกลับได้รับการทดสอบและจัดทำเป็นเอกสารแล้ว