Network Firewall 部署小指南（四）通过私网 NAT 实现零停机变更

AWS Network Firewall（以下简称 NFW）是一种高度可用和托管的网络安全服务，旨在为 Amazon Virtual Private Cloud（VPC）提供全面的入站和出站网络流量检查和防护功能。近年来，采用 NFW 和 NAT 网关来管理和控制出站流量已成为云上 VPC 的标准安全措施，其部署形态可参考出站流量检查分布式部署模型。

笔者最近遇到的客户案例，需求是仅检测和过滤 VPC 私有子网到互联网的出站流量，但现有架构中 Elastic Load Balancing（ELB）和 NAT 网关位于同一公有子网，传统出站流量检查模型将导致 ELB 流量也经过检测。为满足需求且避免停机，本文提出一种新的部署模型，通过引入私网 NAT 隔离已有的公有子网入站流量，部署 NFW 检测和过滤私有子网到互联网的出站流量。该模型不影响现有公网 NAT，避免了 NAT 地址变化带来的风险，实现了变更过程零停机的部署方案。

架构说明

图 1 展示了现有 VPC 的网络架构示意图，VPC 跨越了两个可用区，每个可用区两个子网，分别为应用私有子网（Private subset）、NAT 网关公有子网（Public subnet），ELB 和 NAT 网关位于同一个公有子网。

图 1. 未改造前的网络架构图

采用图 2 传统的出站流量检查部署模型，将 NFW 部署在 NAT 公有子网和应用私有子网之间，会导致 ELB 的流量也会经过 NFW。这样的部署模型无法满足客户仅过滤 VPC 私有子网内的资源到互联网出站流量的需求。

图 2. 使用 NFW 的传统部署方案

另外，客户已将 NAT 的出口公网 IP 关联到第三方厂商的白名单中，变更 NAT IP 意味着变更第三方厂商的白名单。且当前对接的第三方厂商较多，变更带来的切换成本较大。客户希望复用原有 NAT 网关公有 IP 地址，从而不改变第三方厂商的白名单。

为实现仅过滤 VPC 私有子网内的资源到互联网出站流量，保持 NAT 网关 IP 地址不变，我们可以将 NAT 拆分到单独公有子网，来实现 ELB 流量隔离，部署架构如图 3，共需要占用 2个/28 子网。由于 NAT 绑定的弹性 IP（EIP）无法直接迁移，为了保持 NAT 网关 IP 地址不变，需要先删除原 NAT 网关，释放 EIP，在创建新 NAT 网关的时候重新绑定原 EIP，此过程会带来 5-6 分钟的网络中断。

图 3. 拆分公有子网的 NFW 部署架构图

另外，我们可以采用临时变更私有子网出口流量到备用 NAT 所在网络来实现变更过程的平滑。具体做法是将私有子网出口流量通过 Transit Gateway（TGW）切换到其他 VPC 的备用 NAT 网关^[1]，删除并重新创建本 VPC 的 NAT 网关到独立子网，绑定原来的 IP 地址，最后将出网流量切回本 VPC 的 NAT 网关。该方案操作相对复杂，并非本文重点，故不再做展开。

我们还可以采用了新增私有 NAT 网关的部署方案，即为 VPC 添加了两个子网，防火墙私有子网（GWLBE subset），NAT网关私有子网（SNAT subnet），将 NFW、私有 NAT 网关，部署在公有子网 NAT 网关，应用私有子网之间，实现了 NFW 检测和过滤应用私有子网内资源的出站流量，且保持原有公有子网 NAT 网关 IP 地址不变的零停机部署方案。如下图 4 所示，改造后的网络架构跨越两个可用区，每个可用区包括 4 个子网，分别为应用私有子网、防火墙私有子网、私有 NAT 网关子网、公有子网。

图 4. 添加私网 NAT 的 NFW 部署架构图

我们假设当前 VPC 网段为 10.2.0.0/16，其中一个 AZ 已有公有子网 10.2.0.0/20 和（受保护的）私有子网 10.2.128.0/20，新增 NFW 子网 10.2.96.16/28 和私网 NAT 子网 10.2.96.0/28，受保护子网的数据流走向如图 5 所示，具体过程如下：

私有子网 EC2 出公网的数据包匹配默认路由，被发往 NFW
数据包在 NFW 中做策略匹配，若判定为 Pass，则匹配默认路由，被发往私有 NAT 网关
私有 NAT 网关做 SNAT 功能，源地址转换为该 NAT 的私有地址，同时匹配默认路由，发往公有子网中的（Public）NAT 网关
公有子网中的（Public）NAT 网关做 SNAT 功能，将源地址转换为该 NAT 的公有地址，同时匹配默认路由，发往互联网网关
互联网网关将数据包发送到互联网
=== 回包 ===
互联网网关将回包发送到（Public）NAT 网关
（Public）NAT 网关将数据包发往私有 NAT 网关
私有 NAT 网关将目的地址转换为 EC2 IP，匹配 ‘10.0.0.0/16 via GWLEB1’ 的路由，将数据包转发到 NFW
数据包在 NFW 中做策略匹配，若判定为 Pass，则匹配 ‘10.0.0.0/16 via Local ’ 的路由，将数据包发送到 EC2 所在的私有子网，最终发给 EC2

图 5. 单一 AZ 中的流量流向示意图

如下汇总了本文提到的 4 个部署架构，并对其优缺点进行对比，可作为方案选型的参考：

编号	方案说明	优点	缺点
1	传统方案：公有子网的流量也接入 Firewall，见图 2	无需做子网拆分，改动较小；操作简便，网络中断时间短。	公网业务流量也接入了 NFW，影响既有业务流；全部公网流量较多，成本较高。
2	拆分公有子网方案 1：删除旧 NAT 并重新部署，沿用原有 NAT IP 地址，见图 3	公网业务无需变动；操作相对简便。	NAT 迁移过程网络中断时间较长
3	拆分公有子网方案 2：通过临时切换出网流量到备用 NAT，见图 3	公网业务无需变动；网络中断时间较短。	涉及多个 VPC 的路由切换，操作复杂；多次切换会影响现有内网出口连接；每个第三方的业务白名单都需要至少配置 2 个 NAT IP。
4	私有子网 NAT 方案，见图 4	不需要变更已有的 NAT 网关和业务公有子网；网络中断时间极短。	新增子网后，合共需要占用 2 个/28 子网。新增 NAT 网关，此部分费用不能减免。

实施与测试

我们延续上一章节提及示例，在单 AZ 下部署该架构。

准备工作（不影响业务）：

创建 NFW 子网，分配/28 位掩码 CIDR；创建私有 NAT 网关子网，分配/28 位掩码 CIDR。
在 NFW 子网中，创建 NFW。
完成 NFW 基础配置与策略配置，保持默认动作为 pass，可参考 AWS Network Firewall 最佳实践中的配置方法^[2]。
创建私有类型的 NAT 网关。
创建 NFW 路由表，关联 NFW 子网，添加 0/0 默认路由指向新创建的私有 NAT 网关。
创建私有 NAT 网关路由表，关联私有 NAT 网关子网，添加 0/0 默认路由指向原有的公有 NAT 网关，修改 VPC CIDR 指向从 local 修改成 NFW endpoint。

切换步骤（现有连接会中断，应用需要重连）：

把业务子网路由表的 0/0 从 NAT 网关修改成 NFW endpoint。

测试（贯穿整个操作过程）：

在私有子网中的 EC2 环境中访问互联网，通过长 Ping 确认变更过程访问延迟正常。可以看到，变更当下 ping 包的延迟增加 1-2ms，而后快速恢复。

** 如果使用 SSM-agent 的方式访问该私有子网 EC2 实例，会发现 session 在操作时被中断，这是由于操作将影响该机器的公网出口连接，SSM-agent 需要重新连接并创建新的 session；如果你通过部署在公有子网的 EC2 跳板机访问该私有子网 EC2 实例，则内网 SSH 连接并未中断，这是由于我们没有修改私有子网 “10.2.0.0/16 via Local” 这条路由规则，内网流量没有受到影响。

为 NFW 的策略添加一个规则组，该规则组将禁止用户访问 google.com。

配置 out-dns 规则组后，curl www.google.com 将超时，curl www.baidu.com 则正常；而 ping 没有受到影响，这是因为 ICMP 包并没有被阻拦。

通过 NFW 的监控我们也可以看到，Stateful DroppedPactets 指标上升。

总结

本文介绍了一种在 AWS 中使用 AWS Network Firewall（NFW）检查和过滤私有子网出站流量的新部署架构，该方案无需变更现有 NAT 网关和公网业务子网，并能实现变更过程的零停机。在详细阐述了其部署模型、数据流向、实施步骤之外，也对传统 NFW 部署模式等几个可选方案进行对比分析。总的来说，新架构平衡了业务连续性和安全性需求，为企业客户提供了一种可取的 NFW 部署选择。

参考文档

[1] 在大规模环境中使用 NAT 网关与多个 VPC 结合

[2] AWS Network Firewall 最佳实践

亚马逊AWS官方博客