VPN 客户端模式下的路由器：局域网设备为何消失

认为客户端模式本身会切断局域网访问，会把人带进错误的设置菜单，而真正的原因通常有两个。隧道不会移除 LAN 网桥，也不会阻止有线和无线客户端互相访问。破坏本地访问的，要么是路由器转发路径中的检查功能，要么是固件改动时发生移动的 LAN 地址段。两者都会产生同样的抱怨，而且重装 VPN 配置文件一个都修不好。

误解，以及客户端模式真正改变了什么

客户端模式会添加一个隧道接口和一条经它出去的默认路由，然后把 LAN 流量转发进该隧道。有线端口与无线射频之间的网桥不变，本地交换也不变。改变的是策略：哪些流量被转发、在哪里做地址转换、客户端拿到哪个解析器。

这个区别很重要，因为局域网坏掉通常意味着那三条策略之一变了，而不是路由器不再当交换机。还能响应自己管理页面的路由器，证明 LAN 接口还活着。完全没有任何响应的路由器是另一个问题，比如 LAN 地址被改，或者客户端在错误的子网里。

所以有用的第一步是找出哪一层坏了，而不是去改你怀疑的那一层。

动设置之前先探测三个目标

从有线客户端分别探测三个目标并记下每个结果：路由器自己的 LAN 地址、同一交换机上另一台设备的 IP，以及只能经隧道到达的东西。按这个顺序做，因为每个结果排除的是不同层。第一轮用地址而不是名字，因为名字失败会把 DNS 混进连通性问题。

回答的模式就是诊断。本地设备不答而路由器答，指向本地交换或过滤功能，而不是路由。隧道一侧不答而本地设备答，指向隧道路由或远端防火墙。按地址全都通而名字失败，是解析器问题，改多少路由都没用。

把这张表放在测试结果旁边。它能把模糊的抱怨变成一行可执行的话。

转发路径里的安全层

消费级路由器越来越多地带有检查转发流量的功能，而它运行的正是承载 LAN 到隧道数据包的路径。当该检查无法对隧道流量分类时，转发可能卡住，而隧道本身仍然在线，路由器还报告连接健康。VPN 日志里什么都看不出来，因为 VPN 确实连上了。

诊断是一次受控实验，不是永久改动。记下当前设置，在一次测试期间关掉该功能，重新拉起隧道，再按地址探测一台本地主机。转发恢复就是你要的证据，这时取舍才变成决定而不是猜测。如果毫无变化，立刻重新启用，转而排查地址原因。

为了让隧道继续工作而让付费安全功能保持关闭，是需要刻意做出并记录下来的取舍。也值得问一句隧道是否该放在另一台设备上，因为必须检查一切的路由器和必须转发一切的路由器是两份不同的工作。

第二个原因：LAN 网段移动了

固件更新经常把 LAN 地址重置为厂商默认值，有些路由器还有明确的模式开关，决定 LAN 保留私有网段还是从上级设备继承一个。期待 192.168.8.x 的客户端可能落在 10.64.0.x 上，此时隧道完全健康，发往主机的 SSH 会话却超时了。

ipconfig /all
ip addr show
ip route get 192.168.8.20

打开路由器页面前，先从租约里读出前缀和网关。前两条命令显示客户端实际拿到了什么，第三条显示客户端去本地地址会走哪个接口，残留路由或过期子网就是这样暴露的。然后把它和 LAN 页面以及路由器当前模式对照。

如果网段回不去，就更新所有提到它的对象：DHCP 保留、任何指向旧子网的静态路由，以及每条带旧前缀的防火墙规则。与隧道远端子网冲突的网段是更糟的变体，因为本地设备还能访问，远端目标却被悄悄地错误路由进 LAN。

按数据包顺序重连并复测

做完任一改动后，重连隧道并按数据包顺序复测：路由器、本地主机、远端主机，然后名字，最后应用。先测应用会掩盖哪一层还坏着，而浏览器对缓存名字的重试看起来就像路由故障。

把固件版本、LAN 前缀和检查功能状态记在 VPN 配置文件旁边。三者都是下一次更新可能覆盖的配置，两行笔记能省下你刚花掉的一小时。