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 จากหน้าจอเดียว

สรุปใน 1 นาที

อาการ/ปัญหา
ทีม 7 คนต้อง RDP เข้า LAN โดยห้าม forward port เพราะ RDP เปิดสู่โลกโดนสแกนทันที
ใครควรอ่าน
คนดูแลเครือข่ายที่ต้องให้ทีม remote เข้า LAN โดยไม่เปิด port
ทางแก้แบบสั้น
ใช้ Cloudflare Zero Trust ด้วย WARP กับ cloudflared tunnel ขาออก ตั้ง IdP ให้ครบ ปิดค่า Gateway ที่ผ่านหมด และทำ default-deny รายคน รายเครื่อง ราย 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

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