使用 NAT 网关解决 AWS Global Accelerator 和 NLB 连接 Direct Connect 环境下 UDP 通信问题

背景

客户在 IDC 基础上，基于 AWS 构建跨区域、高可用且低延迟的应用架构时，AWS Global Accelerator (AGA)、Network Load Balancer (NLB) 和 Direct Connect (DX) 的组合是企业常用的解决方案。当涉及到 UDP 协议通信时，这种架构可能会面临路由不对称导致的通信问题。本文将深入分析这一问题，并提出基于 NAT 网关的解决方案，确保 UDP 协议下的通信顺畅。

问题分析：路由不对称导致的 UDP 通信障碍

TCP 与 UDP 协议处理差异

在典型的 AGA-NLB-DX 架构中，当我们使用 IP 模式目标组连接到客户 IDC 环境时：

• TCP 协议情况：TCP 是面向连接的协议，NLB 在 TCP 协议下可以关闭目标组的保留源 IP 功能，从而实现会话跟踪和正确路由回包。
• UDP 协议情况：UDP 是无连接协议，NLB 在 UDP 协议下无法关闭保留源 IP 功能，可以参考这个链接，这导致数据包必须保持原始源 IP 地址，当需要基于UDP同时收发数据的场景下，例如客户基于 UDP 自建 Quic 协议，就会存在上述问题。

路由不对称问题详解

路由不对称是指请求和响应走不同的网络路径，具体表现为，如下图所示：

1. 请求路径详解：

• 用户请求首先达到 AGA 端点
• AGA 将请求转发到与之关联的 NLB
• NLB 接收请求并通过 DX 连接将其转发到目标组中的 IDC IP
• 由于 UDP 协议下保留源 IP 功能无法关闭，流量到达 IDC 时保留了原始源 IP（客户端或 AGA 的公网 IP）

2. 响应路径详解：

• IDC 服务器生成响应包，目的地址是原始请求的源 IP
• 响应包试图直接返回给客户端或者 AGA 的公网 IP（而非通过请求时的原路径返回）
• 由于 DX 和 IDC 的互联网路由配置的不同，响应包会尝试通过 IDC 自己的互联网而非 DX 返回
• 这导致响应包可能被防火墙拦截、路由表无法正确导向，或者源地址与会话不匹配，最终被丢弃

3. 问题本质：

• UDP 协议没有建立正式的会话状态，依赖于 IP 地址和端口进行通信
• NLB 将带着源 IP 的数据发送到 IDC 的 Target 后，由于 Target 会利用目的地址路由查找机制，匹配 IDC 的互联网出口路由进行回包，导致数据包不会通过 DX 返回给 NLB（当响应包通过与请求不同的路径返回时，无法被正确关联到原始请求）
• 网络设备无法正确识别和处理这些”无主”的响应包

表现症状

在路由不对称的 UDP 通信中，常见的问题表现包括：

• 请求发出后没有响应返回
• 网络抓包显示出站包正常，但入站包缺失
• 非单向连通性（客户端到服务器可通，服务器回客户端不通，例如 Quic）

解决方案：引入 NAT 网关创建对称路由

为解决上述问题，我们设计了一种优化架构，核心是引入 NAT 网关来确保路由对称性。

架构改进详解

1. 保留原有架构基础：继续使用 AGA、NLB 和 DX 连接构成的主体架构

2. 引入 NAT 网关：在私有子网中添加 NAT 网关

3. 路由表精确调整：

• 公有子网增加路由条目，将经过 NLB 的流量指向 NAT 网关
• 私有子网增加路由条目，确保回程路由指向 NLB 的 ENI（弹性网络接口）

NAT 网关如何解决路由不对称问题

引入 NAT 网关后，请求和响应路径均发生了关键变化：

1. 改进后的请求路径：

• 用户请求经由 AGA 到达 NLB
• NLB 将请求转发至公有子网
• 关键改进：公有子网的路由表将目的地为 IDC 的 IP Target 流量引导至 NAT 网关
• NAT 网关执行源 IP 转换，使用自己的 IP 地址作为源 IP
• 转换后的请求通过 DX 到达客户 IDC

2. 改进后的响应路径：

• IDC 服务器响应数据包，发现目的地址为 NAT 网关的 IP
• 从 IDC 来看，NAT 网关 IP 地址是经过 DX 的线路学习到的
• 所以响应包会通过 DX 返回到 AWS 网络
• NAT 网关接收响应包并查询转换表
• NAT 将目的地址还原为原始请求的源地址（客户端或 AGA 的公网 IP）
• 响应包正确返回到 NLB，然后经由 AGA 返回给用户

当 UDP 数据包通过改进后的架构时，数据流向发生了变化，不再经过 IDC 的 Internet 出口：

1. 客户端请求流程详解

用户 → AGA → NLB → 公有子网 → [路由表] → NAT 网关(源IP转换) → DX → 客户IDC

源 IP 地址在经过 NAT 网关时被替换为 NAT 网关的 IP 地址，这一点至关重要。IDC 服务器接收到的请求看是来自 NAT 网关，而非 NLB 或原始客户端。

2. 响应流程详解

客户IDC → DX → NAT网关(目的IP转换) → [路由表] → NLB的ENI → NLB → AGA → 用户

IDC 服务器发送响应时，将 NAT 网关的 IP 作为目的地址。NAT 网关接收到响应后，查询其维护的转换表，将目的地址还原为原始请求的源地址，然后正确路由回 NLB。

通过这种设计，我们成功实现了请求和响应的对称路由，解决了 UDP 通信的核心障碍。

NAT 网关的高级配置：增强端口容量与扩展性

NAT 网关附加 IP 地址的优势

AWS NAT 网关支持附加多个弹性 IP 地址（最大 7 个，可尝试通过 case 提升 limit），这一特性为高并发 UDP 通信提供了显著优势：

1. 扩展端口容量：

• 每个 NAT 网关 IP 地址提供最多 55,000 个并发连接（理论值，有些端口会被系统默认占用）
• 通过附加额外 IP 地址，可以线性扩展最大并发连接数
• 例如：附加 5 个 IP 地址可支持高达 275,000 个并发连接

2. 动态端口分配优化：

• NAT 网关实现了高效的端口分配算法
• 基于流的方式负载分担到所有可用 IP的地址进行端口转换
• 提供平滑的连接建立体验，不会因端口限制导致服务中断

实际应用中的规模优势

在实际部署中，NAT 网关的多 IP 配置带来的扩展优势非常显著：

游戏服务器场景：大量玩家同时连接到 IDC 内的游戏服务器

• UDP 通常用于游戏实时通信
• NAT 网关多 IP 确保每个游戏会话都有足够的端口资源

IoT 设备通信：大量设备向 IDC 内的后端服务发送遥测数据

• 突发性连接激增不会导致端口资源耗尽
• 确保所有设备通信的可靠性

详细配置步骤

以公有子网 B 和私有子网 B 为例：

1. 在私有子网 B 部署 NAT 网关 B：

• 创建 NAT 网关（Private 类型）
• 根据预估流量规模，考虑附加额外 IP 地址

2. 配置公有子网 B 的路由表：

• 添加路由条目，将目的地为客户 IDC 中 NLB 的 IP Target 范围的流量路由至 NAT 网关 B
• 例如：10.x.x.0/24（客户 IDC NLB 的 IP Target）-> nat-gateway-id-B

3. 配置私有子网 B 的路由表：

• 添加路由条目，将返回流量指向 NLB 的 ENI
• 例如：0.0.0.0（返回客户端的流量）-> eni-nlb-interface-id
• 确保 NAT 网关处理的流量能正确返回给 NLB

4. 验证路由对称性：

• 使用 traceroute 或网络抓包工具验证请求和响应路径
• 确认 UDP 流量可以完整往返

成本效益分析

NAT 网关的引入确实会带来额外成本：

成本构成

1. 固定费用：

• NAT 网关每小时运行费用
• 每个附加 IP 地址的费用

2. 可变费用：

• 数据处理费用（按 GB 计费）
• 跨可用区数据传输费用

总结

通过在 AGA-NLB-DX 架构中引入 NAT 网关并实施精细的路由配置，我们成功解决了 UDP 协议下由于路由不对称导致的通信问题。NAT 网关的多 IP 特性进一步提升了此架构的扩展能力，使其能够支持极高并发连接数的 UDP 通信场景。

这种解决方案保持了原有架构的优势，同时增强了对 UDP 协议的支持能力。尽管 NAT 网关会带来一定的成本增加，但其提供的连接稳定性、扩展性和对业务连续性的保障，使其成为解决 UDP 通信问题的高性价比选择。

本篇作者