在你的局域网中与所有设备共享一个 VPN 连接

一台笔记本电脑持有隧道，家里其他设备都想要同样的访问，而第一次尝试是把所有流量都指向那台联网的机器。它失败的原因与 VPN 毫无关系：接收方主机必须转发数据包、改写源地址，并确保回复能找到回去的路。三者缺一，联网的笔记本照常工作，而其他所有设备都会超时。解决办法是路由设计，而不是客户端设置。

为什么把设备指向主机行不通

一台收到发往远端网络数据包的主机会在那个瞬间变成路由器，无论有没有人把它配置成路由器。转发在 Linux 和 Windows 上默认是关闭的，除非某个功能把它打开。地址转换很关键，因为远端必须知道把回复发到哪里，而私有 LAN 地址对它毫无意义。回程路由是第三块，也是当第一个 ping 看起来成功时人们会忘掉的那一块。

按这个顺序排查，而不是随意开关设置。每一块缺失都会带来略有不同的症状。

在主机上启用转发和地址转换

对联网主机做两处改动就能覆盖前两块：启用 IPv4 转发，并把 LAN 流量转换到隧道接口上。

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

把 sysctl 值持久化到 /etc/sysctl.d 下的文件中，并在重启后重新检查 masquerade 规则，因为防火墙前端可能清空自定义链。在 Windows 上，共享功能会完成这两步，但它还会把 LAN 适配器重新分配到固定子网并清除其网关，这会破坏静态寻址和端口转发。在断定共享失败之前，先把路由器到主机新地址的路径恢复。然后观察第二台设备发送流量时规则计数器是否增长。

给局域网一条能在重启后存活的路径

其他设备需要一条通往远端前缀的路由，而提供这条路由的两种方式影响范围不同。

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

把客户端的默认网关指向主机，会让它的所有流量都经过主机，包括本地打印和文件共享，于是无关的事情会随主机休眠而停止。在路由器上添加一条通往远端前缀的特定路由则范围更窄：只有隧道后面的目的地才走那台联网的机器，局域网其余部分照常工作。上面的子网只是示例，请换成你自己的 LAN 和隧道网段。无论哪种做法，都要用第二台设备在隧道开启和关闭时各测一次。

在归咎于隧道之前先看 MTU

隧道会缩小可用数据包的大小，而第二台设备对此一无所知。大流量传输和 TLS 握手会卡住，而小请求却能成功。

ping -M do -s 1400 10.8.0.5

有回复说明该尺寸可以不分片地通过路径；超时则意味着封装开销把数据包推过了隧道的 MTU。降低共享接口上的 MTU，或在转发设备上钳制最大分段大小，然后重复同样的探测。先在 LAN 一侧测试同样的尺寸，因为本地失败指向的是局域网而不是隧道。记录可用的尺寸，因为之后更换提供商或隧道可能会让它变化。

对于一台额外设备，从主机共享就够了。对于一个家庭，把路由放在路由器上。当访问必须在笔记本随你离开后仍然存在时，隧道本身应该放在专用网关上。