Portal 认证系统能不能落地，很多时候不是产品能力问题，而是控制点归属问题。认证要生效，必须在用户的上网链路上有一个你能控制的点，请求能被引到认证页，认证通过后能在这个点上放通，认证不通过能在这个点上拦住。如果这条链路的出口根本不在你手里，那么不管系统功能多全，都没有地方去执行放行和拦截。这类问题在方案阶段看不出来，因为功能清单上都写着支持，但到了实施阶段就会发现无处下手。
先判断出口在谁手里
判断的第一步是问清楚网络出口在哪里。出口在客户自己的机房，说明有可控的汇聚层和控制点，通常可以在机房旁路部署认证网关，不改动现有网络结构就能把认证能力加进去。出口在运营商机房，比如每个房间直接接运营商的光猫、网络在运营商侧汇聚，那么客户这边根本没有可以放认证设备的位置，补救方案要么成本极高，要么根本不成立。这两种情况的结论差别很大，但外表看都是同一个客户想做统一认证。
四层判断框架怎么用
遇到这类需求，建议按四层判断框架逐层过一遍。第一层看理论可行性，有没有技术路径；第二层看架构适配性，关键点是不是在可控范围，如果关键点不在，这就是重大限制，必须明确标注出来；第三层看项目可落地性，改造量、部署量、维护量、成本、对现网的影响分别是多少；第四层看商业合理性，方案是不是违背了客户当初的选型逻辑，补救成本是不是远超预期。四层每层都要给出明确判断，不能含糊，也不能只因为存在一个补救方案就写成可以做。
认证网关和无线控制器要分工清楚
在无线场景里，经常有人把认证和无线控制混为一谈，以为上了认证系统就能接管所有无线策略。实际上两者分工不同：认证网关负责认证跳转、用户识别、策略放行、流量归属和与认证平台的联动；无线控制器负责无线侧的控制和策略下发。方案里如果不把这个分工写清楚，客户会误以为设备可以被替换，或者误以为认证系统能解决信号覆盖和漫游的问题，后面验收时就会产生分歧。
旁路优先不等于万能
旁路部署因为不改动现有网络结构，在多数场景里是优先选项，酒店和校园的存量改造尤其如此。但旁路不是万能答案，它成立的前提是存在可以旁挂并且能看到流量的位置。有些网络拓扑里，流量在接入层就被隔离或者分流了，旁挂点看不到全部流量，认证就会出现一部分用户被放通、一部分绕过去的情况。所以选型阶段要拿到实际拓扑，确认旁挂位置的可见范围，而不是默认旁路一定可行。
存量改造必须先勘测
老网络改造最忌讳的是假设所有设备都支持标准协议。运行多年的网络里，设备型号混杂、固件版本老旧、配置五花八门的情况很常见，有些设备声称支持某种对接方式，实际开了之后功能和文档描述不一致。稳妥的做法是在方案阶段就安排勘测，把接入设备的品牌型号、固件版本、是否支持外部跳转、现网控制点是否可用这几项确认下来。勘测成本远低于实施到一半发现设备不支持再返工的成本。
这些需求表述要提高警惕
客户的需求描述里，有一些表述属于高风险信号，听到就应该进入谨慎判断模式：比如强调不改原有网络、强调要保留已有投资、强调替换设备但不允许中断业务、或者要求在不提供任何拓扑和型号信息的情况下直接报价。这些表述的共同点是信息不完整，或者隐含了互相冲突的约束。信息不完整时不能给出可以直接对接的结论，正确的回应是先列出需要确认的清单，确认之后再下判断。
验收时要回到控制点
项目验收时，除了验证用户能正常认证上网，还应该专门验证控制点确实生效：不放通的用户是不是真的被拦住、绕过认证直连内网资源的路径有没有被堵、认证失效之后有没有退化成完全放行。有些项目上线后看起来一切正常，实际上只是因为没人在恶意绕过，一旦有人绕过就会暴露。这类验证不复杂，但如果不做，安全问题会在很后期才被发现。
控制点和审计点往往是同一个位置
还要考虑一件事：做认证的项目往往同时有日志留存和审计追溯的要求，而审计点通常就落在网络出口上。如果出口不在可控范围内，不只是认证做不了，审计同样没有落脚点，因为你看不到完整的上网流量。所以判断控制点归属的时候，要把认证和审计两件事一起考虑，不要分开评估。有些项目认证勉强能做，但审计始终缺一块，等到需要追溯的时候才发现这段流量从来没被记录过。