功能概述

AWS 近期为网络负载均衡器（Network Load Balancer，NLB）引入了监听规则（listener rules）特性。该能力允许 NLB 根据连接的源 IP 地址类型（IPv4 或 IPv6），将流量路由至对应地址类型的目标组。对于运行双栈（dual-stack）架构的用户，现在可以使用单个 NLB 同时服务 IPv4 与 IPv6 客户端，且无需协议转换，完整保留两端原始客户端 IP。

原有双栈方案的局限

在监听规则推出前，双栈 NLB 虽能接受来自 IPv4 和 IPv6 客户端的连接，但监听器的默认转发动作只能指向单一 IP 类型的目标组。这导致两种变通方案：

  • 部署两套负载均衡器：分别为 IPv4 和 IPv6 创建 NLB，并通过 DNS 的 A 与 AAAA 记录拆分客户端。该方式需维护两套监听器、目标组、健康检查及计费项，成本与运维负担翻倍。
  • 单 NLB 配合 Proxy Protocol v2：将所有流量导向一个目标组，由 NLB 进行地址转换，目标侧仅见到负载均衡器地址；若需恢复真实客户端 IP，必须在目标应用启用 PPv2 并解析协议头，增加了集群内的改造开销。

对于依赖客户端 IP 执行安全策略、访问日志审计或合规校验的业务，源地址丢失是不可接受的。

监听规则的工作机制

新监听规则在 NLB 监听器上提供条件路由。规则匹配维度为连接的源 IP 地址类型（网络层 L3 属性），而非 ALB 的七层属性（如主机头、路径）。规则按优先级数字由小到大依次评估，命中即转发至对应目标组；未命中则落入监听器默认动作。

典型双栈配置包含两条规则：

  • IPv4 规则：将源地址为 IPv4 的连接转发至 IPv4 目标组；
  • IPv6 规则：将源地址为 IPv6 的连接转发至 IPv6 目标组。

由于每个地址族的流量都进入同类型目标组，双向均无协议转换，IPv4 与 IPv6 客户端的原始源 IP 均得以端到端保留。该特性支持 TCP、UDP、TCP_UDP、TLS 协议，且可作用于已有双栈 NLB，无需重建。

配置实践简例

以下为通过 AWS CLI 整合双栈客户端的核心步骤（需 CLI 版本 2.35.24 以上）：

  1. 创建双栈 NLB，指定具备 IPv6 CIDR 的子网。
  2. 分别创建 IPv4 与 IPv6 目标组，指向同一应用层。
  3. 创建监听器，默认动作指向其中一个目标组（如 IPv4）作为兜底。
  4. 添加监听规则，优先处理 IPv4（priority 10）与 IPv6（priority 11）源流量。
aws elbv2 create-rule \
  --listener-arn <listener-arn> --priority 10 \
  --conditions '[{"Field":"source-ip","SourceIpConfig":{"IpAddressType":"ipv4"}}]' \
  --actions '[{"Type":"forward","TargetGroupArn":"<ipv4-tg-arn>"}]'

控制台操作同样支持，在 NLB 的“Listeners and rules”标签页中可图形化添加规则并设定优先级。

对读者的意义与技术解读

对于运维、SRE 与网络工程师，该特性直接降低了双栈过渡期的架构复杂度。以往为保留真实客户端 IP，往往被迫拆分负载均衡栈或改造应用层解析 PPv2，如今通过网络层路由即可实现透明转发。这意味着：

  • 可观测性提升：后端服务、VPC Flow Logs、安全组与网络 ACL 均可见原始客户端地址，便于结合本站提供的 Ping、Tcping 或 HTTP 测速工具进行端到端链路排障与延迟分析。
  • 成本与风险收敛：单一 NLB 减少了资源重复与配置漂移可能，尤其在多可用区与跨境链路场景下，简化架构即减少故障面。
  • 合规友好：金融、政务等需留存访问者真实 IP 的场景，无需妥协于协议转换。

建议正在规划 IPv6 演进的团队评估此特性，将其纳入双栈运维标准，并利用监控告警校验规则命中情况，确保 IPv4/IPv6 流量均按预期分发。

迁移考量

已有双栈 NLB 可直接附加规则，但需注意目标组地址类型必须与会话匹配。若原有架构依赖 PPv2，可逐步将目标组拆分为同类型并切换规则，过程中保持默认动作兼容，避免流量中断。