🎯 最可能的 4 个根因

1. Win10 客户端 EAP 配置 / Credential Guard 冲突（最高频）

• Credential Guard 开启时，MSCHAPv2 无法工作。如果你的 SSID 用的是 PEAP-MSCHAPv2，Win10 启用了 Credential Guard 就会直接导致认证失败
• EAP 类型不匹配：AC/Radius 侧要求 PEAP，但 Win10 无线网卡属性里勾选的 EAP 方法不一致（比如选成了 EAP-TLS 但客户端没有证书）
• 服务器证书不被信任：PEAP 阶段服务器下发证书，Win10 本地"受信任的根证书颁发机构"里没有对应的 CA 根证书，握手直接断掉——AC 侧就表现为收到 deauth
• Win10 11 月更新后引入的 TLS 1.2 兼容性 bug：部分 RADIUS 实现（早期 FreeRADIUS、Aruba ClearPass 6.5.1、Cisco ISE 2.0.0.306 等）在 EAP 协商时使用 TLS 1.2 会因 PRF 错误导致 MPPE 密钥计算失败，认证被强制中断

💡 现场验证法：找一台没加域、没开 Credential Guard​ 的 Win10 笔记本，手动新建 802.1X 配置文件，明确指定 EAP 类型（PEAP-MSCHAPv2 或 EAP-TLS），并在"服务器证书信任"里装上 RADIUS 服务器的 CA 根证书再试。如果这样能上，问题 100% 在客户端策略。

2. AC 侧 service-template 的 802.1X 配置不对

• service-template 下认证模式必须是 dot1x：client-security authentication-mode dot1x
• 全局 802.1X 认证方式必须是 EAP 中继：dot1x authentication-method eap（如果用默认的 chap 终结，EAP 报文不会透传给 RADIUS，必然失败）
• 认证域调用正确：service-template 里 dot1x domain xxx 指向的域，其下 authentication lan-access radius-scheme xxx 要正确绑定
• 本地用户的 service-type 必须是 wlan-service（不是 lan-access，无线不认 lan-access）

3. RADIUS 服务器侧问题

• 共享密钥不一致：AC 上 radius scheme 里的 key 与 RADIUS 服务器上配置的 NAS 密钥必须完全一致（区分大小写）
• nas-ip 没在 RADIUS 上登记：服务器"客户端列表"里必须有 AC 的 nas-ip，否则直接 Access-Reject
• RADIUS 上用户 service-type 不对：无线用户需要 wlan-service，若只开了 lan-access 会被拒
• AAA 返回错误码：新华三 AC 日志里若能看到 error code，8 一般是密钥/端口(1812)/不可达，26 一般是用户名密码错/认证类型错/服务器没加设备 IP/域配置错

⚠️ 一个隐蔽坑：如果 AC 上游交换机在 RADIUS 服务器方向配置了镜像，会导致 RADIUS 服务器收到两份相同的 EAP 报文，服务器判定异常并返回 Reject——这种故障表现就是客户端反复 deauth。

4. EAP 中继超时或固件兼容性

• AC 默认 dot1x timer supp-timeout 是 30 秒，Win10 在某些 EAP 步骤（证书协商）会慢，可能触发超时 deauth——可临时调大到 60 秒验证
• AC 固件过老对 Win10 新补丁包的 EAP 兼容性差，建议升级到对应产品的最新稳定版

🔧 现场排查顺序（照着做，30 分钟内定位）

1. 缩小范围：找一台能装 H3C iNode 客户端的 Win10 连同一个 802.1X SSID。iNode 能上 → 100% 是 Win10 原生 supplicant 的策略/证书/Credential Guard 问题；iNode 也上不了 → 问题在网络侧
2. AC 上开 debug 抓现场：
   debugging dot1x all debugging radius all debugging wlan client mac xxxx-xxxx-xxxx
   
   看 EAP 协商断在哪一步：是 Access-Challenge 没回去？还是 Access-Reject？还是根本没收到 RADIUS 响应？
3. 查 RADIUS 服务器日志：看是 Access-Accept、Access-Reject 还是无响应。Reject 带 Reason Code 的话直接定位
4. 检查 AC 上的关键配置：
   display dot1x display radius scheme 你的radius方案名 display domain 你的域
   
   确认 dot1x authentication-method eap、service-template 的 client-security authentication-mode dot1x、dot1x domain 都没错
5. 核对密钥与 nas-ip：
   display radius scheme 你的radius方案名
   
   RADIUS 服务器上登记的 AC nas-ip + 共享密钥必须与 AC 上配置一字不差

📌 给你的判断

• iNode 能上 → 问题在 Win10 原生客户端，按上面"根因 1"处理（关 Credential Guard / 装 CA 证书 / 明确 EAP 类型）
• iNode 也上不了 → 问题在 AC 或 RADIUS 侧，按"根因 2/3"用 debug 命令抓包定位

错误代码 2018 提示 Received deauthentication packet in Userauth state，这意味着在 802.1X 认证的关键阶段，客户端（你的Win10电脑）主动向AC（无线控制器）发送了一个“解除认证”（Deauthentication）报文，中断了认证过程。

这并非AC主动拒绝你，而是你的电脑“喊停”了这次认证。同一个AP上的其他SSID（如Portal认证）能连上，也说明AC和AP的物理硬件及信号是正常的，问题大概率出在 802.1X 认证的配置或协商细节上。

 可能的原因与解决方案

请从客户端和服务端两个方向排查：

在客户端（Windows 10电脑）

1. 检查无线网卡设置（高优先级）

   • 确认认证模式：在无线网卡的“安全”设置中，确保“选择网络身份验证方法”明确选为“Microsoft: 受保护的EAP (PEAP)”或与你服务器匹配的方法。

   • 关闭快速漫游（802.11r）：在网卡高级设置中，尝试禁用“快速漫游”或“802.11r”功能。该功能与部分认证服务器存在兼容性问题，可能导致中断。

   • 尝试“用户身份验证”：如果设置里有“指定认证模式”，尝试选择“用户身份验证”。

   • 更新或回滚网卡驱动：不兼容的驱动，尤其是Intel网卡的“ProSet”工具，是常见诱因。

2. 检查系统证书与账户

   • 检查证书：如果认证需要客户端证书，请确认它有效、未过期且被系统信任。

   • 检查登录账户：确认你登录Windows的账户，与用于802.1X认证的账户权限一致。

在服务端（AC / Radius服务器）

1. 核对设备配置一致性（高优先级）

   • 共享密钥：这是最易出错的地方，请仔细核对AC和Radius服务器上的共享密钥（Secret Key） 是否完全一致。

   • 认证端口：确保Radius服务器上的认证端口（默认1812）已开启且未被ACL拦截。

   • 服务模板配置：检查AC上对应的无线服务模板，确认其认证方式、加密套件等配置正确。

   • 检查“清除历史连接”：在AC上启用 clear-previous-connection 功能，可解决客户端异常离线导致的重复认证问题。

2. 检查网络与服务器状态

   • 网络连通性：确保AC与Radius服务器之间路由可达。

   • 服务器日志：查看Radius服务器的认证日志，寻找来自AC IP的失败记录，错误日志能提供最直接的线索。

3. 排查AC的AAA配置

   • 认证域：确认服务模板下引用的认证域（ISP域）在AC上存在且配置正确。

   • RADIUS方案：仔细检查AC上配置的RADIUS方案，确保服务器IP、端口、共享密钥等与Radius服务器侧保持一致。

Win10 无线 802.1X 错误代码 2018 Received deauthentication packet in Userauth state

现象：同一个 AP，Portal‑SSID 可以正常连接上网；802.1X‑SSID 认证失败报 2018知了社区。 释义日志含义：终端处在 802.1X 用户认证状态机还未完成 EAP 协商，就收到 Deauth 解除认证帧；射频、关联、底层 VLAN、AP 硬件全部没问题，故障锁定在 802.1X EAP 协商 / RADIUS 交互 / Windows 客户端 Supplicant 这一条链路知了社区。

Portal SSID 正常证明：AP 射频、CAPWAP、业务 VLAN、DHCP、有线转发全部工作正常，不要往射频干扰、信道、功率方向排查。

概率从高到低根因与排障

1、Windows 客户端侧（最高概率，PEAP‑MSCHAPv2 环境最常见）

1）Credential Guard 与 PEAP 冲突（Win10 企业版典型坑） 开启 Credential Guard 后会破坏 PEAP‑MS‑CHAPv2 握手，认证中途 Windows 主动发送 deauth，抛出 2018 错误。

• 验证：组策略关闭 Credential Guard，测试重连 802.1X SSID。

2）Windows WLAN‑AutoConfig 高级设置问题

• 802.1X 高级设置里勾选了启用单点登录（SSO），在用户登录前执行；同时机器认证 / 用户认证模式混用，EAP 握手中途中断发出 deauth 帧Microsoft ...。

修改：WLAN 属性‑安全‑高级设置：

• 取消【启用单点登录】；
• 指定认证模式为仅用户认证（不要机器 + 用户混合）。

3）根 CA 证书未被 Windows 客户端信任（PEAP） RADIUS (NPS) 服务器证书的根证书没有导入电脑【受信任的根证书颁发机构】，Windows 校验服务器证书失败，客户端主动发出 Deauth 断开，日志报 2018，不会弹出证书告警。

重点：不是看服务器，看每台 Win10 终端本地证书存储。

4）Windows 系统时间偏移 终端时间和 RADIUS 服务器时间偏差 > 5 分钟，证书校验直接失败，终端主动 deauth。

客户端查看详细报错：事件查看器 → 应用程序和服务日志‑Microsoft‑Windows‑WLAN‑AutoConfig‑操作日志，看对应事件 ID 详细原因码Microsoft ...。

2、AC/WLAN 服务模板配置侧

1）认证位置与转发模式不匹配（Comware V7 高频坑）

• 如果是 tunnel 隧道转发：authentication‑location ac（认证必须放在 AC）
• 如果是 direct‑forward 本地转发：authentication‑location ap（认证放 AP）

转发模式和认证位置写反，EAPOL 报文处理异常，握手中途 AP/AC 下发 deauth 帧，报 2018；Portal 不受该参数影响，所以另外 SSID 正常上网H3C。

2）dot1x EAP 模式不匹配

NPS 微软 RADIUS 用standard；部分第三方需要extended；配置错误 EAP 报文解析异常，中途断开。

3）ISP 域、RADIUS 配置检查

• 802.1X SSID 绑定的 ISP 域，必须配置正确 RADIUS 方案；
• RADIUS 方案开启 eap；nas‑ip配置正确；共享密钥完全一致；

Portal SSID 使用另外一套 ISP 域 / RADIUS，不受影响，所以 Portal 可以通。

3、RADIUS (NPS) 服务器侧

1）NPS 策略拒绝 EAP 握手，返回 Access‑Reject，AC 收到拒绝后下发 deauth 给终端。

在 NPS 服务器看安全日志 事件 ID 6273，查看拒绝原因码（原因码 16/22/48/66 等）直接定位账号、证书、网络策略问题Microsoft ...。 2）NPS 服务器证书过期、证书 EKU 属性缺失（缺少服务器身份验证）。

现场快速定位命令（AC 上执行）

最简验证测试

1. 拿手机（安卓 / IOS）连接该 802.1X SSID；

• ✅手机能连上，只有 Win10 报 2018 → 100% 故障点在 Windows 电脑客户端侧（证书 / CredentialGuard/SSO 配置）。
• ❌手机同样 802.1X 认证失败 → 故障点在 AC 配置 / RADIUS 服务器。

处理步骤建议顺序

1. 使用手机测试 802.1X SSID，区分是客户端问题还是网络侧问题；
2. Win10 终端：检查根证书信任、关闭单点登录 SSO、关闭 Credential‑Guard；
3. AC 核对client‑security authentication‑location必须和转发模式（tunnel/direct‑forward）严格匹配；
4. 登录 RADIUS (NPS) 查看 6273 拒绝事件，拿到拒绝原因码；
5. 打开 AC debugging dot1x event，复现故障看 EAP 交互完整流程。

补充：错误 2018 只是结果表象，是谁发出 deauth 帧才是根因：

• Windows 终端自己发出 Deauth → 客户端证书 / 安全设置；
• AP/AC 下发 Deauth → 802.1X 状态机收到 RADIUS 拒绝报文。