上篇文章讲了校园网络计费系统的选型和规划，这篇讲具体技术对接。很多学校在理论阶段想得很美好，一到技术实施就卡壳，原因是没搞清楚计费系统跟其他网络设备之间到底怎么“对话”的。

Radius协议不是“配个IP和密钥”就完事

计费系统和认证设备之间，绝大多数情况通过Radius协议通信。很多人以为配个Radius服务器IP、共享密钥就完了，其实这里面细节很多。

首先，Radius有认证（Authentication）和计费（Accounting）两个独立通道。认证通道决定“让不让上网”，计费通道决定“用了多少、记多少费”。有些学校只开了认证，没开计费，结果用户能上网但系统里没有使用记录，到了月底对账才发现数据对不上。

其次，Radius属性要跟设备匹配。不同厂商的设备，支持的Radius属性不完全一样。华为、H3C、思科、锐捷，各自都有私有属性扩展。计费系统要能识别并正确处理这些属性，否则会出现“能认证但计费不准”的问题。

我遇到过一个案例：学校用的是华为交换机做接入，计费系统Radius配置里没加华为的私有属性，导致下线检测不正常。用户实际已经断网了，系统里还显示在线，持续计费。后来查了半个月日志才定位到是Radius属性缺失。

Portal认证页面，别用厂商默认模板

Portal认证是用户上网的第一触点，体验好坏直接影响对学校信息化水平的评价。很多学校直接用设备厂商提供的默认Portal页面，丑不说，功能也受限。

好的Portal页面应该支持：自定义样式、移动端自适应、多运营商选择（如果有的话）、余额查询、自助改密码、挂失解挂等自助服务。

技术实现上，Portal页面可以放在计费系统侧，也可以放在独立Web服务器上。我建议放在计费系统侧，因为认证流程更短，出问题排查更方便。如果放在独立Web服务器上，要确保计费系统能提供标准的Portal协议接口。

还有一个细节：Portal页面的访问稳定性。如果计费系统宕机，Portal页面应该能显示友好错误提示，而不是直接报404或者连接超时。这需要在网络架构上做冗余设计。

多运营商代拨，校园网特有的复杂场景

这是校园网跟企业网最大的区别之一。企业网一般就一个出口，校园网经常有多个运营商同时接入，学生可以选择用哪家。

技术实现上，这通常通过“代拨”完成：用户在Portal页面选择运营商，计费系统通过后端的拨号服务（PPPoE或IPOE）帮用户建立对应运营商的连接。

这里面有几个技术难点：

第一，代拨服务的性能。如果几百个学生同时登录，代拨服务要能并发处理，不能一个一个来，否则登录体验会非常卡。

第二，多运营商路由策略。用户选择了运营商A，流量就必须走运营商A的出口，不能串。这需要在计费系统里配置正确的路由策略，并且跟核心路由器的配置对齐。

第三，计费准确性。用户可能上午用运营商A，下午用运营商B，系统要能分别计费，并且账单里要能区分。

我见过一个学校，多运营商代拨配置有问题，导致一部分用户流量串到了教育网出口，结果那个月教育网流量超标，被运营商罚了好几万。问题查出来后，发现是计费系统里的路由策略跟路由器实际配置不一致，两边没人核对。

IPoE和PPPoE，两种代拨方式怎么选

PPPoE是比较传统的方式，优点是技术成熟、设备兼容性好，缺点是效率低、 overhead 大。IPOE是较新的方式，效率高，但对设备和系统都有要求。

如果学校设备比较老，建议用PPPoE，稳定性更有保障。如果设备支持IPOE，而且信息化团队技术能力较强，可以考虑IPOE，用户体验会更好。

还有一个折中方案：核心区域用IPOE，边缘区域用PPPoE。这样既有性能优势，又保证了兼容性。

DHCP和固定IP，地址分配也要纳入计费体系

很多学校的DHCP服务和计费系统是分开管理的，这会导致一个问题：IP跟账号绑定关系不清晰，出了问题难追溯。

好的做法是：DHCP服务要么跟计费系统整合，要么能实时同步。用户认证成功后，计费系统通知DHCP服务分配特定IP，或者在IP和账号之间建立绑定关系。

这样既能防止IP冲突，也能在出现异常流量时快速定位到具体用户。

日志审计，政策要求不是摆设

校园网运营要符合网络安全法、日志留存不少于6个月等要求。计费系统生成的日志（认证日志、计费日志、访问日志）必须完整、准确、不可篡改。

技术上，日志要能实时同步到独立的日志服务器，不能只存在计费系统本地。万一计费系统出了问题，日志不能丢。

我建议至少保留两份日志拷贝：一份在计费系统本地，一份在独立的日志审计服务器。有条件的话，第三份异地备份。

还有一个容易被忽略的点：NAT日志。校园网一般使用私网地址，出公网要做NAT。NAT前后的地址映射关系也要记录，否则出了问题无法追溯到具体用户。

高可用和容灾，不能等出了事再想

计费系统是校园网的核心系统，一旦宕机，影响面很大。高可用设计要从几个层面考虑：

服务器层面：计费系统至少双机部署，主备切换时间要短（秒级）。数据库层面：用主从复制或者集群，保证数据不丢。网络层面：计费系统到认证设备之间的网络路径要有冗余。

我见过一个学校，计费系统做了主备，但主备之间数据同步有延迟。有一次主服务器宕机，切换到备服务器，结果发现过去2小时的计费数据丢失了。后来改成实时同步+定期校验，才解决这个问题。

总结

校园网络计费系统的技术对接，细节远比表面看起来多。Radius配置、Portal定制、多运营商代拨、地址管理、日志审计、高可用设计，每一个环节出问题都可能导致大面积故障。

我的建议是：技术实施前，先画一张完整的业务流程图和数据流图，把每个环节都标清楚，再开始配置。不要边配边想，那样容易漏掉关键细节。

下一篇我会讲计费系统的日常运维和故障排查，包括那些厂商手册里不会写的实战经验。