校园网认证系统上线只是第一步，真正考验功力的是日常运维。做过校园网运维的工程师都有一个共识：认证系统不出问题则已，一出问题就是全校级别的故障。学生宿舍晚上断网前三分钟，几千人同时拨号，BRAS设备CPU飙升到百分之九十以上；开学报到当天，Portal服务器因为并发过高直接宕机，新生和家长堵在报到现场上不了网；某个寝室私接了一台开了DHCP的路由器，整层楼两百多人IP地址全乱套。这些场景不是教材里的案例，而是运维人员面对的现实。

要理清运维思路，先从最常见的故障现象入手。排在投诉榜第一位的永远是「能连Wi-Fi但打不开登录页面」。用户说Wi-Fi图标显示已连接，信号满格，但就是弹不出Portal认证页。这种情况需要分层排查。首先让用户手动在浏览器地址栏输入一个纯HTTP网址，比如http://1.1.1.1。Portal重定向只对HTTP请求有效，如果用户浏览器默认打开的是HTTPS页面，重定向会被浏览器的HSTS策略拦截。这一步排查能排除掉大约三成的误报。如果HTTP也打不开，检查终端获取的IP地址和DNS。大部分Portal场景下用户需要先通过DHCP拿到IP和DNS，如果用户手动设了静态DNS或者走了代理，DNS解析不到Portal服务器的域名，重定向自然也触发不了。还有一种容易被忽视的情况是用户在Wi-Fi设置里关了「自动登录」选项，iOS和部分安卓定制ROM有这个开关，关了之后系统不会主动发HTTP探测请求，Portal页不会弹出。

第二个高频故障是认证通过但网速奇慢。用户登录成功，Portal页面显示「认证成功」，但打开网页要等十几秒。这个问题在PPPoE环境下尤其常见，根因十有八九是MTU不匹配。标准以太网MTU是1500字节，PPPoE隧道头部开销8个字节，实际可用只有1492。如果用户路由器或终端默认使用1500的MTU发包，到了BRAS这里，大于1492的包要么被分片要么被丢弃。分片之后TCP需要重传重组，延迟直接翻倍。解决办法是在BRAS上开启TCP MSS调整功能，把三次握手阶段的MSS值钳制到1452以下，这样TCP层面就不会发出超过链路承载上限的数据段。Portal环境下的网速问题则多半出在网关设备的会话表上。每个认证通过的IP对应一条会话表项，老旧网关的会话表容量有限，高峰期打满之后新会话建立不了。表现是用户能ping通外网但打不开网页——ping走ICMP协议不建会话，而HTTP需要新建TCP会话。这种情况只能升级硬件或者优化会话老化时间。

第三个让人头疼的问题是私接路由器和账号共享。学生寝室里接一个家用路由器，WAN口接校园网，全寝室共享一个账号上网。这种行为一方面影响计费公平，另一方面路由器默认开启DHCP反向给校园网分配IP地址，导致同楼层其他用户拿到错误的网关地址，整层断网。防代理检测是认证系统的标配功能，常见手段包括检测IP包的TTL值。正常情况下Windows发出的包TTL是128，经过路由器NAT之后减1变成127。如果系统检测到同一个账号下有多个不同的TTL值，基本可以判断后面挂了路由器。更精细的做法是检测HTTP User-Agent的多样性——一个账号下同时出现Windows、Android和iOS的UA，显然不是单设备行为。部分系统还会结合DPI深度包检测来识别共享行为，比如检测到同一个账号下同时存在多个不同即时通讯账户在活跃。

日常巡检是减少故障的关键。RADIUS服务器的日志是运维人员最好的诊断工具。每天花十分钟翻一下认证失败日志，能提前发现很多问题。比如某个账号短时间内连续认证失败十几次，大概率是密码输错或者被盗用，及时冻结能避免后续的麻烦。再比如某台交换机上报的RADIUS请求量突然翻倍，可能是下面有人在尝试暴力破解或做端口扫描，需要马上排查。Syslog集中收集和分析也应该纳入日常流程，把认证系统的日志、交换机日志和DHCP服务器日志放在一起做关联分析，异常的规律一目了然。比如IP地址冲突事件在某个楼栋集中爆发，十有八九是那栋楼有人私接了路由器。把这些数据源打通之后，很多问题的定位时间可以从小时级缩短到分钟级。

备份和逃生机制是底线中的底线。认证服务器必须做双机热备，一台宕机了另一台无缝接管。更重要的是逃生策略。如果两台都挂了怎么办？要提前在网关设备上配置逃生模式，是默认放行所有流量还是基于上一次的成功认证记录放行，这个策略需要和学校信息化管理部门提前达成一致并白纸黑字确认。没有逃生机制的认证系统，一次宕机就能让全校断网，影响范围从选课系统到食堂刷卡，这个风险属于谁也担不起的级别。实际部署中，建议定期做灾备演练，模拟认证服务器全部宕机的场景，验证逃生策略是否能按预期生效。演练可以在假期凌晨进行，不影响正常教学秩序。

认证系统的运维，说到底是一个持续对抗熵增的过程。设备老化、用户增加、需求变化，都在不断制造新的问题。运维人员要做的不是追求一台永远不出问题的设备——那不存在——而是建立一套能快速定位问题、快速恢复服务的机制。故障不可避免，但中断时间可以用体系和流程来控制。随身带一根串口线、记几个常用的RADIUS调试命令、保存一份脱机版的网络拓扑图，这些朴素的习惯往往比昂贵的网管系统更能在关键时刻救命。

（约1820字）