เปิดตัว Cloudflare Mesh - เครือข่ายส่วนตัวที่ปลอดภัยสำหรับผู้ใช้ โหนด เอเจนต์ และ Workers

 (blog.cloudflare.com)
5 คะแนน โดย GN⁺ 16 일 전 | 5 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในยุคที่เอเจนต์ AI ต้องเข้าถึงทรัพยากรเครือข่ายส่วนตัวอย่างปลอดภัย เครื่องมือเดิมอย่าง VPN หรือ SSH tunnel มีข้อจำกัดเชิงโครงสร้างที่ไม่เหมาะกับซอฟต์แวร์อัตโนมัติที่ไม่ใช่มนุษย์
  • Cloudflare Mesh เป็นโซลูชันเครือข่ายส่วนตัวแบบสองทิศทางที่ใช้คอนเน็กเตอร์น้ำหนักเบาเพียงตัวเดียวเพื่อเชื่อมต่ออุปกรณ์ส่วนตัว เซิร์ฟเวอร์ระยะไกล และเอเจนต์เข้าด้วยกัน
  • ขยาย Workers VPC เพื่อให้เอเจนต์ที่สร้างด้วย Agents SDKเข้าถึงเครือข่าย Mesh ได้โดยตรง และรองรับการเชื่อมต่อบริการภายในผ่านการเรียก fetch() ด้วย binding เดียว
  • สำหรับผู้ใช้ Cloudflare One เดิม นโยบาย Gateway, กฎ Access และการตรวจสอบ device posture จะถูกนำไปใช้กับทราฟฟิก Mesh โดยอัตโนมัติโดยไม่ต้องตั้งค่าเพิ่ม
  • ให้ใช้ฟรีสูงสุด 50 โหนดและผู้ใช้ 50 คน พร้อม global edge routing ในกว่า 330 เมือง ทำให้ใช้งานได้ทันทีตั้งแต่สตาร์ทอัพไปจนถึงองค์กรขนาดใหญ่

ปัญหาการเข้าถึงเครือข่ายส่วนตัวในยุคของเอเจนต์

  • เวิร์กโฟลว์ที่เอเจนต์ AI ต้องเข้าถึงทรัพยากรส่วนตัว เช่น การคิวรี staging database, การเรียก internal API, และการเข้าถึงบริการใน home network กำลังเพิ่มขึ้นอย่างรวดเร็ว
  • ข้อจำกัดของเครื่องมือเดิม:
    • VPN ต้องใช้การล็อกอินแบบอินเทอร์แอ็กทีฟ
    • SSH tunnel ต้องมีการตั้งค่าด้วยตนเอง
    • หากเปิดบริการสู่สาธารณะจะเกิดความเสี่ยงด้านความปลอดภัย
    • ขาดการมองเห็นว่าเอเจนต์ทำอะไรจริงหลังจากเชื่อมต่อแล้ว

เวิร์กโฟลว์หลัก 3 แบบ

  • การเข้าถึงระยะไกลของเอเจนต์ส่วนตัว: เมื่อรัน OpenClaw บน Mac mini แล้วเข้าถึงจากมือถือหรือโน้ตบุ๊ก หากเปิดสู่สาธารณะจะทำให้ shell, file system และ network access เปิดทั้งหมด จนการตั้งค่าพลาดเพียงจุดเดียวก็เกิดความเสี่ยงด้านความปลอดภัยได้
  • การเข้าถึงสภาพแวดล้อม staging ของเอเจนต์เขียนโค้ด: เครื่องมืออย่าง Claude Code, Cursor และ Codex หากต้องเข้าถึงบริการใน private cloud VPC มักต้องเปิดสู่อินเทอร์เน็ตหรือทำ tunneling ทั้ง VPC
  • การเชื่อมต่อบริการส่วนตัวของเอเจนต์ที่ deploy แล้ว: เมื่อเอเจนต์ Workers ที่สร้างบน Agents SDK ต้องเข้าถึง internal API หรือ database จะต้องมีสิทธิ์แบบกำหนดขอบเขต, audit trail และการป้องกัน credential รั่วไหล

โครงสร้างและวิธีทำงานของ Cloudflare Mesh

  • ใช้คอนเน็กเตอร์น้ำหนักเบาเพียงตัวเดียว (binary) เพื่อเชื่อมต่ออุปกรณ์ส่วนตัว เซิร์ฟเวอร์ระยะไกล และ endpoint ของผู้ใช้ทั้งหมด
  • อุปกรณ์ที่เชื่อมต่อจะสื่อสารกันแบบสองทิศทางผ่านprivate IP โดยวิ่งผ่านเครือข่าย global ของ Cloudflare (มากกว่า 330 เมือง)
  • WARP Connector เดิมถูกเปลี่ยนชื่อเป็นCloudflare Mesh node และ WARP Client เปลี่ยนชื่อเป็นCloudflare One Client
  • ตัวอย่างการใช้งาน:
    • ใช้Cloudflare One Client สำหรับ iOSเพื่อเชื่อมต่อจากมือถือไปยัง OpenClaw บน Mac mini ภายในเครื่องอย่างปลอดภัย
    • ใช้Cloudflare One Client สำหรับ macOSเพื่อให้เอเจนต์เขียนโค้ดบนโน้ตบุ๊กเข้าถึง staging database และ API
    • ใช้Mesh node บนเซิร์ฟเวอร์ Linuxเพื่อเชื่อมต่อ external cloud VPC หลายแห่งเข้าด้วยกัน ทำให้เอเจนต์เข้าถึงทรัพยากรและ MCP ในเครือข่ายส่วนตัวภายนอกได้

ความแตกต่างระหว่าง Mesh กับ Tunnel

  • Cloudflare Tunnel: เหมาะกับการพร็อกซีทราฟฟิกทางเดียวจาก Cloudflare edge ไปยังบริการส่วนตัวเฉพาะ เช่น เว็บเซิร์ฟเวอร์หรือฐานข้อมูล
  • Cloudflare Mesh: ให้เครือข่ายแบบสองทิศทาง หลายต่อหลาย (many-to-many) ที่อุปกรณ์และโหนดทั้งหมดเข้าถึงกันได้ผ่าน private IP
    • ไม่จำเป็นต้องตั้ง Tunnel แยกสำหรับแต่ละทรัพยากร เพราะสามารถเข้าถึงทรัพยากรทั้งหมดที่เชื่อมต่ออยู่ใน Mesh ได้

การใช้เครือข่าย Cloudflare: แก้ปัญหาการทะลุ NAT

  • อินเทอร์เน็ตส่วนใหญ่อยู่หลังNAT (Network Address Translation) และหากอุปกรณ์ทั้งสองฝั่งอยู่หลัง NAT เมื่อเชื่อมต่อโดยตรงไม่สำเร็จก็มักต้องพึ่ง relay server
  • หากโครงสร้าง relay มี PoP (Point of Presence) จำกัด ทราฟฟิกจำนวนมากจะต้องผ่าน relay จนทำให้ความหน่วงเพิ่มขึ้นและความน่าเชื่อถือลดลง
  • Cloudflare Mesh จะส่งทราฟฟิกทั้งหมดผ่านเครือข่าย global ของ Cloudflare เพื่อมอบประสิทธิภาพที่สม่ำเสมอโดยไม่ต้องมี relay server แยกต่างหาก
  • สำหรับทราฟฟิกแบบข้ามรีเจียนและมัลติคลาวด์ ให้ประสิทธิภาพดีกว่าการเราต์ผ่าน public internet อย่างต่อเนื่อง

สิ่งที่มีให้หลัก ๆ

  • ฟรี 50 โหนดและผู้ใช้ 50 คน: รวมอยู่ในทุกบัญชี Cloudflare
  • global edge routing: มากกว่า 330 เมือง, backbone routing ที่ปรับแต่งแล้ว, ไม่มีเส้นทาง fallback ที่ทำให้ประสิทธิภาพลดลง
  • ควบคุมความปลอดภัยได้ตั้งแต่วันแรก: เปิดใช้ได้บนแพลตฟอร์มเดียวทั้งนโยบาย Gateway, DNS filtering, DLP, traffic inspection และการตรวจสอบ device posture โดยแต่ละฟีเจอร์เปิดหรือปิดได้ด้วยการสลับเพียงครั้งเดียว
  • ความพร้อมใช้งานสูง (HA): รันคอนเน็กเตอร์หลายตัวด้วยโทเค็นเดียวกันในโหมด active-passive และประกาศเส้นทาง IP เดียวกัน เพื่อให้เกิดการ failover อัตโนมัติเมื่อมีปัญหา

การรวมเข้ากับ Workers VPC

  • ขยาย Workers VPC เพื่อให้เข้าถึงทั้งเครือข่าย Mesh ได้จาก Workers และ Durable Objects
  • bind เครือข่าย Mesh ในไฟล์ wrangler.jsonc ด้วยคีย์เวิร์ดสงวน cf1:network:
    • "vpc_networks": [{ "binding": "MESH", "network_id": "cf1:network", "remote": true }]
  • ภายในโค้ด Worker สามารถเข้าถึงโฮสต์ส่วนตัวได้โดยตรงในรูปแบบ env.MESH.fetch("http://10.0.1.50/api/data";) โดยไม่ต้องลงทะเบียนล่วงหน้า
  • ใช้งานร่วมกับ VPC binding แบบ Tunnel ได้ ทำให้มีทางเลือกด้านรูปแบบความปลอดภัยของเครือข่ายมากขึ้น
  • ด้วยสิ่งนี้ จึงสร้างเอเจนต์ข้ามคลาวด์และ MCPที่เข้าถึง private database, internal API และ MCP ได้อย่างปลอดภัย

องค์ประกอบของสถาปัตยกรรมทั้งหมด

  • Mesh node: รัน Cloudflare One Client เวอร์ชัน headless บนเซิร์ฟเวอร์, VM หรือคอนเทนเนอร์ และรับ Mesh IP เพื่อให้เกิดการสื่อสารผ่าน private IP แบบสองทิศทางระหว่างบริการ
  • อุปกรณ์: รัน Cloudflare One Client บนโน้ตบุ๊กหรือโทรศัพท์เพื่อเข้าถึง Mesh node ได้โดยตรง — ทั้ง SSH, การคิวรีฐานข้อมูล และการเรียก API จะทำผ่าน private IP
  • Workers agent: เข้าถึงบริการส่วนตัวผ่าน Workers VPC Network binding โดยเครือข่ายจะควบคุมขอบเขตการเข้าถึงของเอเจนต์ และเซิร์ฟเวอร์ MCP จะควบคุมการกระทำของเอเจนต์

โรดแมปในอนาคต

  • การเราต์ด้วย hostname

    • ช่วงฤดูร้อนนี้มีแผนจะขยาย hostname routingของ Cloudflare Tunnel มาสู่ Mesh
    • สามารถเราต์ทราฟฟิกด้วย private hostname อย่าง wiki.local หรือ api.staging.internal ทำให้ไม่ต้องคอยจัดการรายการ IP
    • ลดความซับซ้อนของการเราต์ในสภาพแวดล้อมที่มี dynamic IP, auto scaling group และคอนเทนเนอร์ชั่วคราว

  • Mesh DNS

    • ในช่วงหลังของปีนี้ มีแผนจะกำหนดinternal hostname ที่เราต์ได้อัตโนมัติให้กับทุกโหนดและอุปกรณ์ที่เข้าร่วม Mesh
    • สามารถเข้าถึง postgres-staging.mesh ได้โดยไม่ต้องตั้งค่า DNS หรือเพิ่มเรคคอร์ดด้วยตนเอง
    • เมื่อนำไปใช้ร่วมกับ hostname routing จะทำให้เกิดการเข้าถึงโดยไม่ต้องใช้ IP address เช่น ssh postgres-staging.mesh หรือ curl http://api-prod.mesh:3000/health

  • การเราต์แบบรับรู้ตัวตน (Identity-aware Routing)

    • ปัจจุบัน Mesh node ใช้ID ที่ใช้ร่วมกันในระดับเครือข่าย ส่วนอุปกรณ์ตรวจสอบสิทธิ์ด้วย user ID แต่โหนดยังไม่มี routing ID แยกต่างหากที่ Gateway policy จะใช้แยกแยะได้
    • เป้าหมายคือมอบID เฉพาะให้กับแต่ละโหนด อุปกรณ์ และเอเจนต์ เพื่อให้เขียนนโยบายตามตัวตนของผู้เชื่อมต่อ แทนการอิงช่วง IP
    • แนวคิดของโมเดล agent ID:
      • Principal/Sponsor: บุคคลที่อนุมัติการกระทำ
      • Agent: ระบบ AI ที่ลงมือทำงานจริง (รวม session ID)
      • Scope: ขอบเขตงานที่เอเจนต์ได้รับอนุญาตให้ทำ
    • สิ่งนี้จะทำให้สร้างนโยบายแบบละเอียดได้ เช่น "อนุญาตให้อ่านผ่านเอเจนต์ แต่การเขียนอนุญาตเฉพาะมนุษย์โดยตรง"
    • โครงสร้างพื้นฐานมีอยู่แล้ว (โทเค็นต่อโหนด, ID ต่อผู้ใช้, VPC binding ต่อบริการ) โดยส่วนที่กำลังพัฒนาคือการมองเห็น ID ในชั้นนโยบาย

  • การรองรับคอนเทนเนอร์ของ Mesh

    • ปัจจุบัน Mesh node รันบน VM และเซิร์ฟเวอร์ Linux แบบ bare metal
    • กำลังเตรียมอิมเมจ Docker ของ Mesh สำหรับสภาพแวดล้อมคอนเทนเนอร์ เช่น Kubernetes pod, Docker Compose stack และ CI/CD runner
    • สามารถเพิ่ม Mesh sidecar เข้าไปใน Docker Compose stack เพื่อให้ทุกบริการในสแตกเข้าถึงเครือข่ายส่วนตัวได้
    • ใน CI/CD pipeline, GitHub Actions runner จะดึงอิมเมจคอนเทนเนอร์ของ Mesh เข้ามาเข้าร่วมเครือข่าย รันทดสอบแบบรวมกับสภาพแวดล้อม staging และลบโหนดอัตโนมัติเมื่อคอนเทนเนอร์สิ้นสุดการทำงาน
    • มีกำหนดให้ใช้งานในช่วงหลังของปีนี้

วิธีเริ่มต้น

  • Cloudflare Mesh: เริ่มได้ที่ Networking > Mesh ในแดชบอร์ด Cloudflare ฟรีสูงสุด 50 โหนดและผู้ใช้ 50 คน
  • Agents SDK + Workers VPC: ติดตั้งด้วย npm i agents แล้วดู Workers VPC quickstart และคู่มือ remote MCP server
  • ผู้ใช้ Cloudflare One เดิม: ใช้งานร่วมกับการตั้งค่าเดิมได้ และนโยบาย Gateway, การตรวจสอบ device posture และกฎ Access จะถูกใช้กับทราฟฟิก Mesh โดยอัตโนมัติ

บทความที่เกี่ยวข้อง

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

 
eoeoe 15 일 전

เดิมทีผมตั้งค่า tunnel ไว้ที่คอมที่บ้านแล้วใช้แค่ RDP มาตลอด... ดูท่าคงต้องลองเอเจนต์สักครั้งเหมือนกัน!
 
yangeok 16 일 전

ถ้าฟรีจริงและความปลอดภัยดี ก็ใช้แน่นอนครับ 555

พอเห็นอะไรแบบนี้ก็พอจะนึกภาพคร่าว ๆ ได้เลยว่า devops จะเปลี่ยนไปในทิศทางไหน
 
xguru 16 일 전

พอเห็นคำว่า mesh ตอนแรกก็นึกว่าคล้ายกับ Tailscale แต่ดูแล้วต่างกันนิดหน่อยนะครับ
มันไม่ได้เป็นแบบ P2P อย่าง Tailscale แต่เป็นโครงสร้างที่วิ่งผ่านเครือข่าย edge ของ CF เลย
ทำให้นโยบายความปลอดภัยอย่าง Gateway policy หรือ DLP ถูกบังคับใช้โดยอัตโนมัติ
และจุดที่ต่างคือใน Workers/Agents SDK สามารถเรียกใช้ private service ได้ด้วย fetch() แค่บรรทัดเดียว
ส่วนผมคงใช้ Tailscale ต่อไป..
 
minhoryang 15 일 전

ผมกลับรู้สึกว่าเมื่อ Cloudflare edge มาทำหน้าที่เป็น derp relay ของ tailscale มันอาจหมายถึงว่าคู่แข่งที่แข็งแกร่งกว่ากำลังปรากฏตัวขึ้นก็ได้ เพราะ Tailscale เองถ้า P2P ใช้ไม่ได้ ก็จะส่งการสื่อสารผ่าน derp relay อยู่แล้ว ส่วนประโยคที่ว่า “ถ้า PoP (Point of Presence) ของโครงสร้างพื้นฐานรีเลย์มีจำกัด ทราฟฟิกจำนวนมากก็จะต้องวิ่งผ่านรีเลย์ ทำให้เกิด latency และความน่าเชื่อถือลดลง” ตรงนี้ดูเหมือนกำลังพูดถึง tailscale โดยเฉพาะเลยครับ ผมน่าจะใช้ทั้งสองอย่างผสมกัน เดี๋ยวจะไปลองทันที
 
minhoryang 15 일 전

ดูเหมือนว่า Cloudflare edge ก็ใช้ช่วง IP ที่ขึ้นต้นด้วย 100.96.0.0/10 หรือกลุ่ม 100. เหมือนกันนะครับ ผมตั้งใจจะใช้ร่วมกับ Tailscale แต่มีจุดติดขัดเล็กๆ น้อยๆ ตั้งแต่การติดตั้งไปจนถึงการใช้งาน ใครที่กำลังจะใช้พร้อมกันแบบผมก็ขอให้เก็บไว้เป็นข้อมูลอ้างอิงครับ