准入系统项目失败，很多时候不是产品选错了，也不是部署出了问题，而是需求调研阶段留下了坑。这类坑的特点是延迟爆发——调研期间看不出来，到了部署中期或者上线后才炸。本文整理的是这个阶段最高频的几个错误，都是在实际项目里反复见过的。

只统计设备数量，不摸清设备类型

这是最常见的问题。项目负责人在需求调研时，往往只拿到一个数字："全公司有多少终端"。但网络准入认证系统真正需要的信息，是这些终端的类型分布——Windows 台式机有多少、笔记本多少、哪些是打印机、哪些是摄像头、哪些是 IoT 设备、哪些是 BYOD 自带设备。这些不同类型的设备，在准入管控上的策略是完全不同的。

打印机和摄像头不能装 Agent，只能走 802.1X 或 MAC 地址认证。BYOD 设备需要隔离到专用 VLAN，不能直接访问内网。IoT 设备可能不支持 VLAN 标记，需要特殊处理。如果调研阶段只统计了总数，没有分类，等到方案设计时就会发现漏掉了一大块。

一个实际的做法是，在调研阶段要求 IT 部门提供最近 30 天的 DHCP 日志或者 ARP 表，从里面把设备类型粗分出来。不需要很精细，但至少要知道有哪几类设备存在。

把网络准入等同于 VPN，搞错了系统边界

这个认知偏差在一些中小型企业里很常见。决策层知道要做"网络安全"，但对网络准入认证系统的定位不清楚，以为它跟 VPN 是一回事，或者以为它只管远程接入。

实际上，网络准入认证系统管的是内网边界——任何一台设备要接入公司内部网络，不管是有线还是无线，都要经过认证和合规检查。VPN 管的是外网到内网的加密通道，两者解决的是不同层次的问题。

如果这个边界没有在调研阶段厘清，后续就可能出现方案设计上的错位：花了很多钱部署了一套系统，结果只覆盖了无线，有线网口完全没管控；或者只认证了用户账号，没检查终端状态。

调研阶段应该明确一件事：哪些网络接入点需要纳入管控范围，有线和无线分别怎么处理，各个接入层交换机的型号和协议支持情况是什么。

忽略了既有认证系统的冲突问题

很多单位在上网络准入认证系统之前，已经有了一些"半拉子"的认证机制——比如 AD 域用来管 Windows 登录、某款防火墙内置了一个简单的上网行为管理、某个部门自己搭了一套 RADIUS 服务。

这些系统不会在需求调研阶段主动暴露出来，因为各部门的人觉得这是"老东西"，不觉得跟新项目有关系。但等到网络准入认证系统部署时，就会发现冲突：新的 RADIUS 服务器和老的 RADIUS 服务器谁优先？AD 域的组策略和准入系统的合规检查规则能联动吗？防火墙的认证跳转和准入系统的 Portal 会不会打架？

规避这个问题的方式是在调研问卷里加一个专门的问题：目前网络中有哪些已在使用的认证相关机制，包括但不限于域认证、RADIUS、Web 认证、上网行为管理。把这些都摸清楚，才能在方案设计时做好对接或替换规划。

没有区分"认证"和"授权"的需求

需求方往往只说"要做准入认证"，但实际上准入认证系统里有两个核心动作——认证（确认是谁）和授权（决定能访问什么）。很多单位在调研阶段没有把这两件事分开谈清楚，导致方案设计时出现遗漏。

认证的需求相对简单：账号密码、证书、MAC 地址，选哪种方式认证。但授权的需求要复杂得多：认证通过之后，不同角色的用户应该被分配到哪个 VLAN？哪些终端只能访问特定的业务系统？访客能不能访问打印机？外部合作方的设备能不能接触财务系统？

这些授权策略如果在调研阶段没有梳理清楚，到了部署阶段就会变成反复改需求、反复调策略的麻烦。一个实操建议是在调研阶段专门安排一次"角色梳理会"，把公司里不同类型的用户和设备都列出来，每一类确认它应该有的网络访问权限。哪怕只是一张简单的 Excel 表，也比什么都没有要好得多。

对网络现状的摸底不够

网络准入认证系统不是独立部署的，它需要跟现有的网络基础设施联动。调研阶段如果没有把网络现状摸清楚，方案设计就是在沙地上盖楼。

需要摸清楚的内容包括：核心交换机和接入层交换机的品牌型号，是否支持 802.1X 或 VLAN 动态分配；无线 AC 控制器的品牌，是否支持 Portal 或 RADIUS 对接；网络拓扑里有没有不受控的网段，比如某个工厂车间或者分支机构的网络是否联通；有没有混用三层和二层，IP 地址规划是不是规整的。

这些信息不是靠问人问出来的，需要实际去查配置。调研阶段应该要求 IT 部门提供网络拓扑图和核心设备的型号清单，如果没有拓扑图，就需要临时画一张。很多项目在调研阶段跳过了这一步，等到部署时才发现接入层交换机不支持 802.1X，或者无线 AC 是几年前的老型号，只能走 MAC bypass，整个方案要大改。

把合规检查的颗粒度定得过于激进

有些单位在了解了网络准入认证系统的功能之后，一下子想要把所有合规检查项目都开起来：操作系统补丁必须更新到最新、杀毒软件必须是指定版本、必须安装 DLP 客户端、必须关闭 USB 口。这些要求本身没问题，但在需求调研阶段就把合规检查颗粒度定得这么细，往往会带来麻烦。

原因有两个。第一，这些规则在上线初期很容易误判，导致大量设备被拦截，影响正常业务，然后高层迫于压力要求把系统关掉或者设成旁路模式。第二，合规检查规则需要配合终端现状来制定，如果调研阶段没有摸清楚终端实际状态，就很难判断这些规则是否现实可执行。

建议在需求调研阶段，把合规检查分成"硬性要求"和"软性建议"两档。硬性要求是如果不满足就不允许接入的条件，这类应该尽量少、尽量保守；软性建议是如果不满足会有告警但仍然允许接入，这类可以多放一些。上线一段时间后，再根据实际情况逐步把软性建议升级为硬性要求。

没有确认谁是系统的长期运维责任人

这个问题看起来是管理问题，但它对技术方案选择有直接影响。如果未来长期运维的人是一个技术能力较弱的 IT 人员，那么系统就应该选管理界面简单、策略调整容易的产品，而不是功能强大但操作复杂的平台。如果长期运维的人手不够，那就需要在调研阶段明确哪些运维工作可以外包，哪些必须自主完成。

很多项目在调研阶段回避这个问题，等到系统上线后发现没人管，或者管的人看不懂界面，最后系统越来越多规则没人维护，合规检查越来越形同虚设。

在调研阶段，这个问题应该直接问清楚：系统上线后，日常运维由谁负责？对方的技术背景是什么？每天大概能投入多少时间？这些信息直接影响方案设计的复杂度和产品选型的方向。

调研结果没有形成可验证的文档

调研做完了，但只是停留在口头层面，没有形成书面文档，也没有让需求方确认签字。这在后期会变成很大的麻烦——方案设计完成后，需求方说"我们当时没有这个要求"，或者"我们的意思不是这个"，导致反复返工。

需求调研的结果应该形成一份结构化的文档，至少包含：网络现状描述（含拓扑图）、终端类型分布、现有认证机制清单、准入边界定义、用户角色与授权矩阵、合规检查要求清单。这份文档需要由需求方的关键负责人签字确认，才算调研阶段正式完成。

调研阶段多花一两周把这些细节搞清楚，大概率能省后面好几个月的麻烦。这不是在说废话，而是大多数项目里，出问题的环节往往都能追溯到某个调研阶段没问清楚的问题。