网络认证协议出问题，先别急着重启
办公室突然连不上Wi-Fi，提示“身份验证失败”；公司门禁系统刷了卡却没反应；远程办公时VPN登录反复弹窗要求输入密码——这些都可能和网络认证协议有关。很多人第一反应是重启设备，但治标不治本，真正的问题往往藏在认证流程的某个环节里。
从最基础的开始：确认客户端配置是否正确
最常见的问题是客户端配置错误。比如企业用的802.1X认证，员工自己改了无线设置里的EAP类型，从PEAP改成EAP-TLS，但本地没证书，自然连不上。这时候得回到原始配置核对一遍。
以Windows为例，在“管理无线网络”中找到对应SSID，检查安全选项卡里的设置：
网络身份验证方法：WPA2-Enterprise
加密类型：AES
EAP 类型：PEAP 或 EAP-TLS（根据实际环境）如果是Linux命令行连接，比如使用wpa_supplicant，配置片段应该是类似这样：
network={
ssid="Corp-WiFi"
key_mgmt=WPA-EAP
eap=PEAP
identity="username"
password="your_password"
phase2="auth=MSCHAPV2"
}服务器端日志不能忽视
客户端看着没问题，那就看服务端。RADIUS服务器（比如FreeRADIUS或Windows NPS）通常会记录每一次认证尝试。出现失败时，第一时间查日志比猜更有用。
比如在FreeRADIUS中，运行调试模式：
sudo radiusd -X你会看到详细的握手过程。如果卡在TLS握手阶段，可能是证书链不完整；如果提示“User not found”，那就是账号没同步到认证数据库。
证书问题太常见，尤其在PEAP和EAP-TLS中
很多公司用内部CA签发证书，但忘了把根证书推送到所有终端。用户连Wi-Fi时弹出“是否信任此证书”的提示，点了“否”，认证就中断了。这不是协议本身的问题，而是信任链断了。
解决办法很简单：确保设备上安装了正确的根CA证书。移动端可以通过MDM批量推送，PC端可以用组策略统一部署。
时间不同步也会导致认证失败
别小看时间差。Kerberos、TACACS+这类依赖时间戳的协议，如果客户端和服务端时间相差超过5分钟，直接拒绝认证。某次公司内网集体掉线，排查半天才发现是NTP服务器挂了，所有设备时间漂移严重。
检查方法也很直接：
timedatectl status # Linux
w32tm /query /status # Windows确保所有关键设备都指向同一个可靠的时间源。
防火墙和中间设备别忽略
有时候协议本身没问题，但数据包被拦了。比如RADIUS默认用UDP 1812端口，有些网络管理员只开了旧版的1645端口，新请求进不来。又或者防火墙策略限制了特定IP段访问认证服务器。
用tcpdump抓个包看看：
sudo tcpdump -i any port 1812 -n如果根本看不到请求出去，问题大概率出在网络路径上，而不是协议配置。
模拟测试更高效
与其让用户反复试错，不如用工具模拟认证过程。radtest是FreeRADIUS自带的小工具，可以快速验证一个账号能否通过认证：
radtest username password radius-server-ip 0 testing123返回Accept-Reject一目了然。配合wireshark抓包，还能看清EAP交换的每一步。
老旧设备兼容性问题
某些老打印机、监控摄像头只支持WPA-PSK，硬要接入802.1X网络肯定不行。这时候要么单独划个非认证VLAN，要么启用MAC旁路认证（MAB），让设备靠MAC地址过审。
但MAB也有风险，比如MAC地址伪造。建议只在必要场景开启，并配合端口安全策略。