记一次 NAC 802.1X 认证后终端无法获取 IP 的排查记录

Tue, 15 Sep 2026 07:00:00 +0800

问题背景

公司办公网在 2025 年底完成了 NAC（Network Access Control）全覆盖，所有有线端口和无线 AP 均启用 802.1X 认证，认证服务器为 FreeRADIUS + Microsoft NPS，终端通过 EAP-TLS 证书或 PEAP-MSCHAPv2 两种方式接入。认证通过后，RADIUS 会下发 VLAN 属性（Tunnel-Private-Group-ID）把终端分配到对应的业务 VLAN（10/20/30），再由各 VLAN 的 DHCP Server 分配 IP。

9 月 14 日下午，运维在测试一批新采购的 Windows 11 24H2 笔记本时发现：认证日志显示 EAP Success，但终端始终拿不到 IP，ipconfig 显示「媒体已断开」或「无法获取 IP 配置」。已知同 VLAN 的老设备均正常，新设备仅在插有线时复现，无线 802.1X 正常。

故障现象

终端插网线后，交换机端口 LED 常亮，show authentication sessions interface 显示 Status: Authorized，Username 和 MAC 均正确。
show dot1x interface 显示 PortControl=Auto，AuthSM=2（Authenticated）。
但终端 ipconfig /renew 一直超时，抓包只看到 DHCP Discover 没有 Offer。
同一端口换一台已认证过的 Win10 笔记本，立即拿到 IP，说明端口本身没问题。
事件查看器 Microsoft-Windows-NetworkProfile/Operational 有大量 NLA 检测失败 事件，提示「网络无 Internet 访问」。
交换机日志无 STP 变化、无端口安全违规，RADIUS accounting 记录完整（Start/Interim/Update/Stop 都有）。

排查过程

第一步：确认认证确实成功

在核心交换机上执行：

`1`	`show authentication sessions interface GigabitEthernet1/0/23 details`

输出显示：

Interface:  GigabitEthernet1/0/23
MAC Address:  00:50:56:xx:xx:xx
Status:       Authorized
Domain:       DATA
Oper VLAN:    20

RADIUS 返回的 VLAN 20 正确，说明认证链路没问题。

第二步：抓包定位 DHCP 阶段

在终端用 Wireshark 抓包，只看到：

`1`	`DHCP Discover (Broadcast) → 交换机`

之后再无任何 DHCP 报文。说明 DHCP Discover 根本没有被转发到 DHCP Server，或者 Server 收到了但没回 Offer。

第三步：检查 DHCP Snooping 与 IP Source Guard

NAC 环境下通常会同时开启 DHCP Snooping + IP Source Guard + Dynamic ARP Inspection（DAI）。认证成功后，端口从 UNAUTHORIZED 变为 AUTHORIZED，但 DHCP Snooping 的绑定表可能没有及时刷新。

执行：

`1`	`show ip dhcp snooping binding \| include 00:50:56`

发现该 MAC 在 VLAN 20 没有任何绑定记录。

而老设备有：

`1`	`00:50:56:aa:bb:cc 192.168.20.45 Vlan20 Gi1/0/15`

根因初步锁定：新终端认证通过后，DHCP Snooping 绑定表没有自动添加，导致后续所有 DHCP 报文被 DAI 或 IP Source Guard 静默丢弃。

第四步：验证 RADIUS VLAN 下发与 DHCP 作用域

进一步检查 RADIUS 配置，发现 NPS 策略里对「Windows 11 24H2」这个设备类型返回的 VLAN 属性是 20，但 DHCP Server 上 VLAN 20 的作用域只允许 192.168.20.50-192.168.20.200，且该作用域的「授权 DHCP 服务器」列表里没有这台新终端的 MAC。

更关键的是：NAC 认证通过后，交换机端口进入 VLAN 20，但 DHCP Snooping 的「untrusted」端口在认证状态变化时不会自动触发重新绑定。

解决方案

在 FreeRADIUS / NPS 中增加 Class 属性，让 RADIUS 在认证成功时同时下发 Class 属性，交换机据此触发 DHCP Snooping 绑定刷新（Cisco ip dhcp snooping verify no-relay + authentication event server alive action reinitialize）。

修改 DHCP Snooping 配置，允许认证后端口自动刷新绑定：

ip dhcp snooping
ip dhcp snooping vlan 10,20,30
ip dhcp snooping information option allow-untrusted
interface range Gi1/0/1 - 48
  ip dhcp snooping limit rate 10
  authentication port-control auto
  dot1x pae authenticator

在 NPS 网络策略中增加「Windows 11」条件，返回 VLAN 20 + Class=Employee-Laptop，确保新设备也能触发正确绑定。

终端侧临时 workaround（已验证有效）：

1
2
3

netsh interface set interface "以太网" admin=disable
netsh interface set interface "以太网" admin=enable
ipconfig /renew

这会强制重新触发 DHCP 发现，绕过绑定表问题。

根因分析

根本原因：802.1X 认证成功后，交换机端口从 UNAUTHORIZED 切换到 AUTHORIZED 状态时，DHCP Snooping 绑定表没有同步刷新。新终端的 MAC 在 VLAN 20 没有合法绑定记录，后续所有 DHCP 请求被 IP Source Guard 作为「非法报文」丢弃。

次要原因：NPS 策略里没有针对 Windows 11 24H2 的差异化处理，导致新设备虽然能过 802.1X，但 DHCP 阶段卡死。历史设备因为之前手动加过绑定或用过不同 VLAN，所以没暴露问题。

预防措施

建立 NAC 变更 Checklist：任何新终端类型（Win11 24H2、macOS 新版、Linux 新发行版）上线前，必须在测试 VLAN 跑完整「认证→DHCP→访问」三段测试。
监控 DHCP Snooping 绑定表：Zabbix 定时采集 show ip dhcp snooping binding 数量，突降或某 VLAN 绑定数为 0 立即告警。
RADIUS 日志与 DHCP 日志关联分析：把 FreeRADIUS 的 detail 日志和 DHCP Server 的 dhcpd.log 做 syslog 聚合，设置规则「EAP Success 后 30 秒内无 DHCP Offer」触发告警。
定期做 NAC 演练：每季度模拟「新设备入网」场景，覆盖 Win11、macOS、Linux、IoT 四类终端，避免只测老设备。

总结

这次故障本质是「认证成功 ≠ 网络可用」。802.1X 只解决了「是谁」的问题，但 DHCP、VLAN、Snooping 绑定这些「怎么给 IP」的问题同样关键。NAC 项目上线后，必须把「认证后连通性」作为独立验收项，而不是默认认为「过认证就行」。

网络准入 on Zero Day Notes