TL;DR
Magic WAN là tunnel mức mạng: kết nối site-to-site qua Cloudflare backbone, thay thế MPLS và SD-WAN truyền thống cho doanh nghiệp đa chi nhánh / đa cloud.
Khác WARP (Part 9) ở phạm vi:
- WARP: tunnel theo thiết bị, user identity, posture: ZTNA mức người dùng.
- Magic WAN: tunnel theo site, định tuyến CIDR, không identity: backbone mức mạng.
Bài này đi qua:
- WARP vs Magic WAN: cùng là tunnel nhưng phạm vi khác.
- 4 tuỳ chọn tunnel: IPsec, GRE, Anycast IP, CNI (Cloud Network Interconnect).
- BGP peering: khi nào cần, thiết lập cơ bản.
- Magic Transit vs Magic WAN: 2 sản phẩm tách biệt nhưng thường bị lẫn.
- Kịch bản đa cloud: hub-and-spoke với CF làm backbone.
- Magic Firewall: chính sách L3/L4 áp dụng dọc backbone.
- Chuyển đổi từ MPLS/SD-WAN: playbook thực tế.
Luận điểm chính:
Magic WAN không thay thế Cloudflare Access/WARP. Nó bổ sung ở tầng thấp hơn, kết nối mức mạng cho site chi nhánh và VPC cloud. Dùng đúng: ZTNA bằng WARP+Access, site-to-site bằng Magic WAN. Trộn lẫn phạm vi thì thiết kế sẽ rối như tơ vò.
Bài này là Part 10 của Cloudflare One Handbook, đóng block Connectivity (Part 8-10).
Dành cho ai
- Kỹ sư mạng quản MPLS, SD-WAN, hoặc VPN site-to-site.
- Kỹ sư nền tảng xây kiến trúc đa cloud (AWS + Azure + GCP + on-prem).
- IT director đánh giá nền tảng SASE thay nhà cung cấp SD-WAN truyền thống.
Bạn nên đã đọc:
- Part 8, Cloudflare Tunnel (đưa ứng dụng nội bộ ra mà không mở inbound).
- Part 9, WARP (tunnel theo thiết bị mức người dùng).
Sau bài này bạn sẽ:
- Phân biệt WARP vs Magic WAN vs Magic Transit.
- Biết chọn giao thức tunnel nào (IPsec/GRE/Anycast/CNI) cho từng site.
- Hiểu BGP peering với Cloudflare (AS 13335).
- Thiết kế topology đa cloud với CF backbone.
- Có playbook chuyển đổi từ MPLS.
Bài này không nói về gì
- WARP Connector (tunnel mức subnet dùng WARP daemon): trung gian giữa WARP và Magic WAN, niche.
- Cloudflare Network Interconnect (CNI) deep-dive: chỉ nhắc ở mức tổng quan.
- So sánh SD-WAN theo nhà cung cấp cụ thể (Cisco Viptela, VMware VeloCloud, Fortinet): chỉ so với khái niệm Magic WAN.
- Traffic engineering / QoS nâng cao: Cloudflare không phơi toàn bộ BGP community, chỉ hỗ trợ điều hướng lưu lượng cơ bản.
Khái niệm
- Magic WAN: sản phẩm giống SD-WAN của Cloudflare. Site + VPC cloud tunnel lên CF backbone.
- Magic Transit: sản phẩm khác: ingress DDoS scrubbing cho dải public IP của khách (BGP quảng bá prefix của khách).
- Magic Firewall: rule firewall L3/L4 áp dụng trên lưu lượng Magic WAN/Transit.
- IPsec: tunnel mã hóa chuẩn (IKEv2, AES-GCM). Được hỗ trợ rộng rãi.
- GRE: Generic Routing Encapsulation. Tunnel trơn, không mã hóa sẵn.
- Anycast IP: Cloudflare cấp public IP, khách định tuyến lưu lượng trực tiếp (không tunnel).
- CNI (Cloud Network Interconnect): link riêng chuyên dụng (AWS Direct Connect, Azure ExpressRoute) tới CF, không qua internet.
- BGP peering: giao thức định tuyến động, quảng bá prefix giữa khách và Cloudflare AS 13335.
- ASN: Autonomous System Number, định danh mạng trong BGP.
WARP vs Magic WAN: khác phạm vi
Khác biệt cốt lõi
| Yếu tố | WARP | Magic WAN |
|---|---|---|
| Phạm vi | Per-device | Per-site / per-VPC |
| Tunnel count | 1 per device | 1 per site |
| Identity | User (via IdP) | Không có (network-level) |
| Posture | Có (device posture) | Không |
| Policy layer | Access, Gateway, DLP | Magic Firewall (L3/L4) |
| Typical use | User device, laptop, phone | Branch office, cloud VPC, DC |
| Deploy target | OS-level client | Router, firewall, cloud VPN gateway |
| Ideal scale | 10-100,000 devices | 1-1000 sites |
Khi nào dùng cái nào
WARP khi:
- Người dùng đi lại, làm việc từ xa, di động.
- Cần policy gắn identity (kỹ sư vs nhân sự thuê ngoài).
- Cần posture check (đĩa mã hóa, MDM compliant).
Magic WAN khi:
- Cả site (50-500 thiết bị sau router) cần kết nối.
- VPC cloud nói với VPC cloud khác hoặc với DC.
- Không thể cài WARP trên từng thiết bị (IoT, OT, thiết bị legacy).
- Cần thay MPLS/SD-WAN.
Dùng cả hai:
- Doanh nghiệp thực tế dùng WARP cho thiết bị người dùng + Magic WAN cho chi nhánh/cloud. Hai lớp không xung đột.
Topology Magic WAN
Hub-and-spoke với CF làm hub
- Mỗi site tạo tunnel (IPsec/GRE/Anycast/CNI) tới CF edge.
- Lưu lượng site-to-site không cần peer trực tiếp, đi qua CF backbone.
- Thêm site mới = tạo 1 tunnel tới CF, không cần cập nhật tất cả site khác.
Khác full mesh truyền thống
Truyền thống: N site, N(N-1)/2 tunnel. 10 site = 45 tunnel. Thêm mỗi site mới, số tunnel cần cấu hình tăng kiểu bậc hai, nhanh chóng không quản được.
Magic WAN: N site, N tunnel. Độ phức tạp vận hành tuyến tính.
Lợi thế anycast
CF backbone dùng anycast, mọi site kết nối tới PoP gần nhất. Site ở Việt Nam đi PoP Singapore. Site ở Frankfurt đi PoP Frankfurt. Độ trễ tối ưu tự động.
Throughput
Một tunnel có giới hạn (thường 1-2 Gbps cho IPsec đơn, cao hơn cho CNI). Ở quy mô lớn dùng nhiều tunnel + ECMP (equal-cost multi-path routing), Cloudflare hỗ trợ, cần cấu hình.
4 tuỳ chọn tunnel
1. IPsec
Ưu:
- Mã hóa mạnh (AES-GCM, IKEv2).
- Hầu hết router/firewall doanh nghiệp đã hỗ trợ (Cisco, Fortinet, Palo Alto, Juniper).
- Thân thiện với NAT (NAT-Traversal).
Nhược:
- Thiết lập phức tạp (PSK/cert, SA, cấu hình tunnel).
- Throughput thấp hơn GRE (chi phí phụ do mã hóa).
- Debug stack IKE phức tạp.
Khi dùng: site với firewall doanh nghiệp hiện có, yêu cầu tuân thủ tunnel có mã hóa.
Config sample (Cloudflare side):
Anchor IP: <provided by CF>
Remote IP: <your public IP>
IKE version: IKEv2
Pre-shared key: <generate>
Proposals: AES-GCM-256, SHA-256, DH group 14
Lifetime: 28800s (8h)Config sample (customer side, example Cisco ASA):
crypto ikev2 policy 1
encryption aes-gcm-256
integrity sha256
group 14
prf sha256
lifetime seconds 28800
crypto map CFMAP 10 set peer <CF-anchor-IP>
crypto map CFMAP 10 set ikev2 ipsec-proposal AES-GCM
crypto map CFMAP 10 set pfs group142. GRE
Ưu:
- Đơn giản: 2 endpoint, không cần thỏa thuận mã hóa.
- Throughput cao (không chi phí phụ do crypto).
- Cấu hình GRE trên Cisco/Juniper đã quen thuộc.
Nhược:
- Không mã hóa: lưu lượng qua internet ở dạng rõ. Vấn đề tuân thủ với nhiều tổ chức.
- Giao thức 47 (không phải TCP/UDP), bị chặn ở nhiều NAT, wifi khách sạn.
- Cần public IP 2 đầu.
Khi dùng: phân đoạn mạng nội bộ legacy, throughput ưu tiên hơn mã hóa, chấp nhận không mã hóa (vì nằm trên đường MPLS tin cậy).
Config sample (Cloudflare side):
Anchor: 162.159.x.x
Customer: 203.0.113.1
MSS: 1476 (GRE + IP header = 24 bytes)Customer side (Linux example):
ip tunnel add cfgre mode gre remote 162.159.x.x local 203.0.113.1 ttl 255
ip link set cfgre up
ip addr add 10.255.0.1/30 dev cfgre
ip route add 172.16.0.0/12 via 10.255.0.23. Anycast IP
Ưu:
- Thiết lập đơn giản nhất: không cần cấu hình tunnel.
- Cloudflare cấp public anycast IP, khách định tuyến lưu lượng tới đó.
- Chạy được bất cứ đâu internet tới được.
Nhược:
- Tầng ứng dụng (TLS/HTTPS).
- Không mã hóa lưu lượng mạng sẵn có (lưu lượng được mã hóa ở tầng ứng dụng).
Khi dùng: khối lượng công việc cloud nói với CF, stack hiện đại, không cần IP peering site-to-site.
Không phù hợp: giao thức legacy (SMB, NFS, DB direct), cần định tuyến mức mạng.
4. CNI: Cloud Network Interconnect
Ưu:
- Kết nối riêng: không qua internet công cộng.
- Băng thông dự đoán được (link riêng).
- Cam kết SLA.
Nhược:
- Hợp đồng + thời gian thiết lập (nhiều tuần).
- Chi phí định kỳ (phí cổng chuyên dụng).
- Chỉ có ở colocation có CF hiện diện.
Khi dùng:
- Production throughput cao (multi-Gbps).
- Cloud trực tiếp: AWS Direct Connect, Azure ExpressRoute, GCP Partner Interconnect.
- Tuân thủ yêu cầu không đi qua internet.
Khi không: startup, thử nghiệm, throughput thấp, IPsec đủ.
BGP peering
Với nhiều site, route tĩnh không mở rộng. BGP cho phép trao đổi route động.
Khi nào dùng BGP
- ≥ 3 site.
- Route thay đổi thường xuyên (thêm/bớt VPC, subnet).
- Cần chuyển đổi dự phòng tự động (site down, BGP rút route, lưu lượng định tuyến lại).
Thiết lập
- ASN khách: dùng ASN riêng (65xxx-65534) hoặc ASN công khai mà bạn có.
- CF ASN: 13335 (ASN công khai của Cloudflare).
- eBGP peering: TCP 179 qua tunnel (IPsec hoặc GRE).
- Quảng bá: prefix của site (10.10.0.0/16, v.v.) tới CF.
- Nhận: prefix của các site khác (CF phát tán).
Ví dụ cấu hình (Cisco, BGP over IPsec tunnel)
router bgp 65001
neighbor 10.255.0.2 remote-as 13335
address-family ipv4 unicast
neighbor 10.255.0.2 activate
network 10.10.0.0 mask 255.255.0.0
network 10.20.0.0 mask 255.255.0.0Thực hành tốt khi quảng bá route
- Gộp prefix: quảng bá /16 thay vì nhiều /24, giảm kích thước bảng định tuyến.
- Community tag: Cloudflare hỗ trợ BGP community cho điều hướng lưu lượng (community riêng cho đường dự phòng).
- Bộ lọc AS-path: chỉ chấp nhận route từ CF (AS 13335), không chấp nhận quảng bá giả mạo.
Vấn đề BGP phổ biến
- Không trao đổi route: kiểm tra TCP 179 có tới được không. Telnet 179 từ khách đến tunnel IP, nếu fail là firewall chặn.
- Route flap: BGP session không ổn định. Kiểm tra MTU tunnel (khuyến nghị 1400 với chi phí phụ của IPsec).
- Giới hạn prefix: CF có tối đa 1000 prefix mỗi peering. Gộp nhiều.
Magic Transit vs Magic WAN
Hai sản phẩm tên gần giống, hay bị lẫn.
Magic Transit
Trường hợp sử dụng: bảo vệ DDoS cho dải public IP của khách.
Cơ chế:
- Khách có public /24 hoặc /23.
- Cloudflare quảng bá prefix đó qua BGP (Cloudflare làm upstream).
- Lưu lượng toàn cầu đến prefix sẽ vào CF edge trước.
- DDoS scrub ở CF, lưu lượng sạch qua GRE tunnel về DC của khách.
Ví dụ: ngân hàng có endpoint API công khai với IP 203.0.113.0/24. Bị DDoS hàng ngày. Magic Transit scrub ở CF, DC chỉ nhận lưu lượng sạch.
Magic WAN
Trường hợp sử dụng: kết nối site-to-site giữa các site/VPC của khách.
Cơ chế:
- Khách có nhiều site.
- Mỗi site tunnel lên CF.
- CF định tuyến giữa các site, không cần peer trực tiếp.
Ví dụ: doanh nghiệp có 10 chi nhánh + 3 VPC cloud. MPLS đắt, SD-WAN phức tạp. Magic WAN thay bằng 13 tunnel đến CF.
Có thể dùng chung
Magic Transit + Magic WAN cùng lúc: prefix công cộng được Transit bảo vệ, site nội bộ kết nối qua WAN. Hai sản phẩm không đối lập.
Magic Firewall
Rule firewall Layer 3/4 áp dụng trên lưu lượng Magic WAN + Magic Transit.
Ví dụ rule
# Block all inbound except specific allowed
- action: block
expression: "ip.proto == tcp and tcp.dstport in {23 3389}"
# block Telnet, RDP default ports
- action: allow
expression: "ip.src in 10.0.0.0/8 and ip.dst in 172.16.0.0/12"
# allow HQ to AWS VPC
- action: log
expression: "ip.proto == udp and udp.dstport == 53"
# log all DNS for investigationFields: ip.src, ip.dst, ip.proto, tcp.srcport, tcp.dstport, udp.srcport, udp.dstport, icmp.type, ip.geoip.country.
Magic Firewall vs firewall truyền thống
| Dimension | Traditional NGFW | Magic Firewall |
|---|---|---|
| Location | Per-site appliance | Cloudflare edge |
| Scale | Per-box limit | Unlimited |
| Management | Per-device, sync config | Single dashboard all sites |
| L7 inspection | Yes (DPI) | Basic, Gateway for L7 |
| Cost | Box + license per site | Per-throughput |
Magic Firewall không thay NGFW hoàn toàn, nó là lớp L3/L4 ở edge. Kiểm tra L7 ở Gateway (Part 11-12).
Kịch bản đa cloud
Thách thức
- AWS VPC
172.16.0.0/16cần nói với Azure VNet172.17.0.0/16. - Truyền thống: VPC peering (chỉ AWS), hoặc VPN gateway-to-gateway (phức tạp, đắt).
- Đa cloud: 3 cloud × 3 peer = 9 link, mỗi link cần cấu hình.
Giải pháp Magic WAN
AWS VPC → IPsec/CNI → Cloudflare Edge
Azure VNet → IPsec/CNI → Cloudflare Edge
GCP VPC → IPsec/CNI → Cloudflare Edge
Oracle Cloud → IPsec/CNI → Cloudflare EdgeCloudflare định tuyến giữa cả 4. Thêm cloud thứ 5 = 1 tunnel mới, không phải 4.
BGP quảng bá theo từng cloud
Mỗi tunnel của cloud quảng bá CIDR VPC của nó. CF phát tán cho tất cả cloud khác. Bảng định tuyến tự cập nhật.
Cân nhắc về độ trễ
Site-to-site qua Cloudflare backbone thường nhanh hơn VPN liên vùng của chính cloud vì anycast mesh của CF tối ưu. Nhưng peer trực tiếp (VPC peering trong cùng cloud) vẫn nhanh nhất.
Nguyên tắc: trong cùng cloud dùng peering sẵn có, xuyên cloud dùng Magic WAN.
SD-WAN vs Magic WAN
Khác biệt triết lý
SD-WAN truyền thống (Cisco Viptela, VMware VeloCloud):
- Thiết bị tại mỗi site.
- Thiết bị đồng bộ cấu hình từ controller trung tâm.
- Traffic engineering tại hộp.
- QoS, DPI trên thiết bị.
Magic WAN:
- Tunnel lên CF (hộp nội bộ tối thiểu).
- Cấu hình tập trung ở dashboard CF.
- Traffic engineering ở CF edge.
- Firewall L3/L4 + L7 ở Gateway/CASB.
Khi SD-WAN vẫn thắng
- Xuyên site cực nhạy độ trễ (CF thêm 10-50ms, SD-WAN peer trực tiếp có thể thấp hơn).
- Tối ưu WAN nâng cao (khử trùng lặp, nén) mà CF không làm.
- Đã đầu tư SD-WAN: chi phí đã bỏ.
Khi Magic WAN thắng
- Đa cloud (SD-WAN tệ với tích hợp cloud, Magic WAN sẵn có).
- Doanh nghiệp nhỏ-vừa không muốn gánh nặng thiết bị.
- Tổ chức ưu tiên bảo mật: Magic Firewall + Gateway đã tích hợp.
Playbook chuyển đổi
Giai đoạn 1: Đánh giá (4 tuần)
- Kiểm kê site + CIDR.
- Ánh xạ circuit MPLS hiện tại + chi phí.
- Xác định tài sản cloud cần kết nối.
- Tính throughput + độ trễ đường cơ sở.
Giai đoạn 2: Thử nghiệm (8 tuần)
- Chọn 2-3 site rủi ro thấp (chi nhánh nhỏ, môi trường dev).
- Thiết lập IPsec tunnel Magic WAN song song MPLS hiện có.
- Kiểm thử: HTTP, kết nối DB, SMB, SIP (nếu có VoIP).
- Đo: độ trễ, throughput, ổn định.
Giai đoạn 3: Chuyển đổi từng site (3-6 tháng)
- Mỗi site: cắt MPLS, định tuyến qua Magic WAN.
- Giám sát sát: 1 tuần mỗi site.
- Kế hoạch khôi phục: bật lại circuit MPLS nếu có vấn đề nghiêm trọng.
- Kết thúc: hủy hợp đồng MPLS, tiết kiệm $$$.
Giai đoạn 4: Thêm cloud + tối ưu (liên tục)
- Kết nối VPC AWS/Azure/GCP qua CNI hoặc IPsec.
- Tối ưu: BGP communities, rule Magic Firewall, tinh chỉnh throughput.
Lộ trình thực tế
Chuyển đổi toàn bộ 12-18 tháng cho doanh nghiệp 50+ site. Đừng vội, hợp đồng MPLS thường 1-3 năm, căn triển khai với cửa sổ gia hạn.
Truy nguyên
”IPsec tunnel up nhưng không có lưu lượng”
Kiểm tra BGP/route tĩnh. Lớp tunnel OK nhưng định tuyến chưa quảng bá prefix sang phía CF.
# Customer side
show ip bgp summary
# Should see CF peer "Established"
# CF side (dashboard)
Magic WAN → Sites → [site] → BGP sessions
# Status: Active”Throughput thấp hơn kỳ vọng”
- Vấn đề MTU. IPsec thêm ~40-60 byte chi phí phụ. Phía khách đặt MTU 1400 (không phải mặc định 1500).
- Giới hạn băng thông một tunnel. Dùng ECMP với nhiều tunnel.
”Route flap vài phút một lần”
- BGP session không ổn.
- Kiểm tra cấu hình tunnel keepalive (DPD Dead Peer Detection).
- Đôi khi vấn đề bộ đếm NAT-T: tăng lên 20s.
”Không tới được AWS VPC từ HQ”
- BGP có quảng bá prefix AWS VPC về phía CF không?
- CF có lan tới peer HQ không?
- Debug:
show ip bgp 172.16.0.0/16ở phía HQ.
”Rule Magic Firewall không áp dụng”
- Thứ tự rule quan trọng: kiểm tra thứ tự ưu tiên.
- Kiểm tra hành động rule (block vs log).
- CF analytics → firewall events.
Đánh đổi
| Quyết định | Phương án A | Phương án B | Khuyến nghị |
|---|---|---|---|
| Giao thức tunnel | IPsec | GRE | IPsec nếu cần tuân thủ. GRE nếu chấp nhận trơn + throughput cao hơn |
| Định tuyến | Tĩnh | BGP | BGP khi ≥ 3 site. Tĩnh OK cho 2 site |
| Kết nối cloud | IPsec qua internet | CNI | CNI cho prod/throughput cao. IPsec cho dev/khối lượng thấp |
| Thay SD-WAN | Chuyển toàn bộ | Chạy song song | Chạy song song 3-6 tháng, xác nhận, rồi cắt |
| Magic WAN + WARP | Một trong hai | Kết hợp | Kết hợp, WARP cho người dùng, Magic WAN cho site. Bổ trợ nhau |
| MTU | Mặc định 1500 | Tuỳ chỉnh 1400 | Tuỳ chỉnh, tránh phân mảnh với IPsec |
Danh sách kiểm tra: trước khi production Magic WAN
Lập kế hoạch:
- Kiểm kê site + bản đồ CIDR.
- Zone CF có giấy phép Magic WAN.
- Public IP hoặc CNI cho mỗi site.
- ASN BGP đã gán (ASN riêng 65xxx hoặc công khai).
Cấu hình tunnel:
- Anchor IP + IP khách đã xác nhận.
- PSK lưu trong secret manager.
- MTU = 1400 (IPsec) hoặc 1476 (GRE).
- Đã bật DPD/keepalive.
Định tuyến:
- BGP session đã established (Active trong dashboard CF).
- Prefix quảng bá/nhận đúng.
- Gộp route (khối lớn hơn).
Bảo mật:
- Rule Magic Firewall kiểm thử ở chế độ log trước khi áp dụng.
- Thứ tự rule đã rà soát.
- Chống giả mạo: không chấp nhận prefix từ peer không mong đợi.
Vận hành:
- Giám sát: trạng thái tunnel, throughput, BGP session.
- Cảnh báo khi tunnel down > 1 phút.
- Cảnh báo khi BGP session flap > 3x/giờ.
- Runbook khôi phục tunnel.
Bài học thực tế
- BGP là kẻ giết thầm lặng của Magic WAN thử nghiệm. Các nhóm đánh giá thấp độ phức tạp BGP. Đầu tư kiến thức BGP (hoặc thuê nhân sự ngoài) trước khi thử nghiệm.
- Phân mảnh MTU: mặc định 1500 với chi phí phụ IPsec = gói bị phân mảnh = chậm. Tùy chỉnh MTU 1400 rõ ràng.
- Magic Transit ≠ Magic WAN. Product manager đặt cả hai “Magic” gây nhầm lẫn. Nhớ kỹ: Transit = DDoS scrubbing, WAN = site-to-site.
- Đừng chuyển MPLS một cú. Chạy song song là bắt buộc. 3-6 tháng.
- Chuyển đổi VPC cloud thêm 1-2 tháng mỗi cloud. Nhóm mạng chưa quen Cloudflare, phía cloud chưa quen Magic WAN. Dành thời gian.
- ECMP cho throughput: một tunnel có giới hạn. Nhiều tunnel với ECMP cho N× throughput.
Kết luận
Magic WAN hoàn thiện câu chuyện kết nối của Cloudflare One. Part 8 (Tunnel) đưa ứng dụng nội bộ lên edge. Part 9 (WARP) đưa thiết bị người dùng lên edge. Part 10 (Magic WAN) đưa toàn bộ mạng site lên edge.
Ba tầng này xử lý 100% mẫu kết nối của doanh nghiệp hiện đại:
- Người dùng qua WARP.
- Ứng dụng đơn lẻ qua Tunnel.
- Site / VPC cloud qua Magic WAN.
Khi ba thứ phối hợp, lưu lượng đi qua Cloudflare với chính sách bảo mật, khả năng quan sát, và chi phí dự đoán được.
Nếu phải nhớ một câu:
Magic WAN không thay Access/WARP. Nó bổ sung ở tầng thấp hơn. Dùng đúng: ZTNA bằng WARP+Access, site-to-site bằng Magic WAN. Trộn lẫn phạm vi thì thiết kế rối như tơ vò.
Trong Part 11 chuyển sang block Policy & Filtering. Bắt đầu với Gateway DNS filtering, lớp đơn giản nhất của Secure Web Gateway, thường là điểm đầu tiên bật cho nhóm bảo mật.
Tài liệu tham khảo
- Cloudflare Magic WAN overview
- Magic WAN tunnel options
- BGP with Magic WAN
- Magic Firewall
- Magic Transit (distinct product)
- Cloudflare Network Interconnect
Trong series này:
- ← Part 9: WARP client và device enrollment
- Tiếp theo → Part 11: Gateway DNS filtering
- Xem toàn bộ: Series Cloudflare One Handbook
