EST. 2026 — บันทึกงานเซิร์ฟเวอร์จริง SYSADMIN · SECURITY · AI · DIRECTADMIN เล่มที่ 01
THE SYSADMIN ALMANAC
หน้าหลัก / Network / ให้ทีม 7 คน remote เข้า LAN โดยไม่เปิด port — Cloudflare Zero Trust ฉบับทำจริง
Network

ให้ทีม 7 คน remote เข้า LAN โดยไม่เปิด port — Cloudflare Zero Trust ฉบับทำจริง

โดย Ton-Or ·9 ก.ค. 2026·อ่าน 10 นาที
ให้ทีม 7 คน remote เข้า LAN โดยไม่เปิด port — Cloudflare Zero Trust ฉบับทำจริง

RDP เปิดสู่โลก = โดนสแกนภายในนาทีแรก — ทางที่ให้ทีมทั้งทีม remote เข้า LAN ได้โดย router ไม่ต้อง forward port สักพอร์ต คือ tunnel ขาออกอย่างเดียว แล้วคุมสิทธิ์รายคน รายเครื่อง ราย port จากหน้าจอเดียว

พอดีมีโจทย์จริงจากงานจริงครับ: ทีมงาน 7 คน (อยู่ต่างจังหวัดบ้าง ต่างประเทศบ้าง) ต้องเข้าถึงเครื่องใน LAN ภายใน — RDP เข้าเครื่อง Windows, หน้าเว็บ Proxmox, ระบบภายในอีกสองสามตัว เงื่อนไขของผมมีข้อเดียวที่ไม่ยอมแลก: ห้ามเปิด port อะไรออก internet ทั้งสิ้น (RDP เปิดสู่โลก = โดนสแกนภายในนาทีแรก อันนี้ของจริง log ยืนยันได้)

ผมเคยเขียนเรื่อง WireGuard ไปแล้ว (ยังใช้อยู่และยังชอบ) แต่รอบนี้เลือก Cloudflare Zero Trust (WARP + cloudflared) เพราะโจทย์ต่างกัน: คนใช้ไม่ใช่สายเทคนิค แจก config file ให้ import กันเองคงวุ่น และผมอยากคุมสิทธิ์รายคน รายเครื่อง ราย port จากหน้าจอเดียว

ชื่อทีม อีเมล และ IP ภายในในบทความเป็นค่าสมมติทั้งหมด (10.99.x.x)

สถาปัตยกรรม

เส้นทาง trafficเครื่องทีมงานWARP client→Cloudflare edgeAccess + Gateway policy→cloudflaredใน LAN — tunnel ขาออก→10.99.x.xRDP / Proxmox / แอปภายใน

หัวใจคือ tunnel เป็น outbound จากใน LAN ออกไปหา Cloudflare — router ที่บ้าน/office ไม่ต้อง forward port อะไรเลย ฝั่งผู้ใช้ลง WARP client แล้ว login team เดียวจบ

ฝั่ง gateway ใน LAN (Linux อะไรก็ได้ ผมใช้ VM เล็กๆ):

cloudflared tunnel create lan-gw
cloudflared tunnel route ip add 10.99.1.0/24 lan-gw
cloudflared tunnel route ip add 10.99.2.0/24 lan-gw
cloudflared tunnel route ip add 10.99.3.0/24 lan-gw
cloudflared service install   # รันเป็น systemd service

บทเรียนที่ 1: เพิ่มอีเมลใน policy แล้ว ทำไม login ไม่ได้

อันนี้ผมเสียเวลาจริง เลยอยากเน้นครับ: เพิ่มอีเมลทีมงานเข้า Access policy แล้ว ทีมงาน enroll WARP ขึ้น error:

This account is restricted to members of the account

ไล่ไปไล่มาพบว่า Zero Trust team ที่สร้างใหม่ ยังไม่มี login method (Identity Provider) เลย — Access policy บอกแค่ "อีเมลไหนผ่านได้" แต่ต้องมี IdP ให้คนพิสูจน์ตัวก่อนว่าเป็นเจ้าของอีเมลนั้น ทางแก้ที่ง่ายสุดไม่ต้องพึ่ง Google/Azure:

Zero Trust dashboard -> Settings -> Authentication -> เปิด One-time PIN

เท่านี้ทีมงานใส่อีเมล รับ PIN ทางเมล แล้วเข้าได้ สรุปการเพิ่มสมาชิกหนึ่งคนต้องครบ 3 ชั้น จำเป็น checklist ไว้เลย:

  1. IdP — มีช่องทาง login (OTP อย่างน้อยหนึ่งตัว)
  2. Access/enrollment policy — อีเมลคนนั้นอยู่ใน allow list
  3. Gateway policy — กำหนดว่า login แล้วไปเครื่องไหน port ไหนได้

ขาดชั้นไหนชั้นหนึ่ง = เข้าไม่ได้ หรือแย่กว่าคือเข้าได้เกินสิทธิ์

บทเรียนที่ 2: default ของ Gateway คือ "ผ่านหมด" — ต้องปิดเอง

พอ tunnel ติด ทุกคนที่ enroll ได้จะเห็นทุก subnet ที่ route ไว้ ถ้าไม่ตั้ง Gateway network policy คุม นี่ไม่ใช่ Zero Trust แต่เป็น full-trust VPN ธรรมดา วิธีที่ผมวาง (ตาม principle of least privilege):

  • แอดมิน — ทุก subnet ทุก port
  • ทีมในองค์กร 4 คน — 3 subnet เฉพาะ port 3389 (RDP), 8006 (Proxmox), 8090 (ระบบภายใน)
  • ทีม outsource 3 คน — เฉพาะเครื่องที่ระบุรายตัว 5 IP, 3 port เดิม
  • ทุกคน — เครื่องแอปภายในตัวเดียว port 7276

โครง rule ใน Gateway (Network policies) เรียงจากบนลงล่าง:

1. Allow  identity.email in {อีเมลแอดมิน}          -> dst 10.99.0.0/16
2. Allow  identity.email in {ทีม 4 คน}             -> dst in {3 subnets} AND port in {3389,8006,8090}
3. Allow  identity.email in {outsource 3 คน}       -> dst in {5 IPs}     AND port in {3389,8006,8090}
4. Allow  ทุก identity                              -> dst 10.99.2.254   AND port 7276
5. Block  (default-deny ปิดท้าย)                   -> dst 10.99.0.0/16
ข้อ 5 สำคัญสุดและคนลืมบ่อยสุด

ไม่มี rule Block ปิดท้าย = ทุกอย่างที่ไม่ match ผ่านฉลุย — เท่ากับทำ Zero Trust มาทั้งชุดแต่ประตูหลังเปิดโล่ง

ทำผ่าน API ได้ด้วยถ้าจัดการหลายคนบ่อยๆ (ผมเขียนสคริปต์ Python ครอบไว้ เพิ่ม/ถอดคนได้ในคำสั่งเดียว):

curl -s -X PUT \
  "https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/gateway/rules/<RULE_ID>" \
  -H "Authorization: Bearer $CF_TOKEN" -H 'Content-Type: application/json' \
  --data '{"name":"team-rdp","action":"allow",
    "traffic":"net.dst.ip in {10.99.1.0/24 10.99.2.0/24} and net.dst.port in {3389 8006 8090}",
    "identity":"identity.email in {\"[email protected]\" \"[email protected]\"}"}'

บทเรียนที่ 3: เรื่องจุกจิกที่เจอจริง

  • สะกดอีเมลผิดตัวเดียว = คนนั้น enroll ไม่ได้ และ error ฝั่ง user ไม่บอกสาเหตุ — เช็คตัวสะกดก่อนไล่อย่างอื่น (เจอมาแล้วครับ ต่างกันตัว l ตัวเดียว)
  • AnyDesk/แอปที่ใช้ port ช่วงกว้าง ต้องเพิ่ม port range ใน allow rule ไม่งั้นต่อติดแต่ใช้ไม่ได้
  • WARP client ฝั่ง Windows ถ้าเคย login team อื่นค้าง ให้ logout ให้สะอาดก่อน ไม่งั้นอาการเพี้ยนแบบอธิบายยาก

เทียบกับ WireGuard แล้วเลือกอะไร

WireGuard

ทีมเล็ก สายเทคนิค

  • คุมเครื่องปลายทางได้หมด
  • ความเร็วเต็มๆ ไม่ผ่านคนกลาง
  • config file ต่อเครื่อง — แจกเองดูแลเอง
Cloudflare Zero Trust

คนใช้หลากหลาย เพิ่ม/ถอดบ่อย

  • audit log + คุมสิทธิ์ราย port รายคน
  • ไม่แตะ router ไม่เปิด port
  • ผู้ใช้แค่ลง WARP + login อีเมล

ส่วนตัวผมตอนนี้ใช้ทั้งคู่ครับ — WireGuard สำหรับตัวเองเข้าไปดูแลระบบ, Zero Trust สำหรับทีมงาน แยกหน้าที่กันชัดเจน ใครโจทย์ใกล้แบบไหนก็เลือกตามหน้างานได้ตามสะดวก ตรงไหนผมอธิบายตกหล่นหรือพิมพ์ผิด เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ

อยากให้เราทำให้ไหม?

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

คุยเรื่องงานกับเรา

เคยเจองานแบบนี้ไหม? ติดตรงไหน?

มาแลกวิธีกันต่อในบอร์ด LinuxThai

→ คุยต่อในบอร์ด

ความคิดเห็น 0

ยังไม่มีความคิดเห็น — เป็นคนแรกเลย