Windows VPN 连上却没网？可疑的是地址池

Windows 把隧道显示为已连接，并打上无 Internet 访问的标签，人们常把这当成 Windows 的怪毛病。其实它是在说明客户端拿到了什么：没有可用的默认网关、没有能工作的解析器，或者隧道内的地址没有回程路径。当服务器是 Windows 的“传入连接”时，一个设置就能解释大多数这类报告。这个标签不是诊断，但把排查范围缩小到三处。

改之前先读租约

在客户端运行 ipconfig /all，在条目中找到 VPN 适配器。它列出的地址、默认网关和 DNS 服务器就是你需要的事实，而且往往与管理员以为的分发结果不同。

三种模式对应三类故障。地址落在 169.254.0.0/16，说明客户端什么都没拿到，自己配了链路本地地址。地址看似合理却没有网关，说明地址池下发时缺少让客户端获得默认路由的选项。租约完整却仍然到不了任何地方，则指向服务器侧的转发或地址转换。

动服务器之前先把这些值记下来。下一步要把它们与服务器自以为在分发的范围对比，而记忆是租约的糟糕替代品。

为什么自动分配可能不留下网关

“传入连接”条目有自己独立的 IPv4 属性，与物理适配器分开。那里的默认设置提供自动分配地址，依赖连接内置的分配器来提供地址、掩码、网关和 DNS。

在独立工作站上，除非机器上还有别的东西提供范围，否则这个分配器没有可用的范围，于是客户端可能只得到链路本地地址，或者有地址却没有网关。链路通了，连接看起来就建立了，但背后的配置并不完整。

这就是为什么改成指定范围能修好这么多报告。你不再要求一个可能根本没在运行的服务凭空发明租约，而是自己把租约写清楚。

同样的混乱出现在有人指望 LAN 路由器的 DHCP 服务器为隧道客户端服务时。广播发现不会穿过被路由的隧道，所以那台服务器根本看不到请求。反过来想，正是地址池替一个从未向它请求过任何东西的客户端背锅的最常见原因。

设置服务器可路由的明确范围

在服务器可达的子网里选一个小块，避开 LAN 路由器分发的范围，也避开网络上任何其他池。如果服务器在 172.20.10.0/24、路由器占着 172.20.10.1，那么在该子网上端附近取一小段，比如 172.20.10.201 到 172.20.10.209，就能让隧道租约避开路由器已经管理的分发范围。

把它填进“传入连接”的 IPv4 属性，重连客户端，并在改动其他东西之前再读一次适配器。第二次读取才能告诉你地址池是故障本身，还是只是若干故障之一。

以下命令会打印结果配置以及客户端现在拥有的路由：

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

租约里的网关应当是服务器自己持有的地址，客户端的默认路由应当指向它。如果租约完整却没有路由，说明服务器分配时没有推送网关，地址池设置仍然是该看的地方。

地址不是上网通路

拿到租约只是把数据包从客户端送到服务器。要访问互联网，服务器必须转发这些数据包并把它们转换到自己的上行链路，那是另一套配置，有它自己的失效模式。

Internet 连接共享是捷径。它把面向互联网的适配器变成共享网关，并运行自己的地址分配，这可能改写该适配器的地址，并让已有的 NAT 规则指向一个已不存在的值。启用之前先记录原始设置。

路由方案让地址分配保持稳定，并要求你显式配置转发和转换。两种做法都没有错；把两者半途混用，就会得到一个有租约却没有出口的隧道，而这正是你一开始的症状。选定一种模型，做完整之后再添加另一种。

先排除外部通路

如果隧道根本建立不起来，任何地址池都帮不上忙。协议决定通路必须承载什么：PPTP 需要 TCP 1723 和 GRE，GRE 是 IP 协议 47 而不是端口；L2TP/IPsec 需要 UDP 1701 以及 500 和 4500；SSTP 需要 TCP 443。

只转发端口却不转发协议的路由器，会造成一次永远无法通过认证的连接尝试。这与隧道建立之后到不了任何地方是两种不同的故障，不应放在一起排查。

分别从同一 LAN 和远程网络测试。如果 LAN 的尝试成功而远程的始终到不了认证，问题就在外部通路。如果两者都能认证，只有远程客户端没有网络，那就回到地址池和出口。