Wi-Fi 客户端隔离与 VPN 本地访问：到底是什么挡住了你

把两部手机放在同一个访客 SSID 上，彼此都看不见对方，但两台都能上网。在其中一台上加一个 VPN 客户端，三米外的打印机依然不可见，而另一个大陆的服务器却能回应 ping。隧道里没有任何故障；这里涉及两个独立的访问决策，只有一个与路由有关。接入点决定无线客户端能否互相通话，VPN 客户端决定哪些目的地从隧道出去。把这两件事混为一谈，就会带来几个小时的无效配置改动。

两道闸门彼此独立

客户端隔离是交换层面的决策。接入点从已关联的某个站点收到帧，查看目的地址，发现目的地址是同一网桥上的另一个站点，于是把它丢弃。站点的 IP 地址与这个决策无关，VPN 也一样。

路由是另一个决策，在客户端上做出。VPN 的路由表决定发往 192.168.1.50 的数据包是进入隧道，还是从 Wi-Fi 接口出去。如果数据包从 Wi-Fi 出去，而接入点又隔离了客户端，它就会在接入点处消失。如果数据包进入隧道，接入点永远看不到原始目的地，也就无从隔离。

在典型的接入点上，隔离会挡住什么

厂商给这个功能起了好几个名字：客户端隔离、AP 隔离、站点隔离，或者一个默认就隐含它的访客网络。在 OpenWrt 中，按接口生效的选项是无线配置里的 isolate，无线文档里有说明；访客 SSID 通常还会拿到自己的网桥和防火墙区域。结果是客户端之间的单播帧不再被桥接，所以发往邻居的 ping、SMB 连接或打印任务都会失败，即便两台设备都显示满格信号。

发现类协议最先受影响，也最明显。打印机和媒体设备的 mDNS 以组播发往 224.0.0.251，SSDP 使用 239.255.255.250，而这些帧能否过桥取决于厂商，也取决于是否开启了组播转单播。设备从列表里消失，比直接连一个已知地址失败要更弱的证据。

VPN 改变了什么，又改不了什么

全隧道接管默认路由，因此只有客户端为本地子网保留更具体的路由时，才够得着它们。分隧道则相反，按设计保留本地访问。这两个设置都无法让一台正在隔离的接入点在它的两个客户端之间转发帧，所以在 VPN 客户端里放行本地流量是必要的，但并不充分。

反过来的情形同样常见。接入点允许客户端互访，VPN 客户端把本地子网排除在隧道之外，打印机仍然不应答，因为主机防火墙把 Wi-Fi 网络当成公共网络。三层、三个不同的默认值，而在大多数 VPN 日志里只看得到路由。

判断是哪一道闸门关着

先做一个把 VPN 排除在外的测试：把两台普通设备连到同一个 SSID，用地址从一台访问另一台。如果失败，就是接入点在隔离，任何 VPN 设置都修不好。如果成功，再回到客户端，在 Linux 上运行 ip route get 192.168.1.50，或在 Windows 上运行 Find-NetRoute -RemoteIPAddress 192.168.1.50；输出会指出数据包将使用的接口。

当路由指向 Wi-Fi 接口时，数据包明文出去，问题就变成接入点和主机防火墙是否放行。当路由指向隧道时，目的地被送去 VPN 服务器，这对同一局域网内的设备是错的，通常意味着隧道的允许列表开得太宽。

直接连打印机的端口，比看发现列表是更好的测试。Linux 上的 nc -vz 192.168.1.50 9100，或 PowerShell 里的 Test-NetConnection 192.168.1.50 -Port 9100，会在任何应用层配对进入讨论之前，告诉你这个地址到底通不通。

按你所在的网络选对策

在酒店或访客网络上，隔离是刻意为之，不该去破它。把本地设备当作不可达，用 VPN 去连一台能打印或共享的主机，别再把这个 SSID 当局域网。

在家里，设备都是自己的，在主 SSID 上关掉隔离是合理的，访客 SSID 继续保持隔离。这个设置住在接入点的无线配置里，就该在那里，而不是每个客户端上的防火墙例外。

在办公室里，要假定接入点、VLAN 和主机防火墙都是有意的。带着测试结果去上报，而不是要求关掉隔离，因为把客户端隔开的网络通常在保护着什么。

验证应用，而不只是 ping

ping 通只证明路径，不证明服务。打印机常常接受裸 9100 或 631 上的 IPP，却拒绝被发现；文件共享则需要 445，还要能正常解析名称。确认应用实际用的端口，再到设备上重试真正的任务。

在笔记里把两层分开记：Wi-Fi 网络允许什么，VPN 又路由什么。下次某台设备从列表里消失时，这个区分会告诉你先看哪里。