去年这个时候，我们接了一个制造业园区的无线覆盖项目。甲方要求不高——"能把网上了，别让外人随便连"就行。本以为是个标准动作，结果这个"简单"需求让我们在项目里多待了四个月。问题不在无线覆盖本身，在于无线认证这个环节，每一步都有意想不到的坑。以下是这一年来踩过的主要问题，供即将上这个项目的团队参考。

第一个大坑出现在需求确认阶段。项目启动前，甲方IT部门说得很清楚：内网员工用账号密码上网，访客用手机号验证。听起来非常标准，主流方案都能满足。但合同签完进场之后才发现，甲方的IT部门只管得了办公区域，车间那边的设备联网根本不在他们的管辖范围内。生产线上有大量的传感器、AGV小车、工控平板，这些设备要么没有浏览器，要么没有输入界面，根本不可能用账号密码认证。而这些设备偏偏需要访问内网的MES系统和数据采集平台。

这不是个例。几乎所有制造业客户在需求确认阶段都不会主动提到这部分设备，他们默认IT部门会统一考虑，但实际上生产网络和办公网络往往分属不同的IT团队管理，互相不知道对方的需求。解法只有一个：需求调研时，主动问清楚所有需要联网的设备类型，把它们单独列出来，每一类都确认认证方式。人的需求要关注，设备的需求更要单独处理。

第二个坑是认证和授权没有分开处理。员工认证上了WiFi，接下来就是能不能访问内网资源的问题。认证解决的是"你是谁"，授权解决的是"你能干什么"，这是两个独立的事情。但很多甲方甚至集成商都把它们混为一谈。以为只要员工能连上WiFi，就能访问内网的ERP和文件服务器。结果上线之后才发现，财务部的电脑连上了无线，却访问不了财务系统，反而人事部的电脑能访问财务数据。追查一圈发现，问题出在无线网络的VLAN规划上，认证环节和有线网络的权限控制完全没有打通。

解决这个问题需要做三件事：无线认证系统要和有线网络的802.1X或者MAC绑定策略做联动；每一个SSID对应的VLAN要和业务系统权限做对应映射；上线前必须用真实的业务账号做完整的访问路径测试。很多项目在这里出问题，不是因为技术上做不到，而是因为项目范围里根本没有定义清楚谁负责认证、谁负责授权、两个系统之间怎么联动。

第三个坑是高可用没有做真实验证。无线认证系统作为网络入口，一旦出问题影响面极大。我见过一个项目，甲方的无线认证用的是单点部署，正式上线三个月后服务器硬盘故障，整个园区的无线网络全部瘫痪。IT部门用了两天时间才恢复，期间几百名员工无法上网，业务部门直接投诉到CEO办公室。更要命的是，那两天的故障日志完全丢失，事后复盘连问题根因都无法确认。

高可用不是选做题。系统至少要做主备双机，主备之间的会话同步要验证过真实切换效果，切换日志必须完整保留。上线前必须做一次真实的故障切换演练——不是让运维人员看过文档就算数，而是真的把主节点关机，观察备节点是否正常接管，用户的在网会话是否保持，业务系统是否受影响。很多团队觉得演练太麻烦，但这恰恰是最不该省的环节。

第四个坑来自监管部门的合规检查。这个坑在项目初期几乎没有人会提，因为合规检查通常是上线运营一段时间之后才会发生的事。但一旦检查来临，很多项目方会措手不及。常见的问题是：认证日志的留存周期不足，很多系统默认只保留30天，但某些行业的监管要求是至少6个月；日志格式不符合要求，检查方要求的是带时间戳、来源IP、账号、目标URL的完整访问日志，但系统输出的日志格式只有连接记录，没有业务层面的访问信息；还有一个是多人共用账号的问题，检查方发现同一账号同一时间多个IP地址登录，系统无法识别和告警。

合规要求必须在系统设计阶段就明确，不能等项目上线后再想办法补救。一旦日志格式固定了，数据结构改了会非常麻烦。最好在需求阶段就把当地的监管要求逐条对照，把合规需求写进技术方案，而不是在验收前临时抱佛脚。

最后一个坑是运维交接。很多项目把无线认证系统交付给甲方IT部门之后，集成商就算完成了任务。但甲方IT部门的日常运维能力往往达不到系统正常运行的要求。最常见的情况是：日志满了不知道清理，系统性能下降了不知道排查，新员工入职不知道怎么批量开户，设备更换了MAC地址变了之后网络不通不知道从哪查起。

建议在项目交付时，提供一份完整的运维手册，不只是操作手册，而是把常见故障的排查路径做成流程图。还要做一次正式的运维交接培训，把系统的日常健康检查项、常见问题的处理方式、什么情况下需要联系集成商这几个问题讲清楚。很多时候运维做得好不好，不是系统本身的问题，而是交接有没有做到位。