GVC 卡在 Acquiring IP：这不是密码问题

认证可能已经完成，而虚拟网卡仍然没有地址。请沿租约路径排查，而不是反复更改无关的客户端设置。

Global VPN Client 停在 Acquiring IP，第一反应往往是重输密码或重装客户端。这两件事都没有触及真正失败的阶段。认证在客户端还没请求地址之前就已经完成，所以把你卡在这一行的并不是凭据。真正卡住你的是一个尚未完成的 DHCP 交换，它可能在三个不同环节停滞。

认证与地址分配是两个独立阶段

GVC 先证明你是谁，然后按照分配给该连接的策略为虚拟网卡请求设置。这些步骤前后相连，失败特征却各不相同。凭据错误通常更早失败，给出的是认证或协商消息，而不是地址这一行。

这个顺序解释了为什么重设密码、新建本地用户或重装在这里毫无作用。客户端已经通过授权，现在它在等待网关或其 DHCP 伙伴提供租约。即使策略允许该用户却不分配任何地址范围，也会产生完全相同的画面。

因此第一个有用的问题不是凭据是否正确，而是分配了哪条策略，以及该策略对虚拟网卡寻址是怎么规定的。请阅读该连接的实际配置，而不是同事那张能用的截图。

租约究竟从哪里来

常见的有两种模式。防火墙可以自己为 VPN 客户端运行 DHCP 作用域，也可以把请求转发给内网中的外部 DHCP 服务器。模式决定了哪些日志重要、该找谁处理。

在内部模式下，检查作用域是否仍然存在、是否属于正确的接口、是否还有空闲租约。作用域耗尽时，客户端会完美通过认证却永远拿不到地址，而网关日志可能只记录请求。在转发模式下，转发目标、回指 VPN 客户端网段的路由以及任何内部 DHCP 授权都必须对齐。

在测试任何东西之前，先写下你的部署属于哪种模式。网上互相矛盾的建议有一半默认的是另一种。

隧道已建立，租约仍可能丢失

控制连接建立只证明协商成功，并不证明隧道数据双向通行。DHCP 交换需要请求和应答穿过数据路径，而加密设置、VPN 区域策略和 MTU 问题恰恰都在这里。

关于 NAT 穿透的建议最能说明上下文的重要性。有些路径需要开启它，另一些只有关闭时才正常，中间的 NAT 与协商后的连接共同决定属于哪种。在改动客户端设置的同时盲目改它，意味着你无法判断究竟是哪项改动带来了结果。在更改封装之前，先记录协商路径与证据。

重启家用路由器属于同一类做法。它有时能让症状消失，却没有查明租约为何失败，下一次连接时问题就会回来。

按顺序走一遍租约路径

从网卡开始向外排查，让每一步只可能因一个原因失败：

> Get-NetAdapter | Where-Object Name -like "*GVC*"
> ipconfig /all | findstr /i /c:"GVC" /c:"IPv4" /c:"DHCP"
> Test-NetConnection 10.60.0.1 -Port 443

像169.254.x.x这样的地址，说明网卡存在但完全没有收到应答，指向租约来源或数据路径。地址在 VPN 网段内正确但 DNS 条目错误，是另一种故障：租约成功，策略却下发了不完整的设置。网卡始终不出现，则说明客户端还没走到创建它这一步。

一旦出现租约，就去访问真实资源，而不是在地址这一行宣布胜利。如果文件或内网访问仍然失败，请把成功的租约留作证据，转而排查名称解析或策略，因为此时原始故障已经被抛在身后。

SonicWall 关于虚拟网卡的说明列出了若干独立分支，其中的旧截图不应被当作当前菜单地图。用它确认你已经走到哪个阶段，而不是当作可以整体照搬的检查清单。

相关文章