把 Windows VPN 共享给有线主机：PC 网关还是路由器

位于 Windows PC 之后的主机需要下游网段、地址分配、地址转换和愿意转发的客户端。把它和一台自己持有隧道的路由器做个比较。

无法运行 VPN 客户端的游戏主机，有时可以借用 Windows PC 的隧道，而这种安排失败的次数多于成功，原因大多与 VPN 无关。PC 必须变成网关：一个独立的下行接口、给主机分配地址、地址转换，以及一个愿意转发其他设备数据包的客户端。一条只对 PC 自身应用有效的隧道，不能证明以上任何一点。

真正值得做的比较，是这种安排与一台为整个网络持有隧道的路由器之间的比较。两者在维护方式、故障时的表现，以及一次能看到多少策略上都不相同。

PC 网关必须做什么

网关需要一个朝向主机的接口、该网段的地址范围，以及一条把主机流量改写到隧道上的转换规则。它还需要客户端转发并非由自己产生的数据包，这与接受自身流量是不同的设置。名称解析必须走同一条路径，否则主机会通过一条路径解析游戏服务，再从另一条路径连接。以上每一项都是独立的配置步骤，各自有各自的失效方式。

console -> dedicated ethernet -> windows sharing / nat
        -> selected tunnel interface -> internet

Windows 的 Internet 连接共享正好提供这种形态：一个连接被指定为公用，另一个被指定为专用。这个指定比人们预想的更重要，因为通向家庭路由器的接口，并不自动就是承载隧道的那个接口。

起决定作用的比较

三个差异把 PC 网关与路由器网关区分开来，而且正是那些几个月后才显现的差异。表格把它们并排列出。

AspectWindows PC gatewayRouter gateway
Tied to a user sessionYes; sleep or sign-out ends itNo
Policy visibilitySplit across client and sharing layerOne ruleset
Address servicePrivate side of the sharing featureRouter scope
Recovery after rebootManual, per sessionAutomatic

与用户会话的绑定是第一个差异，也是最让人意外的那个。PC 睡眠、注销或安装更新后就不再是网关，主机随之失去路径，而任何配置都没有改变。策略可见性是第二个，因为客户端的规则与共享层位于两个地方，谁也不描述对方。地址服务是第三个，它解释了一台持有地址却仍然什么都访问不到的主机。

这些都不说明 PC 方案是错的。它只是让这套方案成为临时设计，而当需求本身是临时的时候，这是可以接受的。

被转发的流量是另一个类别

桌面客户端对为其他设备转发的数据包，可能与对自己的数据包处理方式不同。按应用划分的包含列表只覆盖 PC 上的进程，对主机的流量只字不提；而保护本地应用的终止开关，可能根本不保护被转发的路径。请确认客户端对转发流量的书面行为，而不是从 PC 上一次成功的网页加载推断。当这一行为不明确时，整个安排就建立在假设之上。

主机的地址应当来自共享安排，绝不能把 PC 的隧道地址复制过去。复制会产生重复地址、错误的网关，以及指向主机无法到达之处的解析器。让下游服务来分发配置，然后检查主机实际收到了什么。

检查主机的流量，而不是 PC 的

唯一有意义的测试是观察主机的路径。在 PC 上，下面的命令会显示接口布局、下游链路上的邻居表，以及主机是否在服务端口上应答。请在游戏会话真正连接时运行它们。

Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4Address
Get-NetAdapter | Select-Object Name, Status, LinkSpeed
arp -a | findstr 192.168.137.
Test-NetConnection 192.168.137.10 -Port 3074

下游一侧没有地址的接口，意味着共享从未启动，这与主机连不上是不同的问题。邻居表里出现主机条目，说明链路和地址分配是活的。此后端口测试失败，说明问题在转发、或客户端对转发流量的处理方式，而不在网线。在断定隧道就是正在使用的路径之前，先把主机的出口地址与 PC 的地址做对比。

把这套安排连同接口名和地址范围一起记录下来。当下一次更新后它出问题时，那一页能省下一小时的重新摸索。

相关文章