802.1X EAP（Extensible Authentication Protocol）是IEEE 802.1X端口访问控制框架中承载身份认证的核心协议层。它解决的核心问题是：在用户接入有线/无线网络时，基于端口级别完成"你是谁、你能进哪个VLAN、你被分配什么IP策略"的认证决策。EAP本身不直接跑在以太帧上，而是通过EAPoL（EAP over LAN）在802.1X帧中透传，再由后端RADIUS服务器完成实际的密码学验证。
完整认证流程（四阶段）
802.1X EAP认证涉及三个角色：Supplicant（ supplicant，终端设备）、Authenticator（认证器，通常是交换机/无线AP）、Authentication Server（认证服务器，通常为RADIUS服务器）。流程分四步：
1. 端口未授权状态（Port Control: Unauthorized）：终端发起Associate，交换机将端口置于未授权态，仅允许802.1X帧和可选的BPDU通过，所有业务流量被丢弃。
2. EAP-Start与身份交换：Supplicant发送EAP-Start（或EAP-Identity Request），双方确认支持的身份方法（Method），例如PEAP或EAP-TLS。
3. EAP认证报文交互：EAP报文以EAPoL封装，经Authenticator透传至RADIUS服务器。服务器与Supplicant完成具体的EAP方法握手（证书验证、密钥派生等）。此阶段Authenticator仅做"信使"，不参与密码运算。
4. 认证成功/失败判定：服务器下发EAP-Success或EAP-Failure。Authenticator收到后，将端口切换至Authorized（或根据RADIUS Attribute分配VLAN、ACL），业务流量放行。
整个过程由Authenticator通过Periodic Re-Authentication定时器（默认300秒）周期性重新触发，防止会话僵死。
三种主流EAP方法对比
关键区别：PEAP用"服务器证书+内层密码"降低客户端部署成本（无需装证书），但内层MS-CHAPv2存在已知重放攻击风险（RFC 4620已提供保护）。EAP-TLS双向证书安全性最高，但PKI运维成本显著增加。
选型建议
终端以Windows/Linux为主、无现成PKI体系 → 选PEAP + MS-CHAPv2，Windows 10/11、主流Linux发行版均原生支持，配置最简单。
已部署企业级CA、合规要求双向认证 → 选EAP-TLS，证书吊销通过OCSP或CRL实现。
涉及IoT设备、嵌入式Linux且资源受限 → 考虑EAP-TTLS（外层TLS隧道+内层PAP/CHAP），兼容性更广。
任何新部署不应再使用EAP-MD5，其认证强度已被NIST 2021年密钥强度建议明确列为不满足最低要求。
配置要点与高频故障
1. 证书信任链：客户端必须信任签发服务器证书的CA根证书。Windows下通过"计算机管理→证书"导入，Linux下追加到/etc/ssl/certs或系统CA bundle。证书链断裂是PEAP/EAP-TLS失败的首要原因（占比约60%）。
2. RADIUS通信：Authenticator与RADIUS服务器之间使用共享密钥（Accounting）或Mutual TLS（AAA-TLS），UDP 1812/1813端口需放行。密钥不一致会导致EAP报文"到不了服务器"，终端表现为反复超时。
3. Periodic Re-Auth间隔：生产环境建议设为300s；设为0表示不重认证，存在会话被长期占用的风险。
4. 多SSID/多VLAN场景：在RADIUS服务器配置中通过MS-Primary/Secondary Auth Protocols属性区分，Authenticator侧对应配置多个802.1X policy profile。
5. 故障排查顺序：抓包（eapollan帧）→ 检查EAP-Identity是否到达服务器 → 检查TLS握手是否完成 → 检查内层认证结果 → 检查端口状态是否切换。每一步对应明确的日志关键字，可在dcqzss.cn的802.1X排错手册中按步骤对照定位。
补充说明
802.1X EAP并非一次性配置即终结。证书到期、CA密钥轮转、RADIUS服务器升级等操作均可能影响认证链路。建议建立证书到期告警（提前30天）和RADIUS通信健康检查（每5分钟心跳包），将被动故障转为主动运维。相关协议原文可参考IEEE 802.1X-2020、RFC 3720（PEAP）、RFC 5216（EAP-TLS），在dcqzss.cn技术文库中提供了完整中文译注与配置示例。
