鉴权失步：两小时无服务风暴

概述

一次 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）双活改造的割接窗口：主备两套网元完成倒换演练，各项巡检全绿。同一晚，号管侧还预激活了一个批量换卡批次——四万两千张新卡写入号段，计划次日凌晨起分批激活。两条线在同一口井里打了水，风暴的引信就此埋下。

影响面有两个层次。用户侧，中招的是换卡批次和割接窗口内新注册的用户——存量在线用户完全无感，因为鉴权只发生在注册和重鉴权时刻，已经挂在网上的终端不会重新走这道门。这也是这类故障最迷惑人的地方：投诉不是全网炸开，而是一个批次一个批次的“聚堆”，很容易被误判成卡的质量问题或号段数据问题。信令侧，代价藏在 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 分布上，因为两种失败指向完全不同的病区：

本案 cause 21 占 83%——计数器病区，板子打在“表没对齐”上。但“表没对齐”只是病灶，真正要剥的是：为什么会不对齐，以及为什么对不齐还能滚成风暴。

第一层：双活的致命细节。 割接当晚业务倒到了备库，而备库的计数器基准是异步复制来的——落后主库约六小时。对这六小时里注册过的存量卡，网端下发的 SEQ“变旧”了，卡端一验：比我已经接受过的还旧，拒绝。到这里为止，故事本该到此为止：卡发 AUTS，Auc 对表，取卡端更新的值，一次自愈，皆大欢喜。

第二层：换卡批次成了放大器。 问题出在那四万两千张新卡上。新卡出厂时计数器基准接近零，而网端账本已推进到很高位置——两边差的不是一步，是“一辈子”。每次鉴权失败→重同步，Auc 取值重新对齐，可当网端存在两个各自动推进的写点、基准来回横跳时，永远无法和卡端收敛到同一读数：卡说“我在这”，网端说“不，你在这”，下一轮鉴权，再对，再错。注册失败，终端按 NAS 重试定时器（T3511）再试，再失败，再试。

第三层：自愈机制反噬成洪峰。 这是全案最讽刺的一环：重同步本是自愈机制，但每一张失步的卡，每次注册都要触发一次额外的 Auc 计算。四万张卡 × 反复重试 × 每次两趟计算，Auc 调用量瞬间被放大三倍，逼近容量红线；过载带来超时，超时带来更多重试，教科书级的雪球滚起来了。

完整的失败链条如下图：

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 分布不达标，不许执行下一步。

五、整改清单：让风暴没有第二次

复盘报告最后沉淀成三张清单，这里合并成一份可带走的检查表：

最后补一句影响评估的完整结论：本次风暴历时约两小时四十二分，直接受影响用户集中在换卡批次与割接窗口新注册用户，无存量用户长时受影响；信令侧 Auc 峰值负载接近容量红线但未击穿，未发生雪崩式的级联扩面。这类故障的量级天然被“只有注册才鉴权”圈住——但它离击穿红线只差一个再大一号的放卡批次。

六、写在最后

鉴权是全网唯一一个“卡和网络各持一半真相”的机制：根密钥一半在卡里，计数器状态一半在卡里。AUTS 重同步，本质上是两边互相报读数对表——这套设计优雅了两代人，从 3G 一路原样搬进 5G。但优雅的机制扛不住架构的背叛：当网端的账本出现两个写点，“对表”就变成了“各说各话”。

给一线工程师留三句话。第一，看到鉴权失败先切 cause 分布，#20 查数据、#21 查计数器，这一刀能省两小时瞎猜。第二，重同步占比是失步风暴最好的哨兵，盯它比盯成功率早半小时。第三，任何涉及单调计数器的双活改造，先问一句“接管时账本怎么对齐”——答不上来，这个双活就是下一个案例。

网络的可靠性从来不毁于一次断电、一条光缆，而是毁于一个“应该单调递增的数，被两个人同时写过”。

参考来源

1. 3GPP TS 33.501：5G 安全架构与流程 — 5G-AKA 全流程、SEAF/AUSF 分层与密钥体系的原始规范
2. 3GPP TS 33.102：3G 安全架构 — SQN/IND 计数器结构、新鲜度校验与重同步机制的规范出处（含附录经典算法）
3. 3GPP TS 24.501：5G NAS 协议 — Authentication Failure 的 cause 20/21 定义、AUTS 参数与注册重试定时器 T3510/T3511
4. 3GPP TS 29.503：UDM 鉴权相关服务 — Nudm_Auth 鉴权向量分发与重同步服务接口
5. 3GPP TS 35.206：Milenage 示例算法集 — 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 等场景全覆盖。