本指南旨在为管理员提供一套系统化的排查流程，用于解决员工在使用 802.1x 进行无线认证时遇到的各类问题，包括认证失败、认证成功但无法上网、客户端状态显示异常等。

请先阅读网络准入常见问题，确认您遇到的问题是否已有对应的快速解决方案。若上述文档未能解决您的问题，请遵循本文提供的排查步骤进行深度诊断。

在开始之前，请参考以下流程，快速定位问题所在环节并跳转至相应排查步骤。

1. 指导员工快速自查
   • 目标：快速排除最常见、最简单的终端用户侧问题。
   • 内容：包括检查客户端模块、系统服务（如定位）以及重启重连等基本操作。
2. 管理员后台排查
   • 目标：在员工自查无效后，进入管理后台核对服务端的配置问题。
   • 内容：包括检查账号生效范围、SSID/共享密钥配置，以及排查终端上的软件冲突或组策略。
3. 深度诊断分析
   • 目标：当前两步都无法解决问题时，深入技术底层，分析认证过程中的具体故障点。
   • 内容：通过分析 RADIUS 日志和网络抓包，判断认证请求是在哪个环节（客户端、网络链路、RADIUS 服务器）失败，并根据具体的错误码或报文进行精准定位。

当员工报告问题时，请首先通过远程协助或沟通，指导其完成以下三个步骤，快速排除最常见的终端侧问题。

步骤 1.1：检查飞连客户端 Wi-Fi 模块 #

引导员工查看飞连客户端界面的“网络”选项中是否显示“Wi-Fi”模块。

• 无 Wi-Fi 模块：该员工的账号很可能未被纳入 802.1x 认证的生效范围。请参考步骤 2.1 检查项 ①：确认账号是否生效。
• 有 Wi-Fi 模块：请继续执行步骤 1.2 的排查操作。

步骤 1.2：检查操作系统定位服务 (Windows 高频问题） #

Windows 10/11 操作系统将“获取附近 Wi-Fi 列表”的权限划归为“定位”功能的一部分。如果定位服务被禁用，飞连客户端将无法获取到 Wi-Fi 状态，从而可能误报“连接失败”。
请引导员工检查电脑的定位服务是否开启。

1. 打开 Windows 设置。
2. 进入隐私和安全性 ＞ 位置。
3. 确保定位服务开关已打开。
4. 指导员工重启飞连客户端，查看状态是否恢复正常。

步骤 1.3：尝试重启与重新认证 #

引导员工执行以下操作，完成设备重启和重新认证。

1. 请员工完全退出飞连客户端。
2. 在系统网络设置中，断开并“忘记”当前连接的企业 Wi-Fi (SSID)。
3. 重启计算机。
4. 重新打开飞连客户端，再次尝试一键认证。

如果员工完成以上自查后问题仍然存在，请继续执行第二部分：管理员后台排查。

在指导员工完成第一部分自查后，请您登录管理后台，按顺序进行以下配置检查。

步骤 2.1：检查员工入网认证配置 #

检查项 ①：确认账号是否生效 #

1. 在管理后台，导航至网络准入 ＞ 员工入网 ＞ 通用配置。
2. 展开 802.1x 认证协议模块，点击右上角编辑。
3. 在飞连账号认证形式的生效范围中，确认故障员工的账号或其所属的部门/角色已被勾选。

检查项 ②：严格比对 SSID 名称 #

1. 在管理后台，导航至网络准入 ＞ 使用配置 ＞ SSID。
2. 在员工 Wi-Fi 中，全选并复制 SSID 名称框内的所有字符。
3. 登录 AC 设备的管理界面，找到对应的 SSID 配置，全选并复制其名称。
4. 将两次复制的内容粘贴至文本比对工具中，确保完全一致，不含任何肉眼不可见的空格或特殊字符。

检查项 ③：检查 RADIUS 共享密钥 #

1. 在管理后台，导航至网络准入 ＞ 使用配置 ＞ 网络设备。
2. 点击进入 AC 设备详情页面，查看设备的共享密钥。
3. 登录 AC 设备，找到 RADIUS 服务器配置部分，确保其配置的共享密钥与飞连平台完全一致。不一致将导致认证请求被直接拒绝。

步骤 2.2：检查终端环境 #

检查项 ①：第三方软件冲突 #

检查员工设备上是否安装了其他网络准入、终端安全、防病毒或 VPN 客户端。若已安装，建议指导员工尝试临时卸载这些软件（仅仅禁用可能无效），然后重启电脑再次认证，以排除冲突可能。

检查项 ②：组策略 （GPO） 限制 （针对已加域的 Windows 设备） #

若员工设备加入了公司域，可能存在强制的无线网络策略，会覆盖飞连的配置。
若您的环境中有 AD 域控，请与域管理员协作，确认是否存在针对“无线网络策略”或“802.1X 设置”的 GPO。可请求临时禁用该策略进行测试。

若前述配置核查与环境检查均未能解决问题，则需启动深度诊断流程。
802.1x 认证的数据流路径为：终端客户端 → 无线网络设备 (AP/AC) → 飞连 RADIUS 服务器。深度诊断的目标是精确定位此路径中的故障域。

关键诊断工具 #

1. 飞连 RADIUS 日志：用于分析服务端接收的认证请求及其处理结果。
   • 默认路径：/opt/feilian/radius/log/radius.event.log（具体路径以实际部署为准）。
2. 网络协议分析器：用于捕获并分析网络报文，以判断认证请求的发出与到达状态。
   • Windows 环境：Wireshark 或 Microsoft Network Monitor。
   • macOS 环境：Wireshark 或系统内置的 tcpdump 命令行工具。

步骤 3.1：分析 RADIUS 服务端日志 #

登录飞连 RADIUS 服务器，在故障员工尝试认证的同时，使用 tail 或 grep 等命令实时监控日志文件。
日志分析结论：

• 情况 A：日志中存在该用户的认证记录
  • 结论：​认证请求已由无线网络设备 (AC) 成功转发至 RADIUS 服务器。故障点位于 RADIUS 服务器的处理逻辑或认证成功后的网络分配阶段。
  • 后续步骤：​请继续执行步骤 3.2：解读 RADIUS 认证日志
• 情况 B：日志中不存在该用户的认证记录
  • 结论：​认证请求在从终端发出后，到达 RADIUS 服务器之前的路径中发生丢失。故障域为终端、无线网络或两者之间的链路。
  • 后续步骤：​请继续执行步骤 3.3：客户端与网络链路深度分析。

步骤 3.2：解读 RADIUS 认证日志 #

在日志条目中，请首先检查是否存在系统级报错；若无系统报错，则重点分析 connResult 字段的取值。

系统/协议级故障 #

若日志中出现以下报错，说明 RADIUS 节点与网络设备（AC）之间的底层对接存在问题，认证请求在进入用户信息校验前已被拦截。

用户会话级结果 #

connResult = 1（认证成功）

• 故障现象：​日志记录为认证成功，但员工终端无法访问网络。
• 分析方向：​认证流程已完成，问题转移至认证后的网络访问控制或资源分配环节。
  1. 检查 IP 地址分配：在员工终端上执行 ipconfig (Windows) 或 ifconfig (macOS/Linux)，检验是否已获取有效的 IP 地址。
  2. 排查 DHCP 服务：
     • 若未获取 IP 地址，需检查 RADIUS 日志中为该次会话下发的 VLAN ID 是否正确。
     • 与网络管理团队协作，确认目标 VLAN 内的 DHCP 服务是否运行正常、地址池是否充足。
  3. 排查网络访问策略：
     • 若已获取 IP 地址但无法访问网络，需检查该 VLAN 或源 IP 网段的防火墙访问控制列表 (ACL)、路由策略是否已正确配置，以允许目标流量通过。

connResult = 2（认证失败）

• 故障现象：​日志明确记录认证失败。
• 分析方向：​需根据日志中的 remark 字段或其他错误信息，定位具体的失败原因。

connResult = 3（认证降级）

• 故障现象：​用户被分配至隔离的、访问权限受限的网络。
• 分析方向：​用户认证成功，但其终端状态未能满足特定的安全合规策略。
  • 检查飞连后台的动态控制策略，确认是否因终端不合规（如缺少指定安全软件、操作系统补丁版本过低等）而被策略性地分配至隔离网络。

步骤 3.3：客户端与网络链路深度分析 #

当 RADIUS 服务端日志中无相关认证记录时，说明认证请求未到达飞连服务器。此时，需在故障终端上通过抓包判断请求是“发不出”还是“传不到”。

① 启动网络抓包 #

在终端上使用 Wireshark 或 Microsoft Network Monitor 抓取无线网卡报文。

• 过滤器表达式：eapol（用于筛选 802.1x 认证核心协议报文）。

② 分析抓包结论与对策 #

• 情况 A：捕获到 EAPoL-Start 或 EAP-Request 报文，但未收到 EAP-Response
  • 结论：​客户端已发出认证请求，但该请求在无线网络设备 (AC) 或 AC 至 RADIUS 服务器的网络路径中丢失。
  • 排查方向：
    1. AC 配置核查：
       • 登录 AC 设备管理界面，核对 RADIUS 服务器的 IP 地址和认证端口（应为 UDP 1812） 是否配置无误。
       • 参照设备厂商的官方技术文档，验证 802.1x 相关配置的完整性与正确性。
    2. 网络路径连通性：
       • 在 AC 设备的命令行界面，使用 ping 或 traceroute 等工具测试到 RADIUS 服务器 IP 的网络可达性。
       • 与网络安全团队协作，检查 AC 与 RADIUS 服务器之间的防火墙或网络 ACL，确保 UDP 1812 端口的流量未被拦截。
• 情况 B：未捕获到任何 EAPoL 报文
  • 结论：​客户端未能成功发起 802.1x 认证流程。
  • 排查方向：
    1. SSID 配置不匹配：这是导致此现象的最常见原因。请遵循步骤 2.1 中检查项 ②：严格比对 SSID 名称的指引，使用文本比对工具确保飞连平台与 AC 设备上的 SSID 配置完全一致。
    2. 终端环境问题：若 SSID 确认无误，则故障根源极有可能在于终端本身。请返回并严格执行步骤 2.2：检查终端环境中的所有步骤，以排查软件冲突或组策略限制。
    3. 模块内部深度诊断：若配置一致但网卡无动静，说明客户端内部流程被拦截。请根据飞连管理后台网络准入 ＞ 员工入网 ＞ 通用配置 ＞ 802.1x 认证协议 ＞ 高级策略 ＞ Windows 系统 802.1x 认证模块中选择的入网模块类型进行深度日志审计：
       1. 场景一：若使用 Windows 系统默认模块
          飞连作为“配置员”将 XML 配置文件写入系统，由 Windows 驱动认证。
          • 审计重点：检查飞连是否有权操作系统配置。
          • 日志路径：查看客户端安装目录下的 logs\corplink.log。
          • 关键搜索词：搜索 ConnectWiFi（无线）或 ConfigWiredNetwork（有线）。
          • 定位分析：
            • 若日志提示 write config file error：说明 corplink-service.exe 对 data 目录无写权限，配置未生成。
            • 若日志提示 write xmluserdata file error：说明 win-helper.exe 进程被杀软拦截或无读权限，配置未下发给系统。
       2. 场景 2：若使用飞连自研入网模块
          飞连自行管理握手协议，提供精细化的阶段审计。

          • 审计重点：利用 Event ID 定位认证在哪个环节中断。

          • 日志路径：Windows 事件查看器 ＞ 应用程序 (Application) ＞ 过滤来源：CorpLinkNetAuth。

          • 关键事件 ID 审计表：

            事件 ID	含义	诊断建议
            ID 16	认证握手开始	若无此 ID：说明网卡被组策略 (GPO) 禁用或驱动不兼容，导致流程未启动。
            ID 1	凭据下发	若卡在此处：显示使用的身份（User/Machine）。若报错，查身份源密码或证书私钥读取权限。
            ID 6	证书校验	若卡在此处：显示服务端证书信息。若失败，说明客户端不信任 RADIUS 颁发的证书，需检查白名单策略。
            ID 18	收到 Success 包	若 RADIUS 日志显示成功但此处无 ID 18：说明回程报文被防火墙拦截，导致“单向通航”。

            如果通过以上审计发现 ID 16 已经出现但抓包依然为空，通常意味着操作系统底层的 WLAN-AutoConfig 服务已损坏或被其他准入软件强行接管。建议尝试“忘记网络”并重启该系统服务。

如果已完成上述所有排查步骤但问题仍未解决，请准备以下信息并联系飞连技术支持团队，以便我们高效地为您定位问题。

• 如果您是飞连认证渠道工程师：请通过飞书搜索飞连 FOC，提交工单处理。
• 如果您是企业用户：请通过火山引擎官网提交工单处理。

信息收集清单 #

1. 问题描述：包括故障现象、影响范围（单个/多个员工、特定区域/设备型号）。
2. 已执行的排查记录：简要说明您执行了哪些步骤，以及每个步骤的检查结果（附截图更佳）。
3. 故障发生时间点：精确到分钟。
4. 相关日志与文件：
   • 故障终端的飞连客户端日志。
   • 对应时间点的飞连 RADIUS 日志 (radius.event.log)。
   • 在终端和 RADIUS 服务器上抓取的网络包文件 (.pcapng 或 .pcap)。

为从源头减少潜在问题，建议参考以下原则，预防故障发生：

• 部署阶段：在项目初期，应依据官方入网配置指南，对网络架构与认证参数进行合理规划与标准化，避免因配置疏漏或不一致引发问题。
• 排障阶段：在处理故障时，应以 RADIUS 认证日志与客户端网络抓包作为核心分析依据，进行科学诊断。
• 协同机制：当问题涉及特定 AC 设备的版本兼容性或私有特性时，应及时与设备厂商建立协同排查机制，共同进行深度分析。