802.1x认证，eap-tls方式，认证不成功

你的分析方向非常准确，这个“type=25”的EAP-PEAP报文正是定位问题的关键线索。根据你的描述和典型的工程经验，这个问题通常源于 H3C 交换机的 EAP 认证模式配置，或是与华为 NCE 之间的协议协商出现了差错。

你可以按照以下逻辑，分三步来精准定位和解决问题：

 第一步：确认交换机的认证模式 (高概率原因)

H3C 交换机默认的 802.1x 认证方法是 chap（EAP 终结模式），在这种模式下交换机不会透传 EAP 报文，可能会错误地发起 PEAP 协商，从而导致当前问题。

• 排查命令：登录交换机，使用 display dot1x | include authentication-method 命令检查全局 802.1x 的认证方法。

• 期望结果：正确支持 EAP-TLS 的模式必须是 eap（EAP 中继模式）。

• 修正方法：如果输出不是 eap，请务必在保存配置备份后，进入系统视图执行 dot1x authentication-method eap 命令进行修改。

这里也可以检查是否配置了 eap-profile 模板。如果不需要本地终结 EAP，建议直接删除端口下的绑定；如果确实需要，请确保模板内的 authentication-type 正确配置为 tls，而不是 peap。

 第二步：排查EAP类型错配 (报文分析与抓包)

如果第一步配置正确但问题依旧，就需要通过抓包来分析报文在路径上的真实情况。

1. 检查终端发起的认证请求：镜像终端接入的交换机端口入方向流量，确认终端发出的第一个EAP响应报文（EAP Response/Identity）和后续的EAP-TLS协商报文类型是否为 13 (EAP-TLS)。同时，在交换机上开启 debugging dot1x packet 调试，观察交换机是否正确透传了这些报文，还是会主动将其篡改为 type=25 (PEAP) 的报文。

2. 检查发往NCE的报文：镜像交换机和华为NCE之间的互联端口流量，分析发往NCE的RADIUS报文，确认其中封装的EAP类型是否正常。如果此处的报文类型正确，则问题可能出在NCE侧的处理上。

 第三步：排查认证流程断联 (RADIUS可达性)

如果你发现认证请求根本没有到达服务器侧（例如 display radius statistics 看不到相关统计信息，debugging radius packet 也没有任何输出），则需要排查交换机的RADIUS配置：

1. 检查NAC配置模式：请登录NCE-Campus，在“准入控制”或“认证授权”相关配置中，确认针对这台H3C交换机（作为NAS设备）的策略。如果NCE上配置了某种“代理”模式（例如用于对接第三方RADIUS服务器），可能需要检查其EAP透传规则是否与H3C的报文格式兼容。

2. 检查RADIUS可达性：首先，确认交换机上RADIUS方案的配置是否正确，包括服务器IP、端口（认证端口通常为1812）和共享密钥。

3. 检查网络连通性：确认交换机与NCE-Campus服务器之间的IP网络是连通的，且交换机上用于和NCE通信的VLAN接口（例如VLAN 1）与NCE之间路由可达。有时交换机默认路由指向错误，导致RADIUS报文无法发出。

4. 检查NAC配置模式：请登录NCE-Campus，在“准入控制”或“认证授权”相关配置中，确认针对这台H3C交换机（作为NAS设备）的策略。如果NCE上配置了某种“代理”模式（例如用于对接第三方RADIUS服务器），可能需要检查其EAP透传规则是否与H3C的报文格式兼容。

你这个现象 100% 是：交换机强制把 EAP-TLS 改成了 EAP-PEAP（Type 25），终端 / 服务器不认可，所以直接卡死、无成功无失败、无 RADIUS 报文。而且你是H3C 交换机 ↔ 华为 NCE 组合，和华为交换机环境不一样，EAP 协商模式默认配置不一致，这是跨厂商最常见坑。
一、先解释关键异常：EAP Type=25
EAP Type 25 = PEAP
你要用的是 EAP Type 13 = EAP-TLS
日志出现 type=25，说明：H3C 交换机在 EAP 协商阶段，主动向终端发送了 EAP-PEAP 请求，而不是透传 EAP-TLS。
原因只有一个：H3C 交换机默认开启了 EAP 中继 / EAP 终结模式，没有纯透传 EAP-TLS，自己篡改了认证类型。
二、为什么华为交换机可以，H3C 不行？
华为交换机：默认 EAP 透明透传，EAP 报文直接丢给 NCE/NPS，不干预类型。
H3C 交换机：默认开启 EAP 终结 / EAP 中继，会自己和终端做 EAP 协商，优先 PEAP。
结果就是：H3C 交换机 → 发 Type25 PEAP → 终端用证书 TLS 回应 → 不匹配 → 卡死→ 没有成功、没有失败、没有 RADIUS 包→ debug 干干净净，就是不通
三、排查思路（按顺序做，做一步通一步）
1. 强制交换机 EAP 模式为 EAP-Transparent（透传模式）
这是最关键一步，必须在全局或接口下配置：
bash
运行
system-view
dot1x authentication-method eap # 必须是EAP，不能是CHAP/PAP
dot1x eap trans transmit # 核心：EAP透传，交换机不处理EAP类型
如果是老版本命令，可能是：
bash
运行
dot1x eap transparent
作用：交换机不再自己发 PEAP（Type25），完全透传 EAP 报文给 NCE → 恢复 EAP-TLS。
2. 关闭交换机自带的 EAP 协商 / PEAP 强制
bash
运行
undo dot1x eap-server enable # 关闭交换机内置EAP服务器
undo dot1x eap-peap # 禁止PEAP
undo dot1x eap-fast
undo dot1x eap-ttls
让交换机只做 802.1X 报文透传，不参与 EAP 类型选择。
3. 接口下强制 EAP 透传（必配）
bash
运行
interface GigabitEthernet1/0/1
dot1x authentication-method eap
dot1x eap trans transmit
port-security access-rule deny eap-type peap # 可选：直接拒绝PEAP
4. 检查 RADIUS 配置 EAP 类型
H3C 对接华为 NCE，必须：
bash
运行
radius scheme XXX
server-type extended # 标准RADIUS，不要华为兼容模式
accounting-on enable
user-name-format without-domain # 域要统一
不能配：
bash
运行
server-type huawei
配了会直接乱改 EAP 类型。
5. 检查 NCE 侧是否强制 PEAP
虽然你配置 TLS，但 NCE 可能：
开启了 “允许 fallback 到 PEAP”
或 H3C 交换机报文中 EAP 类型被识别为 PEAP
让 NCE 只允许 EAP-TLS，关闭其他 EAP 类型。
6. 抓包定位（最准）
在交换机镜像端口抓：
终端 → 交换机：发的是 EAP-TLS（Type13）
交换机 → 终端：发的是 EAP-PEAP（Type25）
只要抓到这个，就100% 是交换机 EAP 模式问题，不是 NCE、不是证书、不是 NPS。
四、你现在的现象完全匹配
无 EAP success/fail
无 RADIUS 接受 / 拒绝
debug 无报错
出现 EAP Type=25 PEAP
华为交换机正常，H3C 不正常
全部指向：H3C 交换机 EAP 非透传，自己发 PEAP 破坏 TLS 协商。
五、最终最简修复配置（直接粘贴）
bash
运行
system-view
dot1x authentication-method eap
dot1x eap trans transmit
undo dot1x eap-server enable

# 接口下
interface GigabitEthernet1/0/1
dot1x authentication-method eap
dot1x eap trans transmit
配置完重连终端，立刻恢复 EAP-TLS，Type25 消失。