第194篇：CGNAT（运营商级 NAT）原理与端口块分配
关键词：CGNAT、NAPT、端口块分配、RFC 7671、464XLTE、NAT444、端口耗尽、运营商级NAT、IPv4地址复用
一、引言
在第193篇中，我们了解了 BRAS 的部署架构和 CGNAT 在城域网中的位置。本篇将深入 CGNAT 的内部工作原理，从 NAPT（Network Address and Port Translation）的映射机制讲起，逐步深入到运营商场景下最为关键的端口分配策略——端口块（Port Block）分配，以及双层 NAT（NAT444）架构。
理解 CGNAT 的底层机制，对于合理设计地址池规模、排查端口耗尽故障、以及规划向 IPv6 的平滑演进路线至关重要。
二、NAPT 映射机制详解
2.1 NAT 类型演进
NAT 经历了从简单到复杂的演进过程：
| NAT 类型 | 全称 | 转换内容 | 端口复用 | 典型场景 |
|---|---|---|---|---|
| Static NAT | 静态 NAT | IP ↔ IP 一对一映射 | 不支持 | 服务器发布 |
| Dynamic NAT | 动态 NAT | 内网 IP ↔ 公网 IP 池 | 不支持 | 早期出口路由器 |
| NATPT | NAT Protocol Translation | IPv4 ↔ IPv6 协议转换 | 不支持（已废弃） | 过渡期（已淘汰） |
| NAPT | Network Address and Port Translation | IP + 端口 ↔ 公网 IP + 端口 | 支持 | 家庭路由器、CGNAT |
| SNAT | Source NAT | 仅转换源地址 | 可选 | 出口安全隐藏 |
| DNAT | Destination NAT | 仅转换目的地址 | 不支持 | 服务器负载均衡 |
2.2 NAPT 数据转发流程
NAPT 是 CGNAT 的核心技术，它在转换 IP 地址的同时也转换传输层端口号，实现"多个内网地址共享一个公网 IP"的效果。
2.3 NAT 会话表结构
NAT 设备维护一张庞大的会话表，每条记录包含以下关键字段：
| 字段 | 说明 | 示例 |
|---|---|---|
| 私网源 IP | 内网用户源地址 | 10.8.1.100 |
| 私网源端口 | 内网用户源端口 | 50000 |
| 公网源 IP | 映射后的公网地址 | 59.43.1.5 |
| 公网源端口 | 映射后的公网端口 | 25000 |
| 目的 IP | 原始目的地址 | 203.0.113.10 |
| 目的端口 | 原始目的端口 | 80 |
| 协议类型 | TCP / UDP / ICMP | TCP |
| 状态 | NEW / ESTABLISHED / FIN_WAIT | ESTABLISHED |
| 超时计时器 | 空闲超时时间 | 3600s |
| 已传输字节 | 会话累计流量 | 15,234,567 bytes |
三、端口分配策略
3.1 端口资源计算
一个公网 IPv4 地址拥有 65536 个端口（0-65535），但在实际 CGNAT 部署中：
- 端口 0-1023 为熟知端口（Well-Known Ports），CGNAT 不分配
- 实际可用端口范围：1024-65535，共计 64512 个端口
- 理论上，1 个公网 IP × 64512 端口 ≈ 6.4 万个并发用户
但实际上，考虑到： - 每个用户通常同时保持多个连接（浏览器多个标签、APP 后台、操作系统服务调用等） - 保守估计每用户占用 50-100 个并发端口 - 1 个公网 IP 实际可承载约 600-1300 个并发用户
3.2 端口分配算法
CGNAT 设备分配端口时，需要遵循特定的分配策略以保证效率和公平性：
| 分配策略 | 描述 | 优点 | 缺点 |
|---|---|---|---|
| 顺序分配（Sequential） | 从最低可用端口开始顺序分配 | 实现简单 | 易产生碎片化 |
| 随机分配（Random） | 在可用端口池中随机选取 | 分配均匀，减少冲突 | 查找效率低 |
| 哈希分配（Hash-based） | 基于五元组哈希确定端口 | 确定性、可预测 | 哈希冲突需处理 |
| 端口块分配（Port Block） | 预分配固定端口块给用户 | 用户可预测端口范围 | 端口利用率低 |
3.3 端口耗尽故障分析
端口耗尽是 CGNAT 最常见的故障之一。以下案例展示了一个典型的端口耗尽场景：
# 查看 NAT 地址池端口使用率
<BRAS-1> display nat address-group 1
Address Pool: 59.43.1.1 - 59.43.1.16
Port Allocation:
IP 59.43.1.1 : Used 64,200 / 64,512 (99.5%)
IP 59.43.1.2 : Used 63,891 / 64,512 (99.0%)
IP 59.43.1.3 : Used 61,023 / 64,512 (94.6%)
...
Overall: Used 1,024,000 / 1,032,192 (99.2%)
# 查看端口碎片化程度
<BRAS-1> display nat port-fragmentation 1
IP 59.43.1.1:
Fragmented Blocks: 12,450
Largest Free Block: 3 ports
Fragmentation Ratio: 85.2%
端口碎片化严重意味着虽然仍有少量空闲端口，但已经分散为零星的"孤岛"，无法分配给需要连续端口或大量并发连接的用户。
四、端口块分配（RFC 7671）
4.1 为什么需要端口块分配
传统 NAPT 中，CGNAT 设备从全局端口池中为每个用户的每个连接动态分配端口。这种方式存在一个严重问题：用户（尤其是家庭路由器后的多层 NAT 场景）无法提前获知自己将被分配到哪些端口，导致以下问题：
- 端口预测困难：内网中的服务器发布（如游戏私服、摄像头、远程桌面）无法在 CGNAT 上做静态端口映射
- 端口冲突风险：不同用户可能分配到相同公网 IP 的相同端口，引发端口碰撞
- IPv4 客户端受限：某些应用（如 P2P、VoIP）需要特定的端口范围
RFC 7671 提出的 Port Control Protocol (PCP) 和端口块预分配机制，允许 CPE（客户终端设备）获知自己在 CGNAT 上的端口块范围。
4.2 端口块分配架构
4.3 端口块大小选择
端口块大小的选择直接影响 CGNAT 的效率和端口利用率：
| 端口块大小 | 每IP承载用户数 | 适用场景 | 利用率 |
|---|---|---|---|
| 16 端口 | ~4000 用户/IP | IoT 设备、低并发用户 | 极低（多数端口闲置） |
| 64 端口 | ~1000 用户/IP | 普通家庭宽带 | 中等 |
| 256 端口 | ~250 用户/IP | 高带宽家庭用户 | 较高 |
| 1024 端口 | ~64 用户/IP | 企业用户、高并发需求 | 高 |
4.4 华为 VRP 端口块配置
# 端口块分配配置
<BRAS-1> system-view
[BRAS-1] nat instance CGNAT-PB
# 配置端口块策略
[BRAS-1-nat-instance-CGNAT-PB] port-block allocate enable
[BRAS-1-nat-instance-CGNAT-PB] port-block size 64
[BRAS-1-nat-instance-CGNAT-PB] port-block range 20000 60000
[BRAS-1-nat-instance-CGNAT-PB] nat address-group 1
# 为不同用户组分配不同大小的端口块
[BRAS-1] nat policy rule name Premium-Users
[BRAS-1-nat-policy-rule-Premium-Users] source-address 10.10.0.0 0.0.255.255
[BRAS-1-nat-policy-rule-Premium-Users] action nat instance CGNAT-PB port-block-size 256
[BRAS-1-nat-policy-rule-Premium-Users] quit
[BRAS-1] nat policy rule name Standard-Users
[BRAS-1-nat-policy-rule-Standard-Users] source-address 10.8.0.0 0.0.255.255
[BRAS-1-nat-policy-rule-Standard-Users] action nat instance CGNAT-PB port-block-size 64
[BRAS-1-nat-policy-rule-Standard-Users] quit
五、NAT444（双层 NAT）架构
5.1 NAT444 概念
NAT444 是在 CGNAT 基础上的"双层 NAT"架构。在 CPE（光猫/家庭路由器）上再进行一层 NAT（称为 CPE-NAT 或 S-NAT），然后流量进入运营商的 CGNAT（称为 B-NAT 或 Carrier-NAT）进行第二次 NAT 转换。
5.2 NAT444 中的地址规划
| 层级 | 地址段 | 标准 | 说明 |
|---|---|---|---|
| 用户内网 | 192.168.0.0/16、10.0.0.0/8 | RFC 1918 | CPE-NAT 的内网侧 |
| CPE-CGNAT 间 | 100.64.0.0/10 | RFC 6598 (Shared Address Space) | 连接 CPE-NAT 外网与 CGNAT 内网 |
| CGNAT 公网侧 | 运营商公网地址段 | 运营商自有 | 真实公网 IP，连接互联网 |
5.3 NAT444 优缺点
| 优点 | 缺点 |
|---|---|
| 最大化 IPv4 地址复用（两层 NAT 叠加） | 端到端连通性严重受损 |
| 用户内网地址完全隐藏，安全性提升 | 双层延迟叠加，NAT 处理开销增加 |
| 运营商可灵活调度 CPE-NAT 地址池 | P2P 应用、在线游戏、视频通话体验下降 |
| CPE-NAT 地址池独立管理 | 故障排查极其困难（需要逐层跟踪 NAT 映射） |
5.4 NAT444 故障排查工具
# 在 CGNAT 设备上查看双层 NAT 会话
<CGNAT> display nat session verbose source-ip 100.64.0.10
Session Detail:
Layer 1 (CPE-NAT):
Original Source : 192.168.1.100:50000
Translated Source: 100.64.0.10:30000
Layer 2 (CGNAT):
Original Source : 100.64.0.10:30000
Translated Source: 59.43.1.5:20000
Final Destination : 203.0.113.10:80
Protocol : TCP
State : ESTABLISHED
Bytes Transferred : 2,345,678
六、CGNAT 演进方向
6.1 从 CGNAT 到 IPv6 的过渡
CGNAT 本质上是 IPv4 地址枯竭时代的权宜之计。真正的解决方案是推动 IPv6 全面部署，以下是常见的过渡路径：
| 过渡阶段 | 技术方案 | 说明 |
|---|---|---|
| 阶段一 | 纯 IPv4 + CGNAT | 当前主流，双/三层 NAT |
| 阶段二 | IPv4/IPv6 双栈 + CGNAT | 逐步引入 IPv6，IPv4 仍通过 CGNAT |
| 阶段三 | DS-Lite / 464XLTE | IPv4 over IPv6 隧道，消除 CGNAT |
| 阶段四 | 纯 IPv6 | 最终目标，无需 NAT |
6.2 CGNAT 监测指标
| 监测指标 | 阈值告警 | 说明 |
|---|---|---|
| 会话表使用率 | > 80% 预警，> 90% 告警 | 衡量当前 NAT 负载 |
| 端口池使用率 | > 85% 预警，> 95% 告警 | 预示端口即将耗尽 |
| CPS 峰值 | > 80% 设备能力 | 新建连接速率过高 |
| NAT 超时会话比例 | > 5% | 大量僵死会话占用资源 |
| 端口碎片化率 | > 70% | 端口分配效率下降 |
七、总结
CGNAT 是当今互联网接入的核心基础设施，其原理看似简单——IP 加端口的映射转换，但在大规模部署中却涉及复杂的端口分配策略、多层 NAT 协同、以及精细的性能监控。
| 核心技术 | 关键要点 | 最佳实践 |
|---|---|---|
| NAPT 映射 | IP+端口到公网IP+端口的动态转换 | 会话超时精细化调优 |
| 端口分配算法 | 顺序/随机/哈希/端口块 | 按用户等级差异化分配 |
| 端口块分配 | RFC 7671，预分配固定端口范围 | 高端用户分配大端口块 |
| NAT444 | 双层NAT最大化地址复用 | 谨慎使用，关注用户体验 |
| 性能监控 | 会话表、端口池、CPS | 实时监控+自动扩容 |
思考题：
- 为什么 CGNAT 不使用端口 0-1023？如果某个用户的应用恰好需要使用熟知端口（如 80 或 443），在 CGNAT 环境下如何实现？
- NAT444 架构中，如果 CPE-NAT 设备重启，CGNAT 上的会话表会发生什么变化？用户业务会中断吗？
- 端口块分配策略虽然解决了端口预测问题，但为什么会导致端口利用率下降？如何权衡端口块大小与利用率之间的关系？
下篇预告：第195篇《DS-Lite 轻量级双栈：IPv4 over IPv6》将探讨如何在 IPv6 骨干网上透明承载 IPv4 流量，彻底消除 CGNAT 的双层 NAT 困境，让用户重新获得端到端的 IPv4 连通性。