Windows VPN 显示 255.255.255.255：子网掩码错了吗？

在点对点隧道上，主机掩码是正常的。先确认接口类型，再查失败主机的路由，最后把 DNS 与服务访问分开排查。

隧道连上了，你打开适配器详细信息，看到掩码是 255.255.255.255。与办公网 255.255.255.0 一对比，很多人立刻认定出问题了。点对点链路上的主机掩码其实是对本地端点的正确描述，远端网段是通过路由下发的，而不是作为直连子网出现。下面的排查步骤把两个问题分开，避免为了一个显示值去重建本来正常的 DHCP 作用域。

点对点链路不是以太网段

以太网接口需要子网掩码，是因为该网段内每个地址都可能在同一根线缆上直接可达。PPP 类隧道另一端只有一个对端，没有广播域，没有 ARP，本地地址也不需要描述一个网段。

这类模型的地址协商定义在 RFC 1332 中，说明了两端如何就各自的地址达成一致。它并不会把办公网作为直连网络交给客户端。客户端是通过在链路上安装路由来知道办公网在哪里的，真正决定可达性的是这些路由。

这并不是说所有看到的掩码都正确。配置错误的客户端同样可能产生奇怪的地址。问题要更具体：这类适配器上的主机掩码是预期行为，因此它本身不能作为故障证据。

第 1 步：确认接口类型

先看适配器是什么，再判断它显示什么。描述字符串能确定驱动，而分配地址的前缀长度能确认客户端协商到的结果：

Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetIPAddress -InterfaceAlias 'Corp VPN' | Select-Object IPAddress,PrefixLength,PrefixOrigin
Get-NetIPInterface -InterfaceAlias 'Corp VPN' | Select-Object AddressFamily,ConnectionState,NlMtu

真正能终结争论的是第三条命令。最大传输单元偏低是封装链路的特征，而接近以太网的数值 则指向另一种虚拟适配器模型。如果描述里是 PPP 或 RAS 驱动，且前缀为 32，那你看到的正是上面描述的设计，可以不用再纠结掩码。

ObservationWhat it meansReasonable next step
/32 on a PPP or RAS adapterPoint-to-point endpoint addressingLook at routes, not the mask
/32 on an Ethernet-like adapterClient chose host addressing deliberatelyConfirm against the server's push policy
Mask differs from the office LANUsually irrelevant to reachabilityTest the destination instead

第 2 步：查看失败目的地的路由

可达性按目的地判定，单个已连接接口说明不了问题。直接向路由表查询用户真正要访问的地址：

Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4

Find-NetRoute 给的是直接答案：它会给出系统为该目的地使用的接口和源地址。如果返回的是隧道，那么去往该主机的流量就是走隧道的，掩码从来不是问题。

如果返回的是物理适配器，就比较两条候选路由及其度量值。更具体的本地路由、其他客户端残留的条目，或者物理路径上更低的度量值，都会压过一条宽泛的隧道路由。表现出来的现象是其他都正常、只有一个资源不通。前缀更长者总是优先，所以胜出的往往是几个月前有人加过又忘掉的一条主机路由。

顺手把两个方向都查一遍。到服务器方向的路由是必要条件而非充分条件，因为回程也必须走隧道。当一台内网主机通、另一台不通时，差异通常在这张表里，而不是适配器配置。

第 3 步：把名称解析与服务访问分开

打不开共享的应用可能卡在两个完全不同的阶段。先解析名字，再访问地址。如果前者失败而后者成功，说明隧道没问题，是解析器的问题：

Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

地址测试成功、名称测试失败，就能把问题定位到解析环节，而第二条命令可以看出隧道接口到底有没有拿到服务器。很多客户端会随隧道下发 DNS，如果配置文件忽略这些下发的选项，机器就会继续使用看不到私有区域的解析器。

不要把能通的地址当成永久修复。按地址访问绕过了名称解析，还可能让应用原本应做的服务器身份校验失效，这是伪装成临时方案的安全退化。用它来定位故障，然后去修解析。

回滚：不要为了一个显示值重建 DHCP

如果你已经开始改地址服务，先停下来确认改动的部分是否承重。重建作用域、重新发放租约或移动地址池都会改变其他客户端依赖的状态，而点对点适配器上的主机掩码并不能为这些操作提供理由。

Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445

在每次有针对性的改动后执行这三条命令，并与上一次结果对比。有用的结果是通往资源的可记录路径，而不是一个掩码看起来像办公网的适配器。

然后把这个掩码到底意味着什么写下来，因为下一个人打开同一个对话框时还会得出同样的错误结论。在配置说明里加一句：隧道是点对点的，远端子网以路由形式下发。下次就能省掉整套排查。

相关文章