RRAS DHCP：新地址还是仅配置选项？

把抓包中的 DHCPACK 当作 VPN 客户端从 DHCP 取得地址的证据，是一种误判。通常它只能证明某条 DHCP 报文得到了应答。Windows RRAS 可以从自身的静态地址池下发会话地址，而 DHCP 仍在向已连接的客户端提供选项。请求类型才是判断这两种工作哪一种正在发生的依据。

共用同一种报文类型的两件事

DHCP 做两件彼此独立的事，而它们共用报文类型。一件是分配地址和租期。另一件是向已有地址的主机下发配置，RFC 2131 把它称作 DHCPINFORM。后一种情况的应答携带选项，却不携带任何租期。

所以 ACK 证明的是有应答，而不是有分配。真正决定问的是哪个问题的，是它前面那条报文。先读请求行，剩下的抓包内容通常会不言自明。

RRAS 从哪里取得地址

RRAS 通过自身配置的 IPv4 分配方式来掌控 VPN 地址的决定：要么是 DHCP 服务器，要么是静态地址池。当地址池是静态的时候，分配者就是地址池，另一台 DHCP 服务器上的保留项在那次会话中没有发言权。两套机制可以在同一网络中并存，谁都不控制对方。

Get-Command -Module RemoteAccess *IPAddress*

排查地址之前先确认当前生效的分配方式。如果是静态地址池，DHCP 作用域就是看错了地方。上面的命令会列出你所运行版本中可用的 cmdlet，找到那个设置已经够了。

用户类能证明什么，又不能证明什么

DHCP 用户类只是客户端发送的一个字符串，不是经过认证的组成员身份。即便客户端发送了某个类，服务端也据此匹配了策略，这个标签也只能证明字符串到达了。RFC 3004 明确说明，该选项并不认证对类的资格。

不要指望 VPN 用户名、安全组标识符或笔记本的 Ethernet 地址会以可用的形式出现在那条请求里。这些属于认证与目录的事实，而 DHCP 请求两者都不携带。如果需求是区分获授权的人，就该在身份真正存在的 VPN 策略里落实。正是这种分离，让两套系统保持各自独立。

比较证据，而不是比较 ACK

与其只读一个数据包，不如把证据链搭起来。记录会话拿到了哪个地址、请求的报文类型与字段、服务端返回的选项，以及随后客户端的实际配置。每一环回答的都是不同的问题，而缺失的那一环往往正是真正故障所在。

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

如果地址来自 RRAS 地址池，DHCP 保留项什么也解释不了。如果选项到达了但客户端忽略了它们，说明服务端已尽责，下一站就是客户端配置。把这两种结果明确对比，ACK 就不再含糊。两份抓包，分配方式各一份，比任何文档都更快地结束争论。