WARP client và device enrollment flow

TL;DR

WARP client (chính thức “Cloudflare One Client”) là agent chạy trên thiết bị người dùng, đưa lưu lượng lên Cloudflare edge qua WireGuard hoặc MASQUE tunnel. Nó làm 3 việc:

1. Chặn bắt lưu lượng của thiết bị qua TUN interface, định tuyến theo split tunnel rules.
2. Thu thập tín hiệu posture (mã hóa ổ đĩa, EDR, phiên bản OS, MDM) gửi lên Cloudflare.
3. Gắn thiết bị với user identity (qua IdP login khi enroll), cho Access/Gateway policy tận dụng.

Bài này đi qua:

• Kiến trúc daemon + luồng enrollment.
• Device posture checkers: built-in vs bên thứ ba (CrowdStrike, Intune, SentinelOne, Kolide).
• Split tunnel 2 chế độ (include vs exclude): triết lý và khi nào chọn.
• Đường phân giải DNS với Local Domain Fallback.
• Tuỳ chọn triển khai: thủ công / MDM / GPO.
• Truy nguyên 6 trường hợp phổ biến (không kết nối được, posture fail, xung đột split tunnel, DNS không phân giải được hostname nội bộ, duyệt web chậm, hao pin).

Luận điểm chính:

WARP là “mắt và tay” của Zero Trust ở endpoint. Không có WARP đúng, mọi policy Access/Gateway viết cho thiết bị được quản lý đều là mong tưởng, CF không có cách nào biết device posture hoặc định tuyến lưu lượng ZTNA.

Bài này là Part 9 của Cloudflare One Handbook.

---

Dành cho ai

• Nhóm IT/Endpoint chuẩn bị triển khai WARP cho fleet laptop/mobile.
• Kỹ sư bảo mật thiết kế device posture policy (Part 4).
• Nhóm platform truy nguyên “người dùng không vào được ứng dụng nội bộ”.

Bạn nên đã đọc:

• Part 8, Cloudflare Tunnel (phía server, WARP là phía client).
• Part 4, Access (policy require device_posture).

Sau bài này bạn sẽ:

• Hiểu WARP hoạt động thế nào ở OS level.
• Enroll thiết bị với xác thực IdP.
• Cấu hình posture rules: chọn có sẵn hay tích hợp bên thứ ba (SP).
• Viết split tunnel rules đúng chế độ cho nhóm.
• Truy nguyên 6 trường hợp phổ biến nhất.

---

Bài này không nói về gì

• WARP Connector (đưa phân đoạn mạng vào Cloudflare thay vì từng thiết bị riêng): trường hợp sử dụng khác, bài riêng.
• 1.1.1.1 consumer WARP: tên giống nhưng là ứng dụng khác, dùng cá nhân, không liên quan doanh nghiệp.
• Browser-based Access (không cần WARP): đã đề cập ở Part 4.
• Zero Trust DNS policy deep-dive: Part 11.

---

Khái niệm

• WARP client: ứng dụng cài trên Windows, macOS, Linux, iOS, Android. Bản doanh nghiệp thay vì bản cá nhân 1.1.1.1.
• Team name: subdomain <team>.cloudflareaccess.com, định danh tổ chức cho WARP. Người dùng điền khi enroll.
• Enrollment: quy trình gắn thiết bị với tổ chức Cloudflare (team name + xác thực IdP).
• Device posture: tín hiệu thu được từ WARP về trạng thái thiết bị.
• Posture checker: rule định nghĩa kiểm tra cụ thể (ví dụ “disk encrypted”). Có sẵn hoặc tích hợp bên thứ ba.
• Split tunnel: chế độ định nghĩa lưu lượng nào qua WARP, lưu lượng nào không.
• Local Domain Fallback (LDF): rule cho phép DNS query domain nhất định phân giải qua DNS nội bộ thay vì Cloudflare.
• MASQUE: giao thức mới (dựa trên HTTP/3) thay thế WireGuard cho một số trường hợp, hoạt động trên mạng hạn chế UDP.

---

Kiến trúc WARP

Ở phía thiết bị

• Ứng dụng (trình duyệt, SSH, Slack, v.v.) không biết gì về WARP. Chúng dùng network stack của hệ thống.
• WARP daemon chạy như dịch vụ (warp-svc trên Windows/Linux, CloudflareWARP trên macOS). Tạo TUN interface ảo và cấu hình bảng định tuyến để chặn bắt lưu lượng.
• Posture collector chạy kiểm tra định kỳ (mỗi 1-5 phút), báo cáo lên Cloudflare.
• Công cụ split tunnel quyết định gói nào vào tunnel, gói nào đi trực tiếp.

Ở phía CF edge

• WireGuard endpoint (UDP 2408) hoặc MASQUE endpoint (HTTPS TLS) kết thúc tunnel.
• Validator ánh xạ chứng chỉ thiết bị, user identity, phạm vi policy.
• Gateway / Access áp dụng policy. Nếu đích đến là nội bộ, định tuyến qua Tunnel (Part 8).

Giao thức: WireGuard vs MASQUE

WireGuard là giao thức mặc định. Ưu:

• Nhanh, chi phí phụ thấp.
• Đã được kiểm chứng ở quy mô lớn (WARP cá nhân 1.1.1.1 dùng WireGuard mặc định).

Nhược: UDP 2408. Một số mạng công ty/khách sạn/sân bay chặn UDP, fail.

MASQUE là phương án dự phòng dựa trên HTTP/3 (TCP 443 TLS). Dùng khi:

• Firewall chặn WireGuard UDP.
• Mạng chỉ cho outbound HTTPS (kiểu doanh nghiệp hạn chế).

WARP client tự động dự phòng: thử WireGuard trước, MASQUE sau. Người dùng không cần cấu hình.

---

Luồng enrollment

6 bước end-to-end

① Cài WARP client, thủ công hoặc qua MDM (chi tiết ở mục “Triển khai”).

② Đăng ký team name, người dùng nhập <team> vào WARP UI. Hoặc MDM đẩy cấu hình có sẵn team name. WARP daemon gọi Cloudflare enrollment API với device fingerprint (hardware ID, OS info).

③ CF redirect về IdP, người dùng được redirect trình duyệt đến trang login IdP (Okta/Entra/Google). Trường hợp one-time PIN, người dùng nhập email và nhận PIN qua mail.

④ IdP trả claims, sau khi đăng nhập, IdP redirect về CF callback với user identity + group claims.

⑤ Binding + token, CF gắn chứng chỉ thiết bị với user identity, trả device identity token về WARP daemon.

⑥ Kích hoạt, WARP daemon tạo TUN interface, áp dụng split tunnel rules, cấu hình DNS. Trạng thái WARP = Connected.

Policy kiểm soát ai được enroll

Trước khi cho phép enrollment, CF check Device enrollment permissions (Zero Trust → Settings → WARP Client → Device enrollment permissions). Rule tương tự Access policy:

include:
  - emails_ending_in: "@example.com"
  - groups: [Engineering, Platform, Admin]
require:
  - mfa_method: [FIDO2, TOTP]
exclude:
  - country: [KP, RU]

Nếu người dùng không match rule, enrollment bị từ chối.

---

Device posture: built-in vs tích hợp bên thứ ba

Checker built-in

WARP trực tiếp thu tín hiệu từ OS:

Check	Windows	macOS	Linux
Disk encryption	BitLocker	FileVault	LUKS
Firewall status	Windows Defender	Firewall tích hợp sẵn	ufw/firewalld
OS version	WMI	system_profiler	/etc/os-release
Domain joined	AD domain	Active Directory Mobility	n/a
Client certificate	Certificate Store	Keychain	PEM file

Tính năng có sẵn đủ cho phần lớn trường hợp cơ bản (thiết bị được công ty cấp, OS đã cập nhật, đĩa đã mã hóa). Các tổ chức đã có EDR/MDM thường cần thêm lớp tích hợp bên thứ ba dưới đây.

Tích hợp bên thứ ba (EDR / MDM)

Khi tổ chức đã đầu tư vào EDR/MDM:

• CrowdStrike Falcon: ZTA score (0-100), device trust level từ Falcon console.
• SentinelOne: agent health, tamper-proof status.
• Microsoft Intune: trạng thái MDM compliance từ Entra.
• Kolide: policy-as-code, custom check thân thiện với developer.
• Jamf (macOS), Tanium, Workspace ONE: cũng được hỗ trợ.

Thiết lập: Zero Trust → Settings → WARP Client → Device posture providers, kết nối tài khoản nhà cung cấp với API key.

Khi nào chọn gì

• Startup / nhóm < 100: tính năng có sẵn đủ. Không tốn thêm nhà cung cấp.
• Doanh nghiệp có EDR: tích hợp nhà cung cấp cho góc nhìn tập trung. Nhóm bảo mật đã dùng dashboard EDR.
• Nặng về tuân thủ: tích hợp Intune nếu đã MDM qua Entra (giảm kiểm toán trùng lặp).

Tần suất posture check

• Có sẵn: mỗi 1 phút (cấu hình được).
• Tích hợp nhà cung cấp: phụ thuộc API của họ: CrowdStrike ~5 phút, Intune ~15-30 phút.

Đánh giá policy dùng snapshot gần nhất. Cache trong daemon, không phải thời gian thực.

---

Split tunnel: 2 chế độ

Chế độ Include

Mặc định: lưu lượng đi trực tiếp (không qua WARP). Chỉ đích đến khớp rule sẽ qua WARP.

Include list:
  - 10.0.0.0/8         # private network
  - 172.16.0.0/12
  - gitlab.internal    # specific hostname
  - *.corp.example.com

Triết lý: “WARP là công cụ cho ZTNA, không phải VPN toàn bộ lưu lượng”. Dùng khi:

• Nhóm ngại chặn lưu lượng internet của người dùng.
• Chỉ cần truy cập mạng nội bộ.
• Tránh độ trễ cho lưu lượng không cần chính sách bảo mật (Zoom, Google Drive).

Chế độ Exclude

Mặc định: tất cả lưu lượng qua WARP. Chỉ đích đến khớp rule sẽ bỏ qua.

Exclude list:
  - 192.168.0.0/16     # home LAN
  - apple.com           # macOS updates
  - zoom.us             # video call

Triết lý: “WARP là SWG cho toàn bộ internet”. Dùng khi:

• Tuân thủ yêu cầu khả năng quan sát đầy đủ (HIPAA, PCI).
• DLP / category filter đầy đủ cho mọi lưu lượng.
• Chấp nhận độ trễ tăng thêm.

Quyết định

Trong thực tế, chế độ exclude là lựa chọn cho tổ chức nặng về bảo mật; chế độ include cho tổ chức nặng về developer.

Bắt đầu bằng chế độ include (ít xáo trộn), chuyển sang exclude khi nhóm sẵn sàng cho SWG.

Ngoại lệ cho máy nội bộ

Cần danh sách cho phép:

• DHCP / ARP (tự động)
• mDNS (Bonjour, phát hiện máy in)
• Printer IP của mạng nhà (nếu người dùng in từ nhà)
• Captive portal (wifi sân bay/khách sạn)

WARP client mặc định loại trừ các giao thức này trong chế độ include. Cấu hình thủ công nếu ở chế độ exclude.

---

Phân giải DNS

DNS là cạm bẫy lớn nhất khi thiết lập WARP. Lý do: công ty có DNS zone nội bộ không định tuyến qua CF được.

2 đường khả thi

Đường 1, Cloudflare Gateway DNS (mặc định cho mọi query).

• Query đi về CF Gateway resolver.
• Áp dụng DNS policy (chặn category malware, log).
• Phân giải đệ quy.

Đường 2, Local Domain Fallback (LDF).

• Query khớp rule *.corp.example.com → bỏ qua Gateway.
• Query thẳng về DNS nội bộ (từ DHCP hoặc cấu hình thủ công).
• Dùng cho zone nội bộ mà chỉ DNS nội bộ biết (Route 53 private zone, AD DNS, DNS công ty).

Thiết lập LDF

Zero Trust → Settings → WARP Client → Local Domain Fallback → Add:

• corp.example.com (toàn bộ zone nội bộ)
• 10.in-addr.arpa (reverse DNS cho dải IP nội bộ)

Không có LDF, người dùng không phân giải được gitlab.corp.example.com ↦ request fail ở bước DNS, trước cả Access/Tunnel.

Split-horizon DNS

Công ty thường split horizon: app.example.com phân giải công khai ra public IP, nội bộ phân giải ra private IP. Với WARP + LDF:

• LDF rule example.com, DNS nội bộ thấy private IP, WARP định tuyến private IP qua tunnel.
• Không có LDF, DNS công khai qua Gateway trả về public IP, người dùng vào qua đường trực tiếp (bỏ qua ZTNA).

Thiết kế LDF là trọng yếu về bảo mật, không chỉ tiện lợi.

---

Tuỳ chọn triển khai

Cài thủ công (cho giai đoạn thử nghiệm)

macOS:

# Download from dash.teams.cloudflare.com
# Open .pkg, install, launch app
# Tab: Enter team name → follow IdP login

Windows:

# Download .msi
msiexec /i Cloudflare_WARP.msi /quiet
# Config team name via GUI or command:
Set-WarpOrg -Organization "<team>"

Linux:

# Debian/Ubuntu
curl -fsSL https://pkg.cloudflareclient.com/install.sh | sudo bash
sudo apt install cloudflare-warp
warp-cli register
warp-cli teams-enroll "<team>"
warp-cli connect

Triển khai MDM (cho production)

Intune (Windows/macOS):

• Tải lên gói .intunewin.
• Cấu hình profile triển khai với team name.
• Gán cho nhóm người dùng.

Jamf (macOS):

• Tải lên .pkg.
• Cấu hình configuration profile.
• Phạm vi tới nhóm thiết bị.

Workspace ONE / JumpCloud: tương tự.

Thực hành tốt khi triển khai diện rộng

• Cài sẵn team name qua cấu hình MDM, người dùng không phải nhập.
• Tự động enroll với cài đặt ngầm, giảm ticket helpdesk.
• Đợt thử nghiệm 10-50 người dùng trước khi triển khai toàn fleet.
• Cơ chế cho phép không tham gia cho các trường hợp đặc biệt (kỹ sư với thiết lập mạng tuỳ chỉnh).

---

Truy nguyên: 6 trường hợp phổ biến

1. “WARP không kết nối được”

Kiểm tra từng bước:

# Before WARP: nslookup gitlab.corp.example.com → works (via corporate DNS)
# After WARP: nslookup gitlab.corp.example.com → NXDOMAIN

Nguyên nhân phổ biến:

• Firewall công ty chặn UDP, MASQUE đáng ra tự động dự phòng nhưng đôi khi fail.
• DNS không phân giải được các endpoint Cloudflare, kiểm tra nslookup cfd-hw.cloudflareclient.com.
• Gõ sai team name.

2. “Enrollment failed: user not allowed”

Rule Device enrollment permissions từ chối người dùng. Kiểm tra:

• Zero Trust → Settings → WARP Client → Device enrollment permissions.
• Xem rule include/require/exclude.
• Xác nhận email / group của người dùng từ IdP khớp rule mong muốn.

3. “Posture check fail”

WARP đã kết nối nhưng Access policy với device_posture vẫn từ chối.

# Check what WARP is reporting
warp-cli debug posture
# Or in GUI: Settings → Preferences → Diagnostics → Posture

Phổ biến:

• Đĩa chưa mã hóa: người dùng chưa bật BitLocker/FileVault.
• Tên check không khớp: policy yêu cầu disk_encrypted, WARP báo bitlocker_enabled. Ánh xạ đúng tên.
• Trễ khi tích hợp nhà cung cấp: posture CrowdStrike chưa đồng bộ. Đợi 5-10 phút.

4. “Không phân giải được hostname nội bộ”

# Before WARP: nslookup gitlab.corp.example.com → works (via corporate DNS)
# After WARP: nslookup gitlab.corp.example.com → NXDOMAIN

Nguyên nhân: không có LDF rule cho corp.example.com.

Sửa: Zero Trust → Settings → WARP Client → Local Domain Fallback → add.

5. “Duyệt web chậm sau khi cài WARP”

Phổ biến:

• Người dùng ở xa PoP Cloudflare gần nhất (hiếm với 330+ PoP nhưng vẫn có).
• Chế độ exclude của split tunnel với rule quá rộng, lưu lượng tưởng nhanh lại đi qua WARP.
• Phương án dự phòng MASQUE đang chạy (UDP bị chặn), gây chi phí phụ TCP-over-TCP.

Debug:

• Kiểm tra warp-cli settings xem chế độ.
• Kiểm tra PoP đã kết nối: WARP UI → About → Connected to: <PoP>.
• Kiểm thử tốc độ: speed.cloudflare.com.

6. “Hao pin trên laptop/phone”

WARP daemon thường < 2% CPU khi nhàn rỗi. Nếu cao:

• Antivirus kiểm tra lưu lượng TUN: cho tiến trình WARP ngoại lệ.
• Posture check quá dày, giảm tần suất.
• WireGuard keepalive cao, mặc định 25s OK, không tự chỉnh.

---

Đánh đổi

Quyết định	Phương án A	Phương án B	Khuyến nghị
Cách triển khai	Thử nghiệm thủ công	MDM	Thủ công cho < 50 người dùng thử nghiệm, MDM cho production
Chế độ split tunnel	Include (chỉ ZTNA)	Exclude (SWG đầy đủ)	Include cho nhóm thiên về developer, Exclude cho nhóm nặng tuân thủ
Nguồn posture	Có sẵn	Tích hợp nhà cung cấp	Bắt đầu có sẵn. Nhà cung cấp khi có EDR trưởng thành
Team name	Thương hiệu công ty	Chung chung	Thương hiệu công ty, khi người dùng tìm kiếm tránh nhầm lẫn
Tự động enroll	MDM cài ngầm	Người dùng tự khởi tạo	Cài ngầm cho đa số, cho phép không tham gia với trường hợp đặc biệt
Ưu tiên WireGuard vs MASQUE	Tự động	Ép MASQUE	Tự động, WARP client tự chọn tốt nhất

---

Danh sách kiểm tra: trước khi triển khai WARP toàn fleet

Lập kế hoạch:

• Chốt team name, ghi lại trong wiki IT.
• Thiết lập rule Device enrollment permissions.
• Kết nối nhà cung cấp posture kiểm thử OK.
• LDF rules cho tất cả zone nội bộ.
• Chốt chế độ split tunnel (include / exclude).
• Chính sách cho phép không tham gia đối với kỹ sư có thiết lập mạng tuỳ chỉnh.

Triển khai:

• Thử nghiệm 10-20 người dùng trước.
• Gói MDM đã kiểm thử (cài ngầm).
• Kế hoạch lùi phiên bản: thủ tục gỡ cài được ghi lại.
• Runbook helpdesk cho 6 trường hợp ở trên.

Vận hành:

• Giám sát tỉ lệ enrollment thành công.
• Cảnh báo khi tỉ lệ posture check fail > 5%.
• Dashboard cho các số đo kiểu DEX (Part 18).
• Kiểm toán hàng quý: số người đã enroll vs toàn fleet, mức tuân thủ posture.

---

Bài học thực tế

• Thiếu LDF là bug số 1 sau khi triển khai WARP. Người dùng kêu “site nội bộ không vào được”, 80% là thiếu LDF rule. Kiểm thử LDF với nslookup từ thiết bị đã cài WARP.
• Không chuyển cứng chế độ split tunnel giữa chừng. Nếu đã triển khai chế độ include, đổi sang exclude sẽ thay đổi hành vi của toàn fleet. Lên kế hoạch chuyển đổi cẩn thận, thử nghiệm trước.
• Trễ khi tích hợp nhà cung cấp cho posture check. Posture CrowdStrike có thể trễ 5-10 phút. Policy yêu cầu posture nghiêm ngặt ngay lập tức sẽ làm người dùng than “posture fail dù laptop đã cài đủ EDR”. Cần giáo dục + đặt kỳ vọng SLA.
• WARP không tự thay VPN cho “toàn bộ lưu lượng khắp nơi”. Nếu nhóm chờ WARP sẽ chặn 100% lưu lượng người dùng không muốn: sai. WARP là công cụ, cấu hình policy mới là thứ quyết định hành vi.
• Ảnh hưởng pin gần như bằng 0 nếu daemon khỏe mạnh. Nếu người dùng than hao pin, thường do tần suất posture check quá cao hoặc AV xung đột, không phải bản chất WARP.

---

Kết luận

WARP là phía client tương ứng với Cloudflare Tunnel, đưa thiết bị vào mạng Cloudflare, gắn identity, thu thập posture, định tuyến theo split tunnel. Không có WARP đúng đắn, Access/Gateway policy với device_posture chỉ là chữ trong dashboard, không áp dụng được gì.

Các điểm đáng đầu tư:

1. Triển khai qua MDM, cài ngầm, không phụ thuộc người dùng.
2. LDF rules trước khi go-live, nếu không, DNS nội bộ fail.
3. Quyết định chế độ split tunnel, include vs exclude, chọn một, kiên định với nó.
4. Tích hợp nhà cung cấp cho posture, khi có EDR, tận dụng để có tín hiệu phong phú hơn.
5. Runbook truy nguyên, 6 trường hợp ở trên chiếm 90% ticket helpdesk.

Nếu phải nhớ một câu:

WARP là “mắt và tay” của Zero Trust ở endpoint. Không có WARP, policy device_posture chỉ là mong tưởng. Với WARP triển khai đúng, ZTNA policy hoạt động như thiết kế.

Trong Part 10 mình đề cập Magic WAN, khi WARP (user-level) không đủ và cần tunnel site-to-site ở tầng network qua Cloudflare.

---

Tài liệu tham khảo

• WARP client overview
• Device enrollment permissions
• Device posture
• Split tunnels
• Local Domain Fallback
• MDM deployment

Trong series này:

• ← Part 8: Cloudflare Tunnel deep-dive
• Tiếp theo → Part 10: Magic WAN và BGP/GRE
• Xem toàn bộ: Series Cloudflare One Handbook