Cuối cùng tôi cũng đã hiểu Cloudflare Zero Trust Tunnel

 (david.coffee)
2 điểm bởi GN⁺ 2025-11-17 | 1 bình luận | Chia sẻ qua WhatsApp
  • Giải thích kiến trúc sử dụng Cloudflare Zero Trust và Warp để kết nối mạng riêng và kiểm soát truy cập dịch vụ mà không gặp vấn đề NAT hay tường lửa
  • Thông qua Argo Tunnel, có thể công khai mạng riêng hoặc dịch vụ cục bộ bằng miền công cộng, hoặc xây dựng mạng riêng tư chỉ truy cập được khi kết nối Warp
  • Tailscale nhanh nhờ nền tảng P2P, nhưng bị hạn chế trong môi trường NAT; còn Cloudflare định tuyến toàn bộ lưu lượng qua mạng edge để cung cấp kết nối ổn định
  • Cloudflared phụ trách tạo tunnel, còn Warp Client phụ trách kết nối mạng và áp dụng chính sách; luồng lưu lượng và kiểm soát truy cập được cấu hình bằng Tunnels·Routes·Targets
  • Có thể thiết lập Access Policy chi tiết bằng đăng nhập email hoặc GitHub để xây dựng môi trường mạng bảo mật, trong đó có thể bỏ qua hoặc giới hạn quy trình đăng nhập tùy theo việc có kết nối Warp hay không

Tổng quan về Cloudflare Zero Trust và Warp

  • Bắt đầu tìm hiểu Cloudflare Zero Trust + Warp do Tailscale thất bại trong việc xuyên NAT
  • Có thể dùng Zero Trust tunnel cho nhiều mục đích như kết nối mạng riêng, công khai dịch vụ, cấu hình mạng IP riêng, hoặc công khai tạm thời dịch vụ cục bộ
  • Mọi lưu lượng đều được chuyển qua mạng Cloudflare mà không gặp vấn đề NAT, đồng thời có thể kiểm soát truy cập giữa người dùng, bot và máy chủ bằng chính sách truy cập chi tiết
  • Khi kết nối SSH, hỗ trợ đăng nhập dựa trên xác thực Zero Trust mà không cần mở cổng công khai

Cloudflare Zero Trust vs Tailscale

  • Tailscale cố gắng thiết lập kết nối P2P bằng cách vượt qua NAT và tường lửa, nếu không thể thì dùng máy chủ relay
  • Cloudflare chuyển mọi lưu lượng, ngoại trừ Warp-to-Warp, qua máy chủ edge của Cloudflare, nên không có vấn đề NAT nhưng có thêm một chút độ trễ

Khác biệt giữa Cloudflared và Warp

  • Warp Client: công cụ kết nối client vào mạng Cloudflare và áp dụng chính sách
    • Chủ yếu chạy trên client, nhưng cũng có thể dùng trên server
    • Hỗ trợ kết nối P2P bằng định tuyến Warp-to-Warp
  • Cloudflared: công cụ tạo tunnel để thêm vào mạng Zero Trust
    • Chạy trên server để cung cấp điểm vào cho mạng
    • Có thể kết nối tới các tài nguyên Zero Trust khác bằng lệnh cloudflared access
    • Có thể tạo tunnel dùng thử một lần

Cấu trúc Tunnels, Routes, Targets

  • Tunnels: điểm thoát lưu lượng được triển khai bằng cloudflared
    • Ví dụ: cài trên thiết bị luôn bật trong mạng gia đình (192.168.1.1/24)
    • Trong tệp cấu hình (/etc/cloudflared/config.yml), chỉ định đích định tuyến khi có yêu cầu đến
    • Ví dụ: gitlab.widgetcorp.tech → localhost:80, gitlab-ssh → localhost:22
  • Ví dụ công khai dịch vụ:
    • homeassistant.mydomain.com → định tuyến tới 192.168.1.3
    • Nếu đặt CNAME trong Cloudflare DNS trỏ tới địa chỉ tunnel, có thể truy cập mà không cần Warp
  • Routes: định nghĩa tunnel nào sẽ nhận một dải IP cụ thể
    • Ví dụ: chỉ định toàn bộ 192.168.1.1/24 hoặc một IP đơn 192.168.1.3/32
    • Khi kết nối Warp, các yêu cầu tới IP đó sẽ được chuyển qua mạng Cloudflare tới tunnel
    • Cũng có thể định tuyến tới IP ảo không tồn tại, ví dụ 10.128.1.1
  • Targets: định nghĩa đơn vị hạ tầng cần được bảo vệ
    • Ví dụ: homeassistant.mydomain.com → 192.168.1.3/32
    • Có thể gán chính sách truy cập cho đích để chỉ cho phép người dùng cụ thể truy cập

Access Policies: kiểm soát truy cập

  • Sau khi cấu hình tunnel, route và target, thiết lập quyền truy cập bằng Access Policy
  • Thành phần chính sách
    • Include: điều kiện cho phép truy cập (OR)
    • Require: điều kiện bắt buộc phải thỏa mãn (AND)
    • Action: Allow / Deny / Bypass / Service Auth
  • Ví dụ 1 – kiểm soát truy cập theo email
    • Chỉ cho phép truy cập với địa chỉ email cụ thể
    • Cũng có thể giới hạn xác thực bằng hình thức đăng nhập GitHub
  • Ví dụ 2 – bỏ qua đăng nhập khi đã kết nối Warp
    • Dùng Gateway selector để bỏ qua màn hình đăng nhập khi đã kết nối Zero Trust Warp
    • Nếu chưa kết nối Warp thì yêu cầu đăng nhập GitHub

Triển khai và đăng ký Warp client

  • Cấu hình chính sách đăng ký trong Settings → Warp Client
    • Cho phép xác thực GitHub và chỉ một số email nhất định được đăng ký
    • Nếu đặt WARP authentication ID thì có thể dùng Gateway selector
  • Định nghĩa hành vi client trong Profile Settings
    • Có thể cấu hình giao thức (MASQUE/WireGuard), service mode, các IP bị loại trừ khỏi định tuyến, v.v.
    • Có thể tự động cài Cloudflare CA, gán CGNAT IP riêng, và thiết lập kiểm tra trạng thái thiết bị (Device Posture)
  • Sau khi đăng nhập Warp client, việc kết nối vào mạng Zero Trust hoàn tất
    • Sau đó, yêu cầu tới 192.168.1.3 sẽ được định tuyến qua tunnel

Tóm tắt kết quả triển khai

  • Đăng ký Warp client bằng chính sách đăng nhập dựa trên GitHub và email
  • Tunnel trong mạng riêng chuyển yêu cầu homeassistant.mydomain.com tới 192.168.1.3
  • Lưu lượng tới 192.168.1.3 chỉ có thể truy cập qua tunnel khi đã kết nối Warp
  • Cung cấp cả hai cách: truy cập công khai dựa trên DNS và truy cập riêng tư dựa trên Warp
  • Khi có kết nối Warp thì bỏ qua đăng nhập, nếu không thì yêu cầu xác thực GitHub

Các mục chưa đề cập thêm

  • Định tuyến Warp-to-Warp
  • Tạo IP riêng chỉ dùng nội bộ trong Zero Trust
  • Cấu hình chính sách xác thực SSH
  • Các loại ứng dụng khác ngoài Self-Hosted

Không có thêm thông tin trong bài gốc

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-11-17
Ý kiến trên Hacker News

  • Cloudflare hoạt động như một điểm kết thúc TLS, nên bất lợi cho nhu cầu cá nhân
    Nếu dùng Tailscale Funnel thì chứng chỉ được cài trực tiếp trên endpoint của tôi, còn Cloudflare sẽ giải mã lưu lượng ở giữa rồi mã hóa lại
    Tôi không rõ mức độ riêng tư mạng cá nhân của WARP ra sao, nhưng khi tunnel Internet thì tôi nghĩ mức suy giảm quyền riêng tư là khá lớn
    Ngoài ra, mô hình kết nối P2P + relay dự phòng có thể hoạt động mà không cần trung chuyển qua bên thứ ba, nên tôi thấy đáng mong muốn hơn nhiều

    • Gần đây tôi đã tự làm một dự án tên là TunnelBuddy
      Nó có cấu trúc dùng máy của bạn bè làm exit node dựa trên WebRTC, và chỉ hỗ trợ P2P, không có máy chủ TURN/relay
      Tỷ lệ kết nối thành công thấp tùy theo môi trường NAT, nhưng lưu lượng không đi qua máy chủ bên thứ ba nên đảm bảo quyền riêng tư rõ ràng
    • Thật mỉa mai khi gọi là “Zero Trust” nhưng rốt cuộc lại phải tin tưởng hoàn toàn vào Cloudflare
    • Cá nhân tôi tin Tailscale hơn, nhưng các tính năng custom domain và truy cập không cần client của Cloudflare khá hấp dẫn
      Cũng có thể dựng tương tự bằng Caddy, nhưng vẫn cần port forwarding
    • NetFoundry trong danh sách awesome-tunneling cũng là một lựa chọn thay thế tốt
      Ưu điểm là mã hóa đầu cuối và hiệu năng, độ tin cậy nhờ hơn 100 PoP
    • connet hướng tới mô hình P2P + relay dự phòng
      Chỉ các peer tham gia mới lộ endpoint nên có lợi về bảo mật và quyền riêng tư
      Bạn có thể tự host hoặc dùng dịch vụ chính thức

  • Tôi đang dùng Netbird ở nhà và cho mục đích cá nhân
    Tôi đã cài nó trên Synology NAS, tất cả laptop, desktop và điện thoại của gia đình, và rất tiện để dùng như desktop từ xa trong môi trường Tmux

  • Tôi đã ngừng đọc ngay ở câu “mọi lưu lượng đều đi qua mạng Cloudflare”
    Hyprspace đã xuyên qua mọi NAT mà tôi từng gặp, và hoạt động tốt không cần hạ tầng của tập đoàn lớn

  • Bài viết này thực sự giống một hướng dẫn cấu hình rất xuất sắc
    Cloudflare nên tài liệu hóa nó và dùng làm hướng dẫn chính thức cũng được

  • Tôi đã đọc bài viết nói rằng vì quá bực khi Tailscale không thể thiết lập kết nối P2P trong môi trường NAT nên tác giả đi tìm hiểu Cloudflare Zero Trust + Warp
    Nhưng Cloudflare vốn dĩ còn chẳng thử P2P, nên rốt cuộc chỉ là chuyển sang mô hình tin cậy của Cloudflare
    Khó hiểu được động cơ, nhưng bản thân bài viết thì được sắp xếp rất tốt

    • Cloudflare có mạng PoP chất lượng cao trên toàn thế giới, nên trên thực tế chất lượng còn tốt hơn cả P2P
      Công ty chúng tôi cũng làm việc từ xa hoàn toàn, và sau khi chuyển từ Tailscale sang Cloudflare thì hiệu năng đã cải thiện
    • Điểm mấu chốt là liệu khi đi qua Cloudflare thì mã hóa giữa các peer có còn được giữ nguyên không
      Nếu có thì khác biệt về mô hình tin cậy không quá lớn, nhưng Cloudflare mạnh về hiệu năng relay nên có lợi về tốc độ
      Dù vậy, khả năng NAT hole punching của Tailscale vẫn rất tốt nên nếu có thể tôi vẫn thích kết nối trực tiếp hơn

  • Tôi đang dùng tuns.sh để phơi bày các dịch vụ cá nhân
    Tôi thích điểm nó dựa trên SSH tunnel nên dùng ngay không cần cài đặt

  • Cả bài viết lẫn phần bình luận đều rất hữu ích
    Tuy nhiên ảnh trong bài bị lỗi và trả về 404 — ví dụ: targets-config-screen.png

  • Tôi mừng vì cuối cùng cũng có người chỉ trích vấn đề cốt lõi của CF
    Tôi nghĩ cần có thêm các cuộc thảo luận chỉ ra vấn đề của mô hình Zero Trust

  • Việc không thể chạy máy chủ Plex bằng tài khoản Cloudflare miễn phí là một điểm trừ chí mạng
    Có thể xem điều khoản liên quan ở đây

    • ISP của bạn có cấp IPv6 không?
      Tôi đang dùng Emby và Jellyfin qua IPv6 với bạn bè rất ổn
    • Ai lại mong được cung cấp miễn phí lưu lượng streaming video chứ?
      Khác với lưu lượng web đơn thuần, chỉ một bộ phim thôi cũng tạo ra chi phí băng thông cao gấp hàng trăm lần
    • Với tài khoản miễn phí của tôi, cloudflared tunnel chạy Jellyfin rất ổn
      Laptop công việc của bạn gái tôi không cài được Tailscale nên cách này rất hữu ích
    • Thực tế là nếu lưu lượng không nhiều thì điều khoản không bị áp dụng quá nghiêm ngặt
    • Tôi cũng dùng cho Jellyfin và đã chạy ổn vài tháng nay không có vấn đề gì

  • Tôi có thắc mắc liệu dùng Cloudflare có phải là vendor lock-in hay không
    Ít nhất thì tôi nghĩ Tailscale không có kiểu phụ thuộc đó

    • Nhưng rồi tôi đã ngạc nhiên khi biết Tailscale rốt cuộc cũng là một vendor thương mại
      Tôi cứ tưởng đó là một dự án mã nguồn mở, nhưng hóa ra không phải