**鉴权失步：两小时无服务风暴** ## 概述 一次 Auc 双活割接，叠加四万多张新卡批量上线，在两个多小时里酿成了一场教科书级的鉴权失步风暴：注册成功率26分钟内从99.2%跳水到61%，换卡批次用户成批显示“无服务”，客服话务瞬间打爆。本文以一次完整的脱敏复盘（案例经合并处理，不指向任何具体运营商，时间与数字为该类故障的典型量级；全部鉴权机制均出自 3GPP TS 33.501、TS 33.102 等规范原文）回答三个问题：5G-AKA 到底在鉴什么、为什么计数器一失步就是全网风暴、这种最阴的核心网故障怎么定位怎么治。 ## 目录 - 一、风暴实录：两小时的完整时间线 - 二、第一道门：5G-AKA 到底在鉴什么 - 三、根因剥洋葱：cause 20 与 cause 21 的分野 - 四、止血与根治：处置过程的每一步 - 五、整改清单：让风暴没有第二次 - 六、写在最后 ## 一、风暴实录：两小时的完整时间线 这不是一场戏剧性的全网瘫痪。没有火光，没有 cables 被挖断，甚至前二十分钟网络监控大屏上一切正常——直到注册成功率曲线开始阴跌。 事情要从前一晚说起。按计划，当晚是鉴权中心（Auc/ARPF，5G 架构下内嵌于 UDM）双活改造的割接窗口：主备两套网元完成倒换演练，各项巡检全绿。同一晚，号管侧还预激活了一个批量换卡批次——四万两千张新卡写入号段，计划次日凌晨起分批激活。两条线在同一口井里打了水，风暴的引信就此埋下。 | 时刻 | 事件 | 关键数据（典型量级） | |---|---|---| | D-1 22:00 | Auc 双活割接窗口开启 | 主备倒换演练通过 | | D-1 23:40 | 批量换卡批次预激活 | 4.2 万张新卡写入号段 | | D0 00:05 | 换卡用户集中开机 | 注册请求量抬升 | | D0 00:21 | 注册成功率跌破门限 | 99.2% → 94.6% | | D0 00:38 | 客服话务异动告警 | “无服务”类投诉集中涌入 | | D0 00:55 | 拉取鉴权失败 cause 分布 | cause 21 占失败总量 83% | | D0 01:12 | 定位备库计数器基准回退 | 备库基准落后主库约 6 小时 | | D0 01:30 | 业务切回主库 | 重同步洪峰出现 | | D0 02:10 | 限流与退避参数生效 | Auc 调用量回落 | | D0 02:47 | 注册成功率恢复 | 99.1%，风暴结束 | 影响面有两个层次。用户侧，中招的是换卡批次和割接窗口内新注册的用户——存量在线用户完全无感，因为鉴权只发生在注册和重鉴权时刻，已经挂在网上的终端不会重新走这道门。这也是这类故障最迷惑人的地方：投诉不是全网炸开，而是一个批次一个批次的“聚堆”，很容易被误判成卡的质量问题或号段数据问题。信令侧，代价藏在 Auc 的 CPU 曲线里：风暴期间鉴权调用量被放大到日常的三倍，其中一多半不是正常鉴权，而是重同步——每一次失败的注册，都要比正常流程多跑一个来回。 ## 二、第一道门：5G-AKA 到底在鉴什么 要理解风暴，得先理解这道门。 终端开机发起注册时，它是“匿名”的——5G 出于隐私保护，空口里跑的是加密推导出来的用户标识（SUCI），网络并不直接认识你。谁都能喊“我是我”，所以注册的第一步必须是鉴权：终端证明卡里有根密钥 K，网络证明自己这边也持有同一把 K，双方验明正身，会话密钥才发得下去。这套机制就是 5G-AKA，规范主体在 TS 33.501。 角色分工值得记一下：AMF 里嵌着 SEAF（安全锚点），负责发起和转发鉴权；AUSF 是鉴权服务层；真正的“账房”是 UDM 里的 ARPF——老一代工程师口中的 Auc。账房按需生成**鉴权向量**，一组五元组：随机数 RAND、期望响应 XRES、鉴权令牌 AUTN，以及推导出的根密钥材料。真正发给终端校验的戏肉是 AUTN，它的构造是理解本案的钥匙： **AUTN = SQN⊕AK ‖ AMF ‖ MAC** MAC 是用根密钥对 RAND、SQN 等参数算出的消息鉴权码——终端验 MAC，证明的是“网络手里有和我同一把 K”，防的是假基站钓鱼。而 SQN（序列号），防的是另一件事：重放。今天截获一组合法鉴权，明天原样再发一遍，MAC 照样验得过——所以必须有个数证明“这是新鲜的一手货，不是昨天用过的旧货”。 这个数就是 SQN，全网最大的单调计数器。规范（TS 33.102）里它的结构是 48 比特 = SEQ ‖ IND：低位 5 比特 IND 把计数器切成 32 组并行推进，卡里为每一组分别记录“已接受过的最高值”；SEQ 是高位主体，逼近上限时还有一套回绕处理的特殊算法，是 TS 33.102 附录里的经典细节。终端收到 AUTN 时做两件事：验 MAC；再把 SEQ 和卡里记录的基准对表——必须单调不回退。对不上表，终端不会默默吞下这组数据，而是回一条 **Authentication Failure，cause #21（Synch failure）**，并附上 AUTS：用匿名密钥掩码过的卡端计数器值，意思是我把我的表读数报给你，你去对。 网络侧收到重同步请求，Auc 比对自己账本上的值和终端上报的值，取更新的那个重新对齐基准，再发一组新向量。协议层面这是一次优雅的自愈：卡和网络各执一半真相，AUTS 是两者之间的对表报文。代价是多一次 Auc 计算、多一个 NAS 空口往返——正常网络里，重同步占鉴权总量的比例在千分之一以下，安静得像不存在。 另外提一句边界：非 3GPP 接入（比如 Wi-Fi 场景）走的是另一支 EAP-AKA' 流程，本文只谈 3GPP 接入的 5G-AKA；标准也允许多种实现，各厂家网元在向量缓存、重同步策略上的具体默认行为，以官方文档为准。 ## 三、根因剥洋葱：cause 20 与 cause 21 的分野 核心网老手看鉴权失败，第一刀永远切在 cause 分布上，因为两种失败指向完全不同的病区： | 失败类型 | 5GMM cause | 指向的病区 | 典型根因 | |---|---|---|---| | MAC 校验失败 | #20 | 密钥与数据 | OPc/密钥配置错、五元组损坏、旧向量重放 | | 同步失败 | #21 | 计数器状态 | 主备基准回退、换卡基准过低、双活脑裂 | | 鉴权流程超时 | 无失败上报 | 容量与链路 | Auc 过载、N1 重试洪峰、定时器（T3510）打满 | 本案 cause 21 占 83%——计数器病区，板子打在“表没对齐”上。但“表没对齐”只是病灶，真正要剥的是：为什么会不对齐，以及为什么对不齐还能滚成风暴。 **第一层：双活的致命细节。** 割接当晚业务倒到了备库，而备库的计数器基准是异步复制来的——落后主库约六小时。对这六小时里注册过的存量卡，网端下发的 SEQ“变旧”了，卡端一验：比我已经接受过的还旧，拒绝。到这里为止，故事本该到此为止：卡发 AUTS，Auc 对表，取卡端更新的值，一次自愈，皆大欢喜。 **第二层：换卡批次成了放大器。** 问题出在那四万两千张新卡上。新卡出厂时计数器基准接近零，而网端账本已推进到很高位置——两边差的不是一步，是“一辈子”。每次鉴权失败→重同步，Auc 取值重新对齐，可当网端存在两个各自动推进的写点、基准来回横跳时，永远无法和卡端收敛到同一读数：卡说“我在这”，网端说“不，你在这”，下一轮鉴权，再对，再错。注册失败，终端按 NAS 重试定时器（T3511）再试，再失败，再试。 **第三层：自愈机制反噬成洪峰。** 这是全案最讽刺的一环：重同步本是自愈机制，但每一张失步的卡，每次注册都要触发一次额外的 Auc 计算。四万张卡 × 反复重试 × 每次两趟计算，Auc 调用量瞬间被放大三倍，逼近容量红线；过载带来超时，超时带来更多重试，教科书级的雪球滚起来了。 完整的失败链条如下图： ```mermaid flowchart TD UE["终端发起注册"] --> AMF["AMF触发鉴权"] AMF --> AUSF["AUSF调用5G-AKA"] AUSF --> UDM["UDM取鉴权向量"] UDM --> AUC["Auc生成五元组"] AUC --> UDM UDM --> AUSF AUSF --> AMF AMF --> UE UE -->|MAC对不上| FAILM["cause20 拒绝"] UE -->|计数器过期| SYNCF["cause21 附AUTS"] SYNCF --> AMF AMF --> AUSF AUSF --> UDM UDM -->|对表取新值| AUC AUC -->|重置基准| UDM UDM -->|新向量| AUSF AUSF -->|二次鉴权| AMF AMF -->|再发AUTN| UE ``` 一句话归纳根因：**单调计数器遇上多写点，就是事故预定。** SQN 的全部价值建立在“只增不减”上，而双活架构天然制造了两个写点；异步复制延迟是常态，倒换只是让常态变成了事故。换卡批次则把“单次可自愈的失步”变成了“永不收敛的失步”，再借重试机制把自己放大成风暴。 ## 四、止血与根治：处置过程的每一步 **定位用了不到一小时，靠的不是运气，是工具链和三分法。** 第一步，AMF 侧开 N1 NAS 信令跟踪，把失败按 cause 分桶——这一步直接把病灶从“网络问题”锁死到“计数器问题”。第二步，看 AUSF/UDM 调用统计里重同步占比：从千分之一跳到百分之四十多，失步实锤。第三步，抽样比对：随机抽一批 IMSI，比对 Auc 主备两侧各自记录的 SEQ 值——备库落后六小时，数字直接摆在大屏上。第四步，测试卡矩阵验证：割接前注册过的老卡、割接窗口注册的卡、新批次卡，三类卡在测试环境复注册，前两类一次重同步即自愈，新卡批注册批失败——根因链条完整闭合。 止血分四步，按“先保业务、再保网元”的顺序： 1. **切回主库，恢复唯一写点。** 写点唯一了，存量卡的失步靠 AUTS 一次对表自愈，注册成功率第一波回升。 2. **新卡批次停量。** 放卡计划冻结——在基准问题解决前，每多激活一张卡，就是给风暴添一把柴。 3. **给 Auc 降压。** 对重同步请求按 IMSI 限频，同时调整 NAS 侧重试退避参数，把终端的重试节奏从“连珠炮”拉回“礼貌敲门”。 4. **双指标确认恢复。** 盯的不只是注册成功率，还有重同步占比——前者回升可能只是重试错峰的假象，后者回到千分之一量级才是真正的病愈。 根治同样四条。**架构上，双活改单写多读**：计数器只允许一个写点，另一侧只读，故障接管时必须先全量对齐基准再接业务——这条纪律没有商量余地，因为 SQN 回退的每一秒都是事故窗口。**数据上，鉴权向量缓存统一短 TTL**，割接后强制清理，杜绝新旧向量交叉。**流程上，发卡工装增加基准预置**：写卡时从网端取当前计数器位置写进卡里，让新卡出生时就和网端在同一页账本上；换卡放号严格执行灰度，先放量 1% 观察 cause 分布，达标再爬坡。**割接单上，新增“鉴权冒烟”强制项**：倒换后用测试卡批量注册，cause 分布不达标，不许执行下一步。 ## 五、整改清单：让风暴没有第二次 复盘报告最后沉淀成三张清单，这里合并成一份可带走的检查表： | 维度 | 整改项 | 触发条件/阈值 | |---|---|---| | 监控 | 注册/重鉴权成功率分层监控 | 周环比跌幅超 0.5 个百分点立案 | | 监控 | cause 20/21 分桶独立告警 | 任一 cause 占比超 30% 即告警 | | 监控 | 重同步占比哨兵 | 超过 0.5% 即为失步风暴前兆 | | 监控 | 主备 SEQ 基准每日抽样审计 | 主备差值随复制延迟收敛为 0 | | 流程 | 双活复制延迟纳入倒换前置检查 | 延迟超阈值禁止倒换 | | 流程 | 换卡批次灰度放量 | 1% → 10% → 全量，每级盯 cause 分布 | | 流程 | 割接窗口与放号日互斥 | 大批次发卡前后 24 小时不动 Auc | | 架构 | SQN 单写多读改造 | 计数器类数据禁止双写点 | | 架构 | 发卡工装预置 SEQ 基准 | 新卡出厂对齐网端账本 | 最后补一句影响评估的完整结论：本次风暴历时约两小时四十二分，直接受影响用户集中在换卡批次与割接窗口新注册用户，无存量用户长时受影响；信令侧 Auc 峰值负载接近容量红线但未击穿，未发生雪崩式的级联扩面。这类故障的量级天然被“只有注册才鉴权”圈住——但它离击穿红线只差一个再大一号的放卡批次。 ## 六、写在最后 鉴权是全网唯一一个“卡和网络各持一半真相”的机制：根密钥一半在卡里，计数器状态一半在卡里。AUTS 重同步，本质上是两边互相报读数对表——这套设计优雅了两代人，从 3G 一路原样搬进 5G。但优雅的机制扛不住架构的背叛：当网端的账本出现两个写点，“对表”就变成了“各说各话”。 给一线工程师留三句话。第一，看到鉴权失败先切 cause 分布，#20 查数据、#21 查计数器，这一刀能省两小时瞎猜。第二，重同步占比是失步风暴最好的哨兵，盯它比盯成功率早半小时。第三，任何涉及单调计数器的双活改造，先问一句“接管时账本怎么对齐”——答不上来，这个双活就是下一个案例。 网络的可靠性从来不毁于一次断电、一条光缆，而是毁于一个“应该单调递增的数，被两个人同时写过”。 ## 参考来源 1. [3GPP TS 33.501：5G 安全架构与流程](https://www.3gpp.org/ftp/Specs/archive/33_series/33.501/) — 5G-AKA 全流程、SEAF/AUSF 分层与密钥体系的原始规范 2. [3GPP TS 33.102：3G 安全架构](https://www.3gpp.org/ftp/Specs/archive/33_series/33.102/) — SQN/IND 计数器结构、新鲜度校验与重同步机制的规范出处（含附录经典算法） 3. [3GPP TS 24.501：5G NAS 协议](https://www.3gpp.org/ftp/Specs/archive/24_series/24.501/) — Authentication Failure 的 cause 20/21 定义、AUTS 参数与注册重试定时器 T3510/T3511 4. [3GPP TS 29.503：UDM 鉴权相关服务](https://www.3gpp.org/ftp/Specs/archive/29_series/29.503/) — Nudm_Auth 鉴权向量分发与重同步服务接口 5. [3GPP TS 35.206：Milenage 示例算法集](https://www.3gpp.org/ftp/Specs/archive/35_series/35.206/) — AUTN 构造、MAC 与 SQS 计算的算法规范 --- > 本文由「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 等场景全覆盖。