上一篇 下一篇 分享链接 返回 返回顶部

从零搭建“私有版 Cloudflare”:边缘网关、WAF 与 CDN 生产落地实战

发布人:慈云数据-客服中心 发布时间:23小时前 阅读量:4

Cloudflare 私有化部署方案|生产环境实测

关键词:Cloudflare 私有化、CDN 私有部署、WAF、DDoS 防护、反向代理、边缘网关、生产环境实践、OpenResty、Nginx、Kubernetes、BGP、Anycast


一、为什么要做“Cloudflare 私有化部署”?

严格来说,Cloudflare 本身是一套全球化的云服务平台,并不提供传统意义上的“私有化部署包”。我们在生产环境中所说的“Cloudflare 私有化部署方案”,通常不是把 Cloudflare 原封不动搬到内网,而是在私有云、IDC、混合云或专有网络环境中,构建一套具备 Cloudflare 核心能力的边缘安全与流量治理平台

Cloudflare 的核心价值主要体现在以下几个方面:

  1. DNS 解析与流量调度
  2. CDN 缓存加速
  3. DDoS 防护
  4. WAF Web 应用防火墙
  5. 反向代理与 TLS 终止
  6. Bot 管理与访问控制
  7. 零信任访问
  8. 日志分析与安全审计
  9. 全局负载均衡与健康检查

在公有云场景下,使用 Cloudflare 非常方便,域名接入后即可获得全球节点、WAF、缓存、证书、规则引擎等能力。但在以下场景中,企业往往希望建设私有化方案:

  • 金融、政务、能源、运营商等行业对数据出境有严格要求;
  • 核心业务必须运行在自有 IDC 或专有云环境;
  • 业务访问群体集中在特定区域,全球 CDN 并非刚需;
  • 需要对安全策略、日志、密钥、证书进行完全自主可控;
  • 已经具备网络、安全、运维团队,希望降低长期 SaaS 成本;
  • 内部系统、专线系统、工业互联网系统无法直接接入公网 SaaS。

因此,本文讨论的“Cloudflare 私有化部署”,本质上是一套面向生产环境的私有边缘网关平台建设方案,目标是尽可能复刻 Cloudflare 在边缘安全、缓存加速、流量治理方面的能力,并结合实际生产经验给出可落地的架构设计。


二、整体架构设计

在生产环境中,我们采用了分层架构,将平台拆分为以下几个层次:

用户 / 客户端
    ↓
DNS / GSLB / 智能解析
    ↓
边缘接入层 Edge Gateway
    ↓
安全防护层 WAF / Anti-DDoS / Bot Control
    ↓
缓存与加速层 CDN Cache
    ↓
负载均衡层 L7 / L4 Load Balancer
    ↓
业务服务层 Kubernetes / VM / Bare Metal
    ↓
日志分析 / 监控告警 / 审计平台

整个方案的核心是“边缘接入层”。它承担了类似 Cloudflare Proxy 的角色,所有外部流量先进入边缘节点,由边缘节点完成 TLS 终止、访问控制、缓存命中、WAF 检查、速率限制、路由转发等动作。

在实际部署中,我们将节点分为三类:

节点类型 主要职责 部署位置
DNS / GSLB 节点 域名解析、智能调度、健康检查 公网 DNS 或私有 DNS
Edge Gateway 节点 TLS 终止、WAF、缓存、限流、反代 IDC 边界区、DMZ、云上 VPC
Origin 节点 真实业务服务 Kubernetes、虚拟机、物理机

生产环境建议至少部署 2 个以上可用区,每个可用区至少 2 台边缘节点,以避免单点故障。对于关键业务,应结合 BGP、Anycast、专线或多运营商出口实现更高等级的容灾。


三、核心组件选型

1. 边缘代理:OpenResty / Nginx / Envoy

边缘代理是整个私有化方案的核心组件。我们在生产环境中主要使用 OpenResty 和 Nginx,部分微服务场景使用 Envoy。

OpenResty 的优势:

  • 基于 Nginx,性能稳定;
  • 支持 Lua 扩展,规则灵活;
  • 可实现动态路由、动态限流、鉴权、灰度发布;
  • 社区成熟,运维成本较低。

Envoy 的优势:

  • 原生支持 xDS 动态配置;
  • 对微服务、gRPC、服务网格友好;
  • 可观测性能力强;
  • 适合复杂东西向和南北向流量治理。

如果团队熟悉 Nginx,并且业务主要是 HTTP/HTTPS,OpenResty 是性价比很高的选择。如果业务大量使用 gRPC、HTTP/2、服务网格,则 Envoy 更适合作为核心网关。

2. WAF:ModSecurity / Coraza / 自研规则引擎

Cloudflare 的 WAF 能力非常强,私有化方案要完全复刻并不现实,但可以实现企业级基础防护。

常见选择包括:

  • ModSecurity + OWASP CRS
  • Coraza WAF
  • Nginx Lua 自研规则
  • 商业 WAF 设备或云 WAF 私有版

我们在生产环境中采用的是“基础规则 + 自定义规则 + 风险评分”的方式,而不是简单地一刀切拦截。

例如:

  • SQL 注入检测;
  • XSS 检测;
  • 命令注入检测;
  • 非法 User-Agent 拦截;
  • 高频路径扫描识别;
  • 后台路径保护;
  • API 参数白名单校验;
  • 地域/IP/ASN 访问控制。

需要注意的是,WAF 最容易出现的问题是误杀。因此上线策略建议分为三个阶段:

  1. 观察模式:只记录不拦截;
  2. 灰度拦截:对低风险业务先启用;
  3. 全量拦截:结合误报反馈持续优化。

3. 缓存加速:Nginx Cache / Varnish / ATS

CDN 的核心能力之一是缓存。私有化部署中,缓存层主要用于静态资源、半静态接口、图片、下载文件等场景。

可选组件:

组件 特点
Nginx Cache 简单稳定,适合中小规模
Varnish 缓存能力强,规则灵活
Apache Traffic Server 高性能,适合大规模 CDN 场景
Squid 历史悠久,但现代 Web 场景使用较少

我们在生产环境中选择 Nginx Cache,原因是架构简单、维护成本低,并且能够满足大多数业务需求。

常见缓存策略包括:

proxy_cache_path /data/cache levels=1:2 keys_zone=edge_cache:10g max_size=500g inactive=7d use_temp_path=off;

location /static/ {
    proxy_cache edge_cache;
    proxy_cache_valid 200 301 302 30d;
    proxy_cache_valid 404 1m;
    proxy_cache_use_stale error timeout updating;
    proxy_cache_lock on;
    proxy_pass http://origin;
}

实际生产中,缓存策略不应只依赖路径,还要结合 Header、Cookie、Query String 和业务类型。例如:

  • 登录态页面不得缓存;
  • 带用户隐私数据的接口不得缓存;
  • 图片、CSS、JS 可长缓存;
  • API 接口可做短时间微缓存;
  • 下载类文件可以开启 Range 支持;
  • 缓存刷新需要接入发布系统或管理平台。

4. DDoS 防护:网络层 + 应用层组合

Cloudflare 的一个核心能力是抗 DDoS。私有化部署中,DDoS 防护是最难完全复刻的部分,因为它不仅依赖软件能力,更依赖带宽、清洗中心、运营商协同和全球节点容量。

生产环境建议采用组合方案:

  1. 运营商高防 / 云高防 / 清洗中心
  2. 边界防火墙 ACL
  3. L4 连接数限制
  4. L7 请求频率限制
  5. 验证码 / JS Challenge
  6. 黑白名单机制
  7. 异常行为自动封禁

在 OpenResty 中可以通过 Lua 实现限流,例如基于 IP、URI、Host、Token 等维度进行限制:

-- 示例:基于 IP 的简单限流逻辑
local limit_req = require "resty.limit.req"
local lim, err = limit_req.new("limit_req_store", 10, 20)

local key = ngx.var.binary_remote_addr
local delay, err = lim:incoming(key, true)

if not delay then
    ngx.status = 429
    ngx.say("Too Many Requests")
    return ngx.exit(429)
end

不过需要强调,边缘节点自身不是无限抗打的。如果攻击流量已经打满入口带宽,应用层限流再精细也没有意义。因此,对于公网关键业务,必须配置上游高防或运营商清洗能力。


四、生产部署拓扑

我们在生产环境中采用了如下部署模型:

                    ┌────────────────────┐
                    │      用户访问       │
                    └─────────┬──────────┘
                              │
                    ┌─────────▼──────────┐
                    │   DNS / GSLB 调度   │
                    └─────────┬──────────┘
                              │
        ┌─────────────────────┼─────────────────────┐
        │                     │                     │
┌───────▼───────┐     ┌───────▼───────┐     ┌───────▼───────┐
│ Edge Node A   │     │ Edge Node B   │     │ Edge Node C   │
│ Nginx/WAF/CDN │     │ Nginx/WAF/CDN │     │ Nginx/WAF/CDN │
└───────┬───────┘     └───────┬───────┘     └───────┬───────┘
        │                     │                     │
        └─────────────┬───────┴─────────────┬───────┘
                      │                     │
              ┌───────▼───────┐     ┌───────▼───────┐
              │ Origin Group 1 │     │ Origin Group 2 │
              │ Kubernetes     │     │ VM / BareMetal │
              └───────────────┘     └───────────────┘

每个 Edge Node 包含以下模块:

  • Nginx / OpenResty;
  • WAF 模块;
  • Cache 模块;
  • TLS 证书管理;
  • 日志采集 Agent;
  • 健康检查组件;
  • 配置下发 Agent;
  • 本地防火墙策略;
  • Fail2ban 或自研封禁模块。

配置管理采用 GitOps 思路:所有站点配置、路由规则、缓存策略、WAF 策略都进入 Git 仓库,通过 CI/CD 进行校验和发布。这样可以避免人工直接登录服务器修改配置导致的不一致和不可追溯。


五、DNS 与流量调度设计

Cloudflare 的 DNS 和代理能力高度集成,私有化方案中需要单独设计 DNS 调度。

常用方案包括:

  1. 公网权威 DNS + 智能解析
  2. 自建 PowerDNS / Bind
  3. GSLB 设备
  4. 云厂商 DNS
  5. 内部 CoreDNS / Consul DNS

生产环境中,我们将公网域名托管在权威 DNS 服务上,通过智能解析将用户调度到不同边缘节点。调度依据包括:

  • 运营商;
  • 地域;
  • 节点健康状态;
  • 业务权重;
  • 灰度比例;
  • 线路质量;
  • 故障切换策略。

对于内部系统,则使用私有 DNS,将域名解析到内网 Edge Gateway,实现内部系统也经过统一安全入口。

DNS TTL 不建议设置过长。一般生产环境可设置为 60 秒到 300 秒。如果业务对故障切换要求很高,可以结合健康检查和短 TTL 实现快速切换。


六、TLS 证书与加密策略

Cloudflare 的证书管理非常方便,而私有化方案中,证书管理必须重点设计。

证书来源可分为:

  • 公网业务:Let’s Encrypt、DigiCert、GlobalSign 等;
  • 内部业务:企业 CA、自建 CA;
  • 专线业务:双方约定 CA 或双向 TLS。

生产环境中建议:

  1. 使用自动化证书申请和续期;
  2. 私钥不得明文分散存储;
  3. 证书变更要有审批和审计;
  4. 支持 TLS 1.2 和 TLS 1.3;
  5. 禁用不安全加密套件;
  6. 对核心 API 启用 mTLS;
  7. 证书即将过期前自动告警。

Nginx 中可配置较安全的 TLS 策略:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5:!RC4:!3DES;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 10m;

对于多租户或多域名场景,可以使用 SNI 动态加载证书,避免每次新增域名都重载完整服务。


七、WAF 策略实测经验

在生产环境中,WAF 的核心不是“规则越多越好”,而是“规则准确、可观测、可回滚”。

我们上线 WAF 后观察到以下几类高频攻击:

  • /phpmyadmin/wp-admin/wp-login.php 扫描;
  • SQL 注入探测,如 union selectsleep()benchmark()
  • XSS 探测,如