多 VPC 集中式网络防火墙架构实战：流量引流、规则校验与高可用回滚

多 VPC 环境中最危险的一次变更，往往并不是策略写错了某一条五元组，而是一条默认路由被指向了尚未就绪的检查实例——路由收敛的几秒里，几十个业务 VPC 的东西向流量同时失去下一跳。集中式网络防火墙把检查能力收拢到一处，同时也把故障影响范围收拢到了一处：控制面上一次误操作，影响面从“一个 VPC”放大到“整个网络平面”。因此这类架构的实战重点并不在于能否买到防火墙，而在于三件事能否形成闭环：流量如何被确定地引到检查点、规则在生效前如何被验证、出错后如何在一分钟内回到已知良好状态。

先看清集中式检查把风险放在了哪里

集中式检查的常见形态有三种，风险特征完全不同：

• 集中出向（NAT 边界）：业务 VPC 的公网出口统一走一个出口 VPC，NAT 网关与防火墙都部署在那里。影响面是“所有出网业务”，但东西向流量不受影响。
• VPC 间东西向检查：通过修改业务 VPC 的路由表，把 VPC 之间的流量牵引到检查 VPC。影响面最大，一旦检查集群不可用或路由错误，跨 VPC 调用直接中断。
• 混合云与专线入口：VPN、专线流量经中转设备进入检查 VPC。失败表现常是“部分网段通、部分网段不通”，比全断更难定位。

无论哪种形态，引流都依赖对路由的修改。腾讯云云防火墙的高可用说明中描述的做法是：通过动态修改 VPC 的默认路由表，把需要保护的跨 VPC 流量牵引到防火墙集群做安全检查；同时该文档明确指出，开启防火墙时底层网络会发生路由收敛，通常带来 1–2 秒的短暂抖动或延迟（CFW High Availability Specification）。这个细节很重要：即便配置完全正确，引流本身也是有成本的，变更窗口必须按“会抖”来设计，而不是按“无损”来假设。

流量引流：三条落地路径与四个不变量

自动引流适合“范围大、变更频繁”

自动引流的价值在于覆盖面。平台侧批量改写路由表，运维不需要逐个 VPC 手工加条目。火山引擎的文档给出的自动引流场景是：完成 VPC1、VPC2、VPC3 之间的流量引流后，再配置“VPC1 网段可访问 VPC2、VPC2 网段可访问 VPC3、其余全部阻断”这类策略（VPC 与 VPC 之间流量访问控制）。

这里有一个容易被忽略的顺序问题：引流与策略必须作为一个原子变更发布。如果先引流、后下发策略，中间那段时间防火墙用的是旧策略或默认策略，可能放行了本应阻断的流量；如果先下发策略、后引流，策略在无流量状态下“看起来生效”，一旦引流才暴露误阻断。两种顺序都需要在变更单里写清楚，并配套一段可观测的观察期。

手动引流适合“范围可控、需要精细控制”

手动引流把控制权交给网络团队，在中转路由器上创建连接并把路由指向检查 VPC。火山引擎文档提到，引流场景创建后，中转路由器网络实例连接中会增加云防火墙的 VPC，连接名带 CFW_system_请勿编辑 前缀——这类由平台托管的对象不应被人工修改，否则平台侧的引流状态与手工配置会互相覆盖（手动引流配置）。

AWS 的对应做法是通过 Transit Gateway 集成检查 VPC 之间的东西向流量，无需为每个业务 VPC 单独维护检查实例（AWS Network Firewall 功能）。这条路线的工程要求是：中转层的路由表分区必须清晰，生产、预发、隔离环境的附着（attachment）不能共享同一张路由表，否则一次关联错误就会把测试流量送进生产检查集群。

四个必须守住的不变量

1. 不回环：检查 VPC 自身的默认路由不能再次指向检查集群，否则流量在集群内部打转。
2. 路径对称：请求与响应必须经过同一组检查节点。非对称路由在有状态检查下会表现为“SYN 过去、回包被丢”，且日志里只看到单向流量。
3. 保留逃生路径：为管理面、监控探针、堡垒机保留独立的、不经过检查集群的路由，避免“防火墙挂了连修都修不了”。
4. 不重复牵引：走网关端点、PrivateLink、对等连接的流量要明确是否需要二次检查，重复牵引会带来额外延迟和会话表压力。

规则校验：把“全网断网”挡在发布之前

规则错误导致的事故，绝大多数不是语法错误，而是语义与影响面错误：一条 deny any any 被放在了规则组顶部、一条网段写成了 /8、一条规则只对某个标签生效但标签选择器写错了。这些错误在控制台上看起来都“配置成功”。

分层校验模型

把校验分成五层，每层的拦截成本依次上升：

1. 语法层：规则能被解析、字段类型正确、CIDR 合法、端口范围合法。
2. 语义层：规则之间无矛盾；允许列表与拒绝列表的优先级符合预期；默认动作明确写死，不依赖平台默认值。
3. 影响面层：这条规则改动能触达哪些 VPC、哪些网段、哪些业务标签。把结果与变更单声明的范围比对，超出即拒绝。
4. 仿真层：用历史流量或影子流量跑一遍新旧策略，输出“新增拒绝”和“新增放行”的差异清单。
5. 灰度层：先对一个非核心 VPC 或一个低峰时段生效，观察指标后再全量。

AWS 的集中式网络检查方案在变更管理上提供了参考：它通过 GitOps 工作流来协作和管理 Network Firewall 配置的变更，并集中配置防火墙、防火墙策略与规则组，可覆盖成百上千个 VPC 与账号（Centralized Network Inspection on AWS）。把策略放进版本库的意义不只是“留痕”，而是让每一次变更都能被流水线拦截、被 diff 审阅、被回滚。

一个最小可用的策略门禁可以写成这样：

# policy-gate.yaml —— 示例，按实际平台字段调整
change:
  target: vpc-firewall-policy
  scope_vpcs: [vpc-prod-a, vpc-prod-b]
gates:
  - id: no-global-deny
    rule: "不得新增 src=0.0.0.0/0 dst=0.0.0.0/0 action=deny"
  - id: deny-delta
    rule: "新增拒绝条目数 <= 基线 * 1.2"
  - id: scope-match
    rule: "变更涉及的 VPC 必须全部出现在 scope_vpcs 中"
  - id: rollback-required
    rule: "必须附带可执行的回滚计划与责任人"

仿真怎么做才有意义

仿真不是“跑一遍不报错”。有用的做法是：取最近 7 天的 VPC Flow Logs 或防火墙会话日志，抽样出跨 VPC 的连接五元组，分别用旧策略和新策略做判定，输出三张表——新拒绝（最危险）、新放行（需要安全确认）、不变。新拒绝表里的每一条，都要业务方确认“这是预期阻断”，否则就是一次误阻断。这一步通常能在发布前拦下大部分事故，成本却远低于事后回滚。

上线后的观察指标

健康检查探针被自己的策略阻断，是集中式架构里非常典型的一次自伤：探针源地址落在某个业务网段里，新策略把该网段整体拒绝，负载均衡判定后端全部不健康，于是“防火墙没挂，业务全挂了”。

高可用与回滚：把“改回去”设计成一条命令

高可用不等于多开一台防火墙

多开实例只解决单点，不解决引流路径上的单点。需要同时确认：

• 集群是否跨可用区，且业务 VPC 到检查集群的路径在每个可用区都可达；
• 扩容是否是弹性的，流量突增时集群能否自动扩展而不是把会话丢弃；
• 控制面与数据面是否分离，控制台不可用时数据面是否继续按最后一份策略转发；
• 容量与配额，会话表、规则条数、日志投递速率都有上限，配额打满的表现往往就是“随机丢包”。

腾讯云的文档把 VPC 防火墙描述为分布式集群部署，通过调度算法在多个防火墙引擎之间做负载均衡与并行处理，并在流量突增时弹性扩容（CFW High Availability Specification）。这提示了一个运维事实：集群的“健康”不等于“容量充足”，需要单独监控每个引擎的负载分布，避免某几个引擎成为热点。

回滚要分层，且顺序不能反

误阻断发生时的第一反应常常是“把策略改回去”，但如果引流本身有问题，改策略是无效的。应按以下顺序判断并执行：

L1 是最快的止血手段，但它意味着一段时间内没有检查。所以旁路不能是“静默开关”，而必须是带时限、带告警、带事后补偿的动作：开启旁路即触发高优告警，15 分钟内必须有人确认，事后补做流量回溯分析，确认旁路期间没有异常流量通过。

变更审计要能回答三个问题

一次可复盘的变更记录，至少要能回答：谁在什么时候改了什么（精确到规则 ID 与路由条目）、审批链是谁、系统在什么条件下会自动回滚。前两个靠工单与 Git 提交记录，第三个靠自动化：把上文表格里的观察指标写成监控规则，满足条件即自动执行 L1 或 L2 回滚，并通知值班人。

自动回滚本身也需要防误触发。常见的做法是加“双条件”判定：指标异常 + 时间窗口内存在变更，两者同时满足才动作；同时对回滚脚本做幂等设计，避免重复执行把状态改乱。

落地检查表

变更前

• 引流范围、业务影响面、回滚责任人在变更单中明确；
• 策略已在版本库中完成 diff 审阅，默认动作显式写死；
• 仿真结果中的“新拒绝”条目已逐条确认；
• 逃生路由、管理面路径、探针路径已从检查范围中排除；
• 变更窗口避开业务高峰，并预留至少一次完整回滚的时间。

变更中

• 按“策略先就绪、引流后生效”或相反的既定顺序执行，不跳步；
• 每完成一个 VPC 或一批 VPC 暂停观察，确认指标无异常再继续；
• 全程开启路由变更审计与防火墙日志，确认日志链路没有中断。

变更后

• 24 小时内复核拒绝命中、新建连接失败率、跨 VPC 延迟；
• 确认无长期旁路残留，所有临时放行规则已回收；
• 更新资产清单与拓扑文档，把本次引流关系记录在案；
• 若发生过回滚，输出时间线复盘：触发信号、判定依据、执行耗时、旁路时长。

集中式防火墙架构真正的门槛，在于让“改错”这件事变得可发现、可拦截、可逆。把引流写成代码、把规则放进流水线、把回滚做成一条命令，这套治理动作的价值，在第一次误阻断发生的那天才会真正体现出来。而在此之前，它需要被当作常规运维的一部分持续演练——没有演练过的回滚方案，和没有回滚方案差别不大。