校园网认证管理系统

去年秋天，校园教学楼三楼西侧的证管机房突然断网。管理员老张跑过去一看，理系交换机指示灯全灭，校园重启后恢复正常。证管三天后同样位置再次断网，理系这次他查了日志，校园发现认证服务器在凌晨两点收到大量来自同一MAC地址的证管请求——有人用脚本刷认证。这不是理系黑客攻击，是校园某个学生嫌每次登录都要输学号密码太麻烦，写了个自动重连脚本，证管结果参数写错，理系循环间隔设成了0.1秒。校园

校园网认证管理系统要解决的证管第一个问题从来不是"让用户上网"，而是理系"让正确的人以正确的方式上网"。很多学校早期用PPPoE拨号，每个账号绑定一个IP，简单粗暴。但无线设备一多就撑不住了——手机、笔记本、平板，一个学生手里三四个终端，PPPoE那套会话机制根本扛不住。后来换成Web Portal认证，打开浏览器弹个页面，输账号密码，底层走的是Portal协议。这套方案现在仍是主流，但坑也不少。

Portal认证有个致命弱点：它依赖浏览器。用户点了"登录"之后，如果认证服务器响应慢，页面转圈超过十秒，大部分人直接关掉重来。更麻烦的是移动端，iOS和Android对Captive Portal的探测机制不一样，有些手机会自动弹窗，有些必须手动打开浏览器。我见过一个学校在宿舍区部署Portal，结果小米手机用户集体投诉——系统弹不出认证页面，因为MIUI把Captive Portal探测请求给拦截了。

认证管理系统的核心模块其实就三块：接入控制、用户管理、计费策略。接入控制决定谁能连、连上之后能访问什么。用户管理管的是账号生命周期——新生入学批量导入，毕业生离校批量注销，中间还有休学复学、密码重置这些杂事。计费策略最复杂，有按流量计费的，有按时长计费的，还有包月不限量的。某高校用了一套开源系统，计费模块写死了"每月前30GB免费"，结果有个实验室的NAS设备持续同步数据，一个月跑了2TB，账单出来的时候财务处直接打电话问是不是系统被黑了。

RADIUS协议是认证系统的老黄牛。用户提交的账号密码最终会以Access-Request包发给RADIUS服务器，服务器查数据库，返回Access-Accept或Access-Reject。这个过程通常不到200毫秒，但一旦RADIUS服务器挂了，整个校园网就变成大型局域网——能连WiFi，但什么都打不开。去年某校RADIUS服务宕机四小时，图书馆里学生排着队问"为什么知网打不开"，管理员只能挨个解释"不是知网的问题，是我们认证服务器炸了"。

802.1X认证比Portal更底层，它在数据链路层就完成认证，不需要浏览器介入。有线网络里802.1X是标配，无线网络里用802.1X的也越来越多。但802.1X对客户端有要求，Windows自带 supplicant，Linux上得装wpa_supplicant，有些国产操作系统还得单独适配。我见过一个机房装了某国产Linux，802.1X认证死活过不去，最后发现是网卡驱动不支持EAP-TLS，换了个USB网卡才解决。

认证日志是个宝藏。正常运行时没人看，出问题时全靠它。某次宿舍区大面积掉线，查日志发现大量认证请求来自一个不存在的VLAN——有人把交换机配置改错了，把认证流量导到了错误的上联口。还有一次，认证成功率突然从99%掉到60%，排查半天发现是LDAP服务器和RADIUS服务器之间的时钟差了五分钟，导致Kerberos票据验证失败。这种问题看日志一眼就能定位，不看日志能查一整天。

现在很多学校开始上SDN，认证系统也跟着变。传统架构里认证和转发是分离的，SDN可以把认证策略直接下发到OpenFlow流表里。听起来很美，但实际部署时发现，OpenFlow的流表容量有限，一个宿舍楼几千个终端，每个终端一条流表，交换机直接爆表。所以现阶段还是RADIUS加Portal的组合最稳，SDN那套再等两年吧。

最后说个真事。某校认证系统升级，新版本支持"无感知认证"——用户第一次输密码后，设备MAC和账号绑定，之后自动登录。上线第一周，投诉量翻倍。原因是很多学生把账号借给外校同学用，无感知认证一开，对方设备自动绑定了，原主人反而登不上。管理员只好加了个"解绑"按钮，放在自助服务页面最显眼的位置。技术从来不是问题，人才是。