Portal认证系统校园网AAA升级的RADIUS Proxy对接实操

校园网从旧的一套AAA或者旧认证计费体系，迁移到统一认证计费平台，是很多高校网络改造的重点。这类项目最容易产生的期待，是"零改造直接迁移、一键替换"。这个期待和真实工程之间，隔着联调、映射和回退三道关，任何一道没过，上线就是事故。

什么场景会用到RADIUS Proxy

一类场景是校园网从旧AAA迁到新平台，新老体系要并存一段时间。另一类场景是过渡期里并存多种认证入口，比如Portal、802.1X和历史账号体系同时要能跑。这两种情况下，RADIUS Proxy的价值才真正显现：它不是认证本身，而是负责把请求转发、协议透传和策略衔接串起来的那一层。

对接的三个硬要点

第一，Radius Proxy用于请求转发、协议透传和策略衔接，这是它的定位，不是替代认证系统。第二，认证属性映射、计费字段一致性、失败回退路径，这三项必须联调验证，光看文档说"标准协议应该能通"是不够的，字段对不上、计费对不齐，上线后问题会集中爆发。第三，新老系统并存阶段，必须定义清楚分流策略、割接窗口和回滚机制，没有这三样，一旦新系统出问题，旧系统也回不去。

和代拨、运营商链路要分开评估

如果项目里还涉及PPPoE代拨或者运营商AAA、BOSS系统，需要单独核验接口、账号体系和策略继承关系，不能假设校园网内部联调通过了，运营商侧也一定通。不同链路应当分开评估，严禁把单链路验证结果外推到全部链路。这条边界在高校二次认证场景尤其重要，因为运营商侧的复杂度往往被低估。

对外推荐口径

稳妥的表达是：可以做升级与并存，但是否可落地取决于属性映射、联调条件和回退方案的完整性。这句话把"技术上可行"和"项目上成立"分开了。升级可以分阶段推进，关键在并存策略、映射规则和联调计划，不是一键替换。客户听到这个口径，反而能配合把联调和回退准备做实，而不是盯着"零改造"的承诺。

有几句话绝对不能说

不能讲"零改造直接迁移"，因为新旧体系的字段和策略几乎必然有差异。不能讲"无需联调即可上线"，因为属性映射和计费字段一致性必须实测。也不能讲"任意旧系统都能无条件对接"，因为不同厂商、不同版本的AAA差异很大，必须case by case确认。这三句话任何一句出口，都会把项目的真实工作量藏起来，后期一定反噬。

校园网AAA升级的本质，是一次有计划的并存与切换，不是一次性的替换动作。把Radius Proxy的转发定位、联调的强制要求、以及割接回滚的机制讲清楚，项目才能在不影响师生日常上网的前提下往前推。

属性映射和字段一致性是联调重点

Radius Proxy对接里最容易被文档掩盖的，是属性映射和字段一致性。常见的Calling-Station-Id、Framed-IP-Address、Acct-Session-Id这些属性，新老系统未必用同样的方式填、同样的位置传。计费字段也一样，时长是按秒还是按分、流量是按字节还是按兆，单位对不上，对账就会差出一截。这些不是标准协议应该能通能带过的，必须拿真实报文一条条对。失败回退路径也要提前定好：新系统拒认的时候，请求是丢还是退回旧系统，决定了割接期间师生能不能正常上网。

并存阶段的分流怎么设计

新老体系并存时，分流通常按VLAN、SSID或者用户群来做。比如一部分宿舍区先走新平台，教学区暂留旧体系，或者新生走新认证、老生沿用旧账号，给一个观察窗口。分流策略必须写清楚、可回退，并且和割接窗口对齐。没有分流策略的并存，等于两套体系在同一个网络里互不相让，出问题谁都收不回来。

为什么不能外推单链路结果

校园网内部联调通过，不代表运营商侧也通过。PPPoE代拨或者运营商AAA、BOSS系统各自有不同的接口、账号体系和策略继承关系，必须单链路单独核验。把内部一条链路验证成功，直接说全部链路都没问题，是这类项目最常见的误判来源，也会在割接当天集中爆发。

回退机制决定割接能不能睡安稳觉

并存阶段最怕的不是新系统有问题，而是出问题之后回不去。回退机制要在割接前就写好：新平台拒绝认证时，请求是退回旧系统还是直接失败，决定了割接窗口里几十栋楼的用户还能不能上网。这个机制必须实测，不能停留在方案文档里一句话带过。很多校园网升级项目，真正的风险点不在对接能不能通，而在回退有没有被认真验证过。把回退当成和对接同等重要的交付项，割接当天才不至于手忙脚乱。

联调不是走过场

Radius Proxy对接最容易犯的错，是把联调当成上线前的一个签字环节。真正的联调要覆盖正常认证、属性映射、计费字段、失败回退四条线，每条线都要有真实报文和真实账号跑通的记录。缺任何一条，割接当天都可能变成故障现场。联调报告里写的通过，必须对应到具体的测试用例，而不是一句系统支持标准协议。