共享 Windows 连接？底下的 VPN 路径会变

共享的网卡让电脑变成路由器，转发的流量走的是与主机应用不同的路径。从客户端测试，而不是主机。

笔记本电脑共享自己的 Wi-Fi，主机通过隧道上网毫无怨言，而共享出来的平板却什么都访问不到。启用共享的那一刻，主机就不再只是客户端了：它成了路由器，转发的数据包会遇到另一套规则。主机上一切正常，并不能说明它背后的设备。从下游客户端做检查，这个区别就不再是理论问题。

主机的成功证明不了什么

连接共享把四项工作交给一台机器：分配地址、转发、转换和过滤。保护本地产生流量的 VPN 客户端可能把转发流量视为超出自己的范围，也可能把它当作泄露而有意拦截。这两种行为都不是缺陷，也都不会写在开启共享的那个界面上。只有下游测试才能告诉你属于哪一种。

许多客户端只转发主机的流量，别的什么都不做，所以要查客户端文档里关于共享的那一节，而不是指望隧道替平板转发。可见的症状是设备能关联、能拿到地址，却在第一个请求上失败。拒绝转发的客户端在主机上看起来依然完全正常。

哪个网卡被共享，哪个为客户端服务

两块网卡都要记录，因为它们承载不同的地址和不同的过滤规则，改错一块会解释很多令人困惑的结果。共享主机通常在下游一侧占用固定地址，并在那里运行一个小型 DHCP 和 DNS 服务。Windows 按网卡而不是全局维护转发状态，所以必须逐个接口去读。

Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceIndex,LinkSpeed
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias,IPAddress,PrefixLength
Get-NetIPInterface | Select-Object InterfaceAlias,Forwarding,ConnectionState
Get-NetConnectionProfile

如果共享网卡上的转发显示为已禁用，那么无论隧道做什么，下游都不会工作。只有在策略允许它替其它设备路由的机器上才启用。

转发、转换和过滤

转发的数据包必须到达隧道，被转换成远端能接受的形式，再经过同一次转换返回。这三个阶段中任何一个都可能断掉，而每次断裂都会产生同样的浏览器超时。抓包、查路由，以及来自远端的日志，比再看一遍共享对话框更有价值。哪个阶段失败，才说明需要谁去改。

远端可能还需要一条回到共享子网的路由，那是 VPN 服务器从未见过的网段。客户端做转换时，服务器只看到隧道地址，不需要回程路由。不做转换时，拥有网关的人必须有意添加那条路由，那是变更请求，而不是客户端设置。

在客户端上检查，而不是在主机上

每项检查都在出问题的客户端上做，而不是在正常的主机上做。把出口地址、解析器应答和应用测试放在同一次会话里，因为间隔一小时收集的结果说明不了三者如何组合。

Resolve-DnsName intranet.example.net -Type A
Resolve-DnsName intranet.example.net -Type AAAA
Invoke-RestMethod https://api.ipify.org
Test-NetConnection intranet.example.net -Port 443 -InformationLevel Detailed

把出口地址与主机自己的地址作比较，并记下两者是否一致。答案不同意味着转发的路径绕开了隧道，这是有责任方的策略问题，而不是快速修复。答案一致而应用失败，则把工作转向名称解析或远端的策略。也不要停在 IPv4 结果上：共享可能通过每一项 IPv4 检查，而 IPv6 却从另一个出口离开，所以要用 AAAA 记录和详细连接测试重做名称与出口检查。

在受管机器上，先确认共享本身是否被允许，因为把访问暴露给另一台设备是管理决定，而不是便利开关。任何受支持的变更之后，都要在重连时和故障期间重复检查。主机干净地重连，并不能恢复客户端从未支持过的转发路由。

相关文章