ในที่สุดฉันก็เข้าใจ Cloudflare Zero Trust Tunnel

 (david.coffee)
2 คะแนน โดย GN⁺ 2025-11-17 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • อธิบายโครงสร้างการใช้ Cloudflare Zero Trust และ Warp เพื่อเชื่อมต่อเครือข่ายส่วนตัวและควบคุมการเข้าถึงบริการได้โดยไม่ติดปัญหา NAT·ไฟร์วอลล์
  • ผ่าน Argo Tunnel สามารถเปิดเผยเครือข่ายส่วนตัวหรือบริการโลคัลด้วยโดเมนสาธารณะ หรือสร้าง เครือข่ายส่วนตัว ที่เข้าถึงได้เฉพาะเมื่อเชื่อมต่อ Warp
  • Tailscale เร็วด้วยพื้นฐาน P2P แต่มีข้อจำกัดในสภาพแวดล้อม NAT ขณะที่ Cloudflare จะเราต์ทราฟฟิกทั้งหมดผ่าน เครือข่ายเอดจ์ เพื่อให้การเชื่อมต่อเสถียร
  • Cloudflared ทำหน้าที่สร้างท่อเชื่อมต่อ ส่วน Warp Client รับผิดชอบการเชื่อมต่อเครือข่ายและการบังคับใช้นโยบาย โดยใช้ Tunnels·Routes·Targets เพื่อจัดโครงสร้างการไหลของทราฟฟิกและการควบคุมการเข้าถึง
  • ตั้งค่า Access Policy แบบละเอียดด้วยการล็อกอินผ่านอีเมล·GitHub เป็นต้น เพื่อสร้าง สภาพแวดล้อมเครือข่ายที่ปลอดภัย ซึ่งสามารถข้ามขั้นตอนล็อกอินหรือจำกัดการเข้าถึงตามการเชื่อมต่อ Warp ได้

ภาพรวมของ Cloudflare Zero Trust และ Warp

  • เริ่มศึกษา Cloudflare Zero Trust + Warp เพราะ Tailscale ทะลุ NAT ไม่สำเร็จ
  • สามารถใช้ Zero Trust Tunnel เพื่อเชื่อมต่อเครือข่ายส่วนตัว เปิดเผยบริการ สร้างเครือข่าย IP ส่วนตัว และเปิดเผยบริการโลคัลแบบชั่วคราวได้หลากหลายรูปแบบ
  • ทราฟฟิกทั้งหมดจะถูกส่งผ่านเครือข่าย Cloudflare โดยไม่มีปัญหา NAT และสามารถควบคุมการเข้าถึงระหว่างผู้ใช้·บอต·เซิร์ฟเวอร์ได้ด้วย นโยบายการเข้าถึงแบบละเอียด
  • รองรับการล็อกอินผ่าน การยืนยันตัวตนแบบ Zero Trust สำหรับการเชื่อมต่อ SSH โดยไม่ต้องเปิดพอร์ตสาธารณะ

Cloudflare Zero Trust vs Tailscale

  • Tailscale จะพยายามเชื่อมต่อแบบ P2P โดยหลบเลี่ยง NAT·ไฟร์วอลล์ และหากทำไม่ได้จะใช้เซิร์ฟเวอร์รีเลย์
  • Cloudflare จะส่งทราฟฟิกทั้งหมด ยกเว้น Warp-to-Warp ผ่าน เซิร์ฟเวอร์เอดจ์ของ Cloudflare จึงไม่มีปัญหา NAT แต่มีความหน่วงเพิ่มขึ้นเล็กน้อย

ความแตกต่างระหว่าง Cloudflared และ Warp

  • Warp Client: เครื่องมือสำหรับเชื่อมต่อไคลเอนต์เข้ากับเครือข่าย Cloudflare และบังคับใช้นโยบาย
    • โดยหลักจะทำงานบนไคลเอนต์ และสามารถใช้บนเซิร์ฟเวอร์ได้เช่นกัน
    • รองรับการเชื่อมต่อแบบ P2P ผ่าน Warp-to-Warp routing
  • Cloudflared: เครื่องมือสำหรับสร้าง tunnel และเพิ่มเข้าไปในเครือข่าย Zero Trust
    • ทำงานบนเซิร์ฟเวอร์เพื่อเป็นจุดทางเข้าเครือข่าย
    • สามารถเชื่อมต่อไปยังทรัพยากร Zero Trust อื่น ๆ ได้ด้วยคำสั่ง cloudflared access
    • สามารถสร้าง tunnel แบบใช้ทดสอบครั้งเดียวได้

โครงสร้าง Tunnels, Routes, Targets

  • Tunnels: จุดออกของทราฟฟิกที่ถูกดีพลอยด้วย cloudflared
    • ตัวอย่าง: ติดตั้งบนอุปกรณ์ที่เปิดตลอดเวลาในเครือข่ายบ้าน (192.168.1.1/24)
    • ระบุปลายทางการเราต์เมื่อมีคำขอเข้ามาได้ในไฟล์ตั้งค่า (/etc/cloudflared/config.yml)
    • ตัวอย่าง: gitlab.widgetcorp.tech → localhost:80, gitlab-ssh → localhost:22
  • ตัวอย่างการเปิดเผยสู่สาธารณะ:
    • homeassistant.mydomain.com → เราต์ไปยัง 192.168.1.3
    • หากกำหนด CNAME ใน Cloudflare DNS ให้ชี้ไปยังที่อยู่ของ tunnel ก็จะเข้าถึงได้โดยไม่ต้องใช้ Warp
  • Routes: กำหนดว่าจะส่งช่วง IP ใดไปยัง tunnel ไหน
    • ตัวอย่าง: ระบุทั้ง 192.168.1.1/24 หรือ IP เดี่ยว 192.168.1.3/32
    • เมื่อเชื่อมต่อ Warp คำขอไปยัง IP นั้นจะถูกส่งผ่านเครือข่าย Cloudflare ไปยัง tunnel
    • สามารถเราต์ IP เสมือนที่ไม่มีอยู่จริงได้ด้วย (เช่น 10.128.1.1)
  • Targets: กำหนดหน่วยโครงสร้างพื้นฐานที่ต้องการปกป้อง
    • ตัวอย่าง: homeassistant.mydomain.com → 192.168.1.3/32
    • สามารถกำหนดนโยบายการเข้าถึงให้กับเป้าหมายเพื่อให้เฉพาะผู้ใช้บางคนเข้าถึงได้

Access Policies: การควบคุมการเข้าถึง

  • หลังจากตั้งค่า tunnel, route และ target แล้ว ให้กำหนดสิทธิ์การเข้าถึงด้วย Access Policy
  • องค์ประกอบของนโยบาย
    • Include: เงื่อนไขที่อนุญาตให้เข้าถึง (OR)
    • Require: เงื่อนไขที่ต้องเป็นจริงทั้งหมด (AND)
    • Action: Allow / Deny / Bypass / Service Auth
  • ตัวอย่าง 1 – ควบคุมการเข้าถึงด้วยอีเมล
    • อนุญาตให้เข้าถึงได้เฉพาะอีเมลที่กำหนด
    • สามารถจำกัดวิธีการยืนยันตัวตนเป็นการล็อกอินผ่าน GitHub ได้
  • ตัวอย่าง 2 – ข้ามการล็อกอินเมื่อเชื่อมต่อ Warp
    • ใช้ Gateway selector เพื่อข้ามหน้าจอล็อกอินเมื่อเชื่อมต่อ Zero Trust Warp
    • หากไม่ได้เชื่อมต่อ Warp จะบังคับให้ล็อกอินผ่าน GitHub

การดีพลอยและลงทะเบียน Warp Client

  • ตั้งค่านโยบายการลงทะเบียนใน Settings → Warp Client
    • อนุญาตการยืนยันตัวตนด้วย GitHub และจำกัดการลงทะเบียนให้เฉพาะอีเมลที่กำหนด
    • หากตั้งค่า WARP authentication ID จะสามารถใช้ Gateway selector ได้
  • กำหนดพฤติกรรมของไคลเอนต์ใน Profile Settings
    • ตั้งค่าโปรโตคอล (MASQUE/WireGuard), โหมดบริการ, IP ที่ยกเว้นจากการเราต์ เป็นต้น
    • สามารถติดตั้ง Cloudflare CA อัตโนมัติ กำหนด CGNAT IP เฉพาะ และตั้งค่าการตรวจสอบสถานะอุปกรณ์ (Device Posture) ได้
  • หลังล็อกอินเข้า Warp client แล้ว การเชื่อมต่อกับเครือข่าย Zero Trust จะเสร็จสมบูรณ์
    • จากนั้นคำขอไปยัง 192.168.1.3 จะถูกเราต์ผ่าน tunnel

สรุปผลการติดตั้งใช้งาน

  • ลงทะเบียน Warp client ด้วยนโยบายล็อกอินผ่าน GitHub และอีเมล
  • tunnel ภายในเครือข่ายส่วนตัวจะส่งคำขอ homeassistant.mydomain.com ไปยัง 192.168.1.3
  • ทราฟฟิกไปยัง 192.168.1.3 จะเข้าถึงผ่าน tunnel ได้เฉพาะเมื่อเชื่อมต่อ Warp
  • รองรับทั้งการเข้าถึงแบบสาธารณะผ่าน DNS และการเข้าถึงแบบส่วนตัวผ่าน Warp
  • เมื่อเชื่อมต่อ Warp จะข้ามการล็อกอินได้ และหากไม่เชื่อมต่อจะต้องยืนยันตัวตนผ่าน GitHub

หัวข้อที่ยังไม่ได้กล่าวถึงเพิ่มเติม

  • Warp-to-Warp routing
  • การสร้าง private IP สำหรับใช้งานภายใน Zero Trust เท่านั้น
  • การตั้งค่านโยบายยืนยันตัวตนสำหรับ SSH
  • ประเภทแอปพลิเคชันอื่นนอกเหนือจาก Self-Hosted

ไม่มีข้อมูลเพิ่มเติมในต้นฉบับ

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

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

 
GN⁺ 2025-11-17
ความคิดเห็นบน Hacker News

  • Cloudflare ทำงานเป็น จุดสิ้นสุด TLS จึงไม่ค่อยเหมาะกับการใช้งานส่วนตัว
    ถ้าใช้ Tailscale Funnel ใบรับรองจะถูกติดตั้งบนเอนด์พอยต์ของฉันโดยตรง แต่ Cloudflare จะถอดรหัสทราฟฟิกตรงกลางแล้วเข้ารหัสใหม่
    แม้จะไม่แน่ใจนักว่าระดับความเป็นส่วนตัวของเครือข่ายส่วนตัวใน WARP เป็นอย่างไร แต่คิดว่าการทำ internet tunneling แบบนี้ทำให้ ความเป็นส่วนตัวลดลง มาก
    อีกทั้งโครงสร้างแบบ การเชื่อมต่อ P2P + relay fallback ยังทำงานได้โดยไม่ต้องพึ่งตัวกลางบุคคลที่สาม จึงมองว่าน่าพึงประสงค์กว่ามาก

    • ไม่นานมานี้ฉันทำโปรเจกต์ชื่อ TunnelBuddy ขึ้นมาเอง
      เป็นโครงสร้างที่ใช้เครื่องของเพื่อนเป็น WebRTC-based exit node และรองรับเฉพาะ P2P โดยไม่มีเซิร์ฟเวอร์ TURN/relay
      อัตราความสำเร็จในการเชื่อมต่ออาจต่ำตามสภาพแวดล้อม NAT แต่ทราฟฟิกไม่ผ่านเซิร์ฟเวอร์ของบุคคลที่สาม จึง รับประกันความเป็นส่วนตัว ได้ชัดเจน
    • น่าขันตรงที่บอกว่าเป็น “Zero Trust” แต่สุดท้ายก็เป็นโครงสร้างที่ต้อง เชื่อใจ Cloudflare แบบเต็มที่
    • ส่วนตัวฉันเชื่อใจ Tailscale มากกว่า แต่ความสามารถด้าน custom domain และ การเข้าถึงโดยไม่ต้องมีไคลเอนต์ ของ Cloudflare ก็น่าสนใจ
      จะจัดแบบคล้ายกันด้วย Caddy ก็ได้ แต่ก็ยังต้องทำ port forwarding อยู่ดี
    • NetFoundry ใน ลิสต์ awesome-tunneling ก็เป็นทางเลือกที่ดี
      จุดเด่นคือมี end-to-end encryption และได้ทั้ง ประสิทธิภาพ·ความน่าเชื่อถือ จาก PoP มากกว่า 100 แห่ง
    • connet ตั้งเป้าไปที่โครงสร้างแบบ P2P + relay fallback
      เปิดเผยเอนด์พอยต์เฉพาะกับ peer ที่เข้าร่วม จึงได้เปรียบในด้านความปลอดภัยและความเป็นส่วนตัว
      สามารถโฮสต์เองหรือใช้ บริการทางการ ก็ได้

  • ฉันใช้ Netbird ที่บ้านและสำหรับงานส่วนตัว
    ติดตั้งไว้บน Synology NAS รวมถึงโน้ตบุ๊ก เดสก์ท็อป และมือถือทั้งหมดของครอบครัว และสะดวกมากสำหรับใช้งานคล้ายรีโมตเดสก์ท็อปใน สภาพแวดล้อม Tmux

  • ฉันหยุดอ่านตั้งแต่เจอประโยคที่ว่า “ทราฟฟิกทั้งหมดจะผ่านเครือข่ายของ Cloudflare”
    Hyprspace เจาะผ่าน NAT ทุกแบบที่ฉันเคยเจอมาได้ และทำงานได้ดี โดยไม่ต้องพึ่งโครงสร้างพื้นฐานของบริษัทยักษ์ใหญ่

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

  • ฉันอ่านบทความที่เล่าว่าผู้เขียนไปเรียนรู้ Cloudflare Zero Trust + Warp เพราะหงุดหงิดที่ Tailscale จับการเชื่อมต่อ P2P ไม่ได้ในบางสภาพแวดล้อม NAT
    แต่ Cloudflare เองก็ไม่ได้พยายามทำ P2P ตั้งแต่แรก และสุดท้ายก็เหมือนย้ายไปใช้ trust model ของ Cloudflare แทน
    เลยเข้าใจแรงจูงใจได้ยาก แต่ตัวบทความเองก็สรุปได้ดี

    • Cloudflare มี เครือข่าย PoP คุณภาพสูง อยู่ทั่วโลก ดังนั้นในทางปฏิบัติคุณภาพกลับดีกว่า P2P ด้วยซ้ำ
      บริษัทของเราก็ทำงานรีโมตเต็มรูปแบบ และหลังย้ายจาก Tailscale มา Cloudflare ประสิทธิภาพก็ดีขึ้น
    • ประเด็นสำคัญคือเมื่อวิ่งผ่าน Cloudflare แล้วยังมีการเข้ารหัสระหว่าง peer อยู่หรือไม่
      ถ้ายังอยู่ ความต่างของ trust model ก็อาจไม่มากนัก แต่ Cloudflare เด่นเรื่อง ประสิทธิภาพของ relay จึงได้เปรียบด้านความเร็ว
      ถึงอย่างนั้นความสามารถด้าน NAT hole punching ของ Tailscale ก็ยอดเยี่ยมมาก จึงยังชอบการเชื่อมต่อตรงถ้าทำได้

  • ฉันใช้ tuns.sh สำหรับเปิดให้เข้าถึงบริการส่วนตัว
    เพราะมันอิงกับ SSH tunnel จึงชอบตรงที่ ใช้งานได้ทันทีโดยไม่ต้องติดตั้ง

  • ทั้งบทความและคอมเมนต์มีประโยชน์มาก
    แต่รูปในบทความหลักเสียและขึ้น 404 — เช่น targets-config-screen.png

  • ดีใจที่ในที่สุดก็มีเสียงวิจารณ์ประเด็น ปัญหาระดับโครงสร้างของ CF ออกมาบ้าง
    คิดว่าจำเป็นต้องมีการถกเถียงที่ชี้ให้เห็นปัญหาของโมเดล Zero Trust

  • ข้อเสียร้ายแรงคือบัญชี Cloudflare แบบฟรีใช้เปิด เซิร์ฟเวอร์ Plex ไม่ได้
    ดูข้อกำหนดที่เกี่ยวข้องได้ที่ นี่

    • ผู้ให้บริการอินเทอร์เน็ตของคุณมี IPv6 ให้หรือเปล่า?
      ฉันใช้ Emby กับ Jellyfin ผ่าน IPv6 กับเพื่อน ๆ ได้ดีมาก
    • จะมีใครคาดหวังให้มีคนให้ ทราฟฟิกวิดีโอสตรีมมิง ฟรีจริงหรือ?
      ต่างจากเว็บทราฟฟิกทั่วไป เพราะหนังเรื่องเดียวก็มีต้นทุนแบนด์วิดท์สูงกว่าหลายร้อยเท่า
    • ในบัญชีฟรีของฉัน cloudflared tunnel ใช้กับ Jellyfin ได้ดี
      วิธีนี้มีประโยชน์เพราะโน้ตบุ๊กทำงานของแฟนฉันติดตั้ง Tailscale ไม่ได้
    • ในความเป็นจริง ถ้าทราฟฟิกไม่ได้มาก ข้อกำหนดก็มักไม่ได้ถูกบังคับใช้อย่างเข้มงวด
    • ฉันก็ใช้กับ Jellyfin อยู่ และผ่านมาหลายเดือนแล้วก็ยังทำงานได้ดีไม่มีปัญหา

  • มีคำถามว่า การใช้ Cloudflare แบบนี้ไม่ถือเป็น vendor lock-in หรือ?
    อย่างน้อยฉันคิดว่า Tailscale ไม่มีการผูกติดแบบนั้น

    • แต่ฉันก็แปลกใจเมื่อรู้ว่า Tailscale เองสุดท้ายก็เป็น commercial vendor เหมือนกัน
      เคยนึกว่าเป็นโอเพนซอร์สโปรเจกต์เสียอีก แต่ไม่ใช่