**概述**：你手机上网用的那个“公网IP”，很可能不是你一个人的——它背后挤着几百上千个用户。这一切的幕后装置叫 CGNAT（运营商级NAT）。它平时安静，一出问题就是最刁钻的那类：单用户可复现、批量难归因，“部分网站打不开”“游戏联机失败”“账号莫名被封”全是它的锅。本文以 IETF 两份核心文档——[RFC 6269《Common Issues with IP Address Sharing》](https://www.rfc-editor.org/rfc/rfc6269)与 [RFC 7422《Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments》](https://www.rfc-editor.org/rfc/rfc7422)——为解读主轴，把 CGNAT 的原理账、故障账和日志合规账一次算清，并给出一份一线排查流程与经验清单。读者对象：核心网/数通运维工程师、网络优化与支撑系统同事。 ## 目录 - 一、先算账：为什么一千人挤一个IP - 二、五分钟原理：NAT444、地址池与端口块 - 三、四类高频故障：全都写在RFC里的坑 - 四、日志海啸：合规账单与RFC 7422的算术 - 五、一次典型排查的完整推演 - 六、写给同行的十条经验 - 结语 ## 一、先算账：为什么一千人挤一个IP IPv4 只有约 43 亿个地址，而全球联网设备早已是百亿量级。这场枯竭是有明确时间表的：APNIC（亚太）在 2011 年 4 月用完最后一个 /8，RIPE NCC（欧洲）在 2012 年 9 月见底，ARIN（北美）2015 年 9 月宣告枯竭，2019 年 11 月 RIPE 分完最后的 /22，自由池彻底清零。此后想拿新地址只有一条路——去 IPv4 交易市场买二手，据行业交易报道，单个地址价格已炒到几十美元，一个 /24 卖出上百万美元的新闻并不稀奇。 对运营商来说，账很好算：一千万宽带用户，如果人手一个公网IP，光买地址就是一笔天文数字，而且有钱也未必买得到。于是行业找到了那个心照不宣的答案：**用户侧发私网地址，出口处做一次大地址翻译**。这就是 CGNAT（Carrier-Grade NAT），也叫 NAT444——用户私网、运营商侧再来一层NAT，一个公网IP背后叠几百上千个用户。 移动网更彻底。3GPP 体系下 UE 拿到的 IPv4 地址本来就是运营商内网地址（10/8 居多），所有流量从 PGW/UPF 出来后几乎必然要过一道NAT才能访问互联网。换句话说，**在移动核心网干活的工程师，你的用户每天都在 CGNAT 后面**，只是它不出事时没人记得它。 有一个容易被忽略的细节：IETF 专门为 CGNAT 的内层划了一个段——100.64.0.0/10（RFC 6598，“共享地址空间”）。你在现网看到用户地址是 100.64.x.x，基本可以断定这是 CGNAT 架构，而它既不是私网地址也不是公网地址，防火墙策略、路由规划、日志系统稍不留神就会把它当普通地址处理，埋下第一批坑。 ## 二、五分钟原理：NAT444、地址池与端口块 CGNAT 的本质不复杂：把「用户私网IP + 端口」映射到「公网IP + 公网端口」，靠一张会话表维持状态。真正的工程含量全在参数里。 先说三个关键构件： - **地址池**：对外可用的公网IP集合。注意公网IP的 TCP/UDP 可用端口约 64K，一个IP理论上限也就六万多个并发端口，池子大小直接决定并发容量。 - **端口块（port-block）**：为了管理和溯源，多数部署把一个公网IP的端口切成块（比如每块 1024 或 4096 个端口），按块分给用户。一个 4096 端口的块意味着一个IP最多服务 16 个用户。 - **会话表**：五元组映射 + 超时定时器。表容量和超时时间是 CGNAT 的两大命门。 **表1：CGNAT 行为基线（IETF 标准要求摘录）** | 参数项 | 基线要求 | 出处 | |---|---|---| | 映射方式 | 应支持端点无关映射（EIM）：同一内网端点对外映射结果保持一致 | RFC 4787 | | UDP 映射保活 | 不得短于 2 分钟，工程上普遍取 5 分钟量级 | RFC 4787 | | TCP ESTABLISHED 超时 | 不得低于 2 小时 4 分钟（7440 秒） | RFC 5382 | | 回环互访（hairpinning） | 同一NAT后两用户互访，被列为明确要求项 | RFC 4787 | | ICMP 翻译行为 | 与 TCP/UDP 一致地对内网主机做端点标识翻译 | RFC 5508 | | 按用户限制能力 | 要求具备按用户限制会话/端口、并支撑溯源的日志能力 | RFC 6888 | 需要说明：上表是标准给所有 CGN 实现划的公共基线，具体默认值与可调范围，标准允许多种实现，以各厂家官方文档为准。但现网最大的教训恰恰在于——**很多设备出厂默认值并不落在基线上**。笔者见过 TCP ESTABLISHED 超时被配成一小时、UDP 只有 30 秒的现网配置，省的是会话表内存，坑掉的是全网的长连接和推送通道。 ## 三、四类高频故障：全都写在RFC里的坑 RFC 6269 专门用一整篇文档罗列了地址共享的“副作用清单”。对照一线经验，故障基本逃不出四类： **第一类：端口与会话耗尽。** 单用户被分配的端口块用完，新连接建不起来——典型表现是“网页一半打得开一半打不开”、下载到一半速率骤降。更隐蔽的是病毒或P2P类应用在端口块内疯狂建会话，把同块用户的额度也吃光。RFC 6888 为此专门要求 CGN 具备按用户限制会话数的能力，这条要求落地与否，直接决定你是“精准限流一个异常用户”还是“全区域用户陪葬”。 **第二类：超时配置失当。** 手机端的即时消息、推送、心跳全靠长连接活着。UDP 超时太短，连接被反复掐断重建，用户感知是“消息要等、推送迟半天”，后台感觉是信令量莫名上涨（重连风暴），终端电池加速耗电。这类故障最冤：锅出现在 CGNAT，投诉却全砸在无线和核心网头上。 **第三类：回环与ALG。** 同一个 CGNAT 后面两个用户互访，报文本应“绕回”内部完成翻译（hairpinning）。这一项支持不佳时，用户访问同城同区域的服务反而绕出去绕不回来。ALG（应用层网关）则是另一个雷区：SIP、FTP 这类报文里内嵌地址协议的应用，ALG 自作聪明改写内嵌地址，改错了就表现为“注册成功通话单通”“传真必失败”。 **第四类：误伤与信誉污染。** 这是 CGNAT 最反直觉的一类。一个公网IP后面一千个人，前任干了坏事，IP 进了黑名单，继任者无辜背锅——发邮件被反垃圾系统拦截（Spamhaus 的 PBL 名单从设计上就默认“共享地址段不该直接发信”）、访问网站疯狂弹验证码、游戏或社交账号被平台风控误封。RFC 6269 还专门点名了执法场景：靠 IP 追踪当事人，在地址共享时代可能定位到一整批无辜用户，溯源必须依赖运营商的映射日志。 **表2：症状速查表（一线经验版）** | 现象 | 高概率根因 | 首查动作 | |---|---|---| | 游戏联机失败、NAT类型严格 | 双层NAT，UPnP 穿不透 CGNAT | 确认用户是否在CGNAT侧、有无公网选项 | | 部分网站间歇性打不开 | 端口块或会话表耗尽 | 查单用户会话数、会话表占用率 | | 推送延迟、消息迟迟不到 | UDP/TCP超时配置过短 | 超时模板比对 RFC 4787/5382 基线 | | 账号被平台误封、验证码轰炸 | 端口块/IP前任用户劣迹 | 查该公网IP近期用户归属记录 | | 同区域用户互访不通 | hairpinning 缺失或性能差 | 验证CGN回环路径 | | VoLTE外呼单通、传真必失败 | ALG 改写报文出错 | 临时关闭ALG做对照验证 | ## 四、日志海啸：合规账单与RFC 7422的算术 如果说前三类故障是技术账，这一节是钱袋账，也是 CGNAT 运维最重的负担。 《中华人民共和国网络安全法》第二十一条要求网络日志留存不少于六个月。对 CGNAT 来说，这条规定的杀伤力在于：**动态分配模式下，每一次地址翻译都必须记日志，否则出了事无法回答“当时这个公网端口是谁的”**。RFC 6888 同样把可溯源的日志能力列为 CGN 的硬性要求。 来算一笔账（以下为笔者按经验参数的估算，仅供量级参考）：一百万在线用户，人均每天产生约 1500 条NAT会话日志，每条含双端五元组与时间戳约 250 字节—— - 每天原始日志：100万 × 1500 × 250B ≈ **375 GB** - 六个月留存：约 **68 TB** - 这还只是裸数据。日志进 Elasticsearch 这类系统，索引膨胀和副本通常再乘 2～3 倍，存储与检索成本直接翻上 **150～200 TB** 量级，还不算为支撑查询而常年运转的计算资源。 这就是 2015 年 IETF 发布 RFC 7422 的动机。它的思路一句话能说清：**把“动态随机分配 + 全量日志”换成“静态算定 + 极少日志”**。每个用户的端口块由算法从地址池中确定性推出，同一时间永远可复算，于是只需要记“哪个用户拿到了哪个块”（分块日志），而不必记每一条会话。RFC 7422 自己给出的算例显示，日志量可以下降几个数量级；代价是用户占用块的时间粒度变粗、并发容量上限被块大小锁死，且映射规则一旦发布就难以频繁调整。 沿 RFC 7422 的思路自行演算一笔：单IP约 64K 可用端口、按 4096 一块，一个IP固定服务 16 个用户；一百万用户约需 6.3 万个公网IP（一个 /16 略多）；分块日志按用户记，一百万条、约 0.25 GB，一次性入库、六个月不增长。与动态方案的每天 375 GB 相比，是三个数量级的差距。 **表3：三条技术路线对比** | 路线 | 原理 | 日志负担 | 主要代价 | 适用场景 | |---|---|---|---|---| | 动态 CGNAT | 池内动态分配端口，逐会话记日志 | 每天数百GB起（百万用户级） | 日志成本高、误伤难归因 | 存量网快速落地、用户基数小 | | 确定性NAT（RFC 7422） | 端口块静态算定，只记块分配 | 下降数个数量级 | 并发受块大小限制、调参不灵活 | 大规模宽带/移动网合规 | | A+P 家族（lw4o6/MAP-E/MAP-T，RFC 7596/7597/7599） | 端口集直接下发到用户侧CPE | 网络侧几乎零会话日志 | 要求CPE支持，排障链路变长 | IPv6过渡期、新建区域 | 顺带一提 IPv6：它是唯一的终局答案，但从 APNIC 的公开测量看，全球部署率过半的市场也才少数，过渡期里 464XLAT（无状态NAT46+有状态NAT64 组合，部署指南见 RFC 8683）这类方案让“IPv6-only 接入 + 兜底翻译”跑通了手机网络。对运维而言那又是另一套故障域——DNS64 合成地址、应用写死 IPv4 字面量，都是后话。 ## 五、一次典型排查的完整推演 下面这个场景是多起公开报告与一线实践中反复出现的典型模式，细节已做脱敏与通用化处理，但它能完整串起前文所有知识点。 某区域陆续进线：用户反映“网页大部分正常，个别网站打不开”，且主要集中在游戏和社交平台。第一直觉是内容网问题，但跨网站、跨时段都有，排除。第二天投诉升级：有用户发现自己的游戏账号被平台封禁，而他自己坚称什么都没干。 到这里，CGNAT 的嫌疑才浮出水面。排查链如下： ```mermaid flowchart TD A[个别网站打不开投诉] --> B{单用户还是批量} B -->|单用户| C[查账号与公网出口IP] B -->|批量且同区域| D[查NAT资源池告警] C --> E[还原端口块归属记录] D --> F{会话表占用率} F -->|超阈值| G[端口耗尽或扫描流量] F -->|正常| H[比对超时模板基线] G --> I[扩池并定位异常源] H --> J[按RFC基线调参] E --> K{IP是否被外部拉黑} K -->|是| L[换池并提交解封申诉] K -->|否| M[抓包比对内外映射] I --> N[复盘固化告警基线] J --> N L --> N M --> N ``` 推演中的几个关键动作值得展开： 1. **还原归属。** 从认证系统取该用户的上线时间窗，再从 CGNAT 的块分配日志确认他在投诉时段占用的公网IP和端口块。动态模式下这一步必须逐会话对日志，确定性模式下直接复算——这也是为什么本文反复强调日志方案选型。 2. **查前科。** 拉出同一端口块在该用户之前 24 小时的使用者。典型结论：前任是中毒终端，在块内对目标网站发起了扫描或攻击，目标平台把整个IP/端口段拉黑，继任者全军覆没。误封的账号案也在此告破。 3. **验证翻译行为。** 在 CGN 内外两侧同步抓包，比对内层五元组与外层映射，重点看超时是否符合基线、ALG 是否在改写。若发现 UDP 映射远短于 5 分钟，推送延迟的那批投诉同时闭环。 4. **闭环固化。** 处置完成不算完：把“单用户会话数”“会话表占用率”“块内信誉变更”固化为告警项和巡检基线，把这次的事故模式写进下一轮预案。标准允许多种实现，各网元的默认参数差异不小，基线必须以自己现网的验证结果为准。 ## 六、写给同行的十条经验 1. **把 CGNAT 纳入核心网故障域，而不是当数通设备甩给数据专业。** 移动网里它就是 SGi/Gi 上的必经之路。 2. **超时参数照 RFC 基线过一遍**：TCP ESTABLISHED 不低于 7440 秒（RFC 5382），UDP 不短于 2 分钟、建议 5 分钟量级（RFC 4787）。任何想调短的冲动，先想想重连风暴。 3. **按用户限会话是必配项**（RFC 6888 要求项），否则一个中毒终端能拖垮整个端口块。 4. **日志方案在建设期就要选**：用户规模上了百万级，动态全量日志的存储账单会逼你重构，RFC 7422 的确定性方案宜早不宜迟。 5. **100.64.0.0/10 单独建地址组策略**，别和 RFC1918 私网混在一个安全域里。 6. **建一份“IP信誉”视角的监控**：出口IP被外部拉黑，要能告警到运维而不是等用户投诉。 7. **ALG 默认关闭、按需开启**，每开一个都要有对应的回归验证。 8. **投诉分类里加一条“部分网站/平台异常”的标记**，它是最典型的 CGNAT 症状指纹，能帮一线少走三天弯路。 9. **hairpinning 上线前实测**，尤其同城有自建业务节点时，回环路径的性能经常被高估。 10. **IPv6 是唯一的解药**。每多一分 IPv6 流量占比，CGNAT 的会话表、日志和误伤面就小一分。 ## 结语 CGNAT 是 IPv4 时代运营商给全行业上的最后一道补丁：它让几十亿人挤在 43 亿个地址里继续上网，也把地址稀缺的代价转化成了日志成本、排障复杂度和“连坐式误伤”。RFC 6269 早就把这份代价清单写得明明白白，RFC 7422 则给出了工程上最划算的对冲。对一线工程师，它不值得怕，只值得被认真对待——把参数锚在标准基线上、把日志账在建设期就算清、把“千人一IP”的副作用写进告警基线，CGNAT 就会重新变回那个安静的隐形人。而在地平线上，IPv6 每涨一个百分点，这道补丁就离退役近一步。 ## 参考来源 1. [RFC 6269: Common Issues with IP Address Sharing](https://www.rfc-editor.org/rfc/rfc6269) — IETF 对地址共享副作用的最权威清单：应用破坏、黑名单误伤、地理定位漂移、执法溯源难题，本文第三节的主轴 2. [RFC 7422: Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments](https://www.rfc-editor.org/rfc/rfc7422) — 确定性NAT降日志的标准方案，含官方算例，本文第四节主轴 3. [RFC 4787: NAT Behavioral Requirements for Unicast UDP](https://www.rfc-editor.org/rfc/rfc4787) — UDP 映射方式、保活时长与回环要求的出处 4. [RFC 5382: NAT Behavioral Requirements for TCP](https://www.rfc-editor.org/rfc/rfc5382) — TCP ESTABLISHED 7440 秒超时基线的出处 5. [RFC 6888: Common Requirements for Carrier-Grade NATs (CGNs)](https://www.rfc-editor.org/rfc/rfc6888) — CGN 按用户限制与可溯源日志能力的合规要求 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。