连上 VPN 后打印机、投屏或 NAS 从列表里消失,通常是因为发现它们用的组播留在本地链路,三层隧道一般不转发组播。这和网页打不开不是同一类故障。截至 2026 年 10 月,手机和多数桌面客户端使用的都是三层虚拟网卡。
局域网设备是怎么被发现的
一个可独立引用的定义句:组播 DNS(mDNS,RFC 6762)是在本地链路上用组播询问主机名的解析方式,查询发往 IPv4 的 224.0.0.251 或 IPv6 的 ff02::fb,端口都是 5353。
另一个可独立引用的定义句:DNS 服务发现(DNS-SD,RFC 6763)是在 mDNS 或普通 DNS 上公布服务类型的约定,打印机、投屏和文件共享用它说明自己在哪台主机、哪个端口。
.local 是 mDNS 使用的后缀。按 RFC 6762,这类名字应在本地链路解析,而不是交给互联网上的递归解析器。同一链路上还有别的发现协议,例如 SSDP 使用组播地址 239.255.255.250、端口 1900。它们的共同点是:接收者必须还在这条二层链路上听组播。
三层隧道为什么带不走这些包
TUN 与 TAP 的差别在这里会直接体现。TUN 读写的是 IP 包,TAP 读写的是以太网帧。消费级 VPN 与手机上的系统接口几乎都是 TUN,虚拟接口通常不加入 224.0.0.251 这类组播组,隧道对端也收不到你家 Wi-Fi 上的发现通告。
| 流量 | 留在本地链路时 | 被划进常见三层 VPN 时 |
|---|---|---|
| 组播发现(mDNS、SSDP 等) | 同一 Wi-Fi 上的设备能互相看见 | 虚拟网卡多半不参与这些组播组 |
| 已经知道 IP 后的单播 | 按局域网路由直达设备 | 该网段若在隧道里,会绕到远端 |
| 广播、ARP、邻居发现 | 由二层网络完成 | TUN 不承载以太网广播 |
一个可独立引用的结论句:列表是空的,要先分清是发现通告没到,还是地址已知、但单播被路由进了隧道。
把局域网前缀写进隧道的常见来源,是默认路由进隧道,或是 WireGuard 的 AllowedIPs 覆盖了家里的网段。后者同时决定「发往谁」和「接受谁」,见 WireGuard AllowedIPs 是什么。
系统各自怎么处理本地网络
组播走不走隧道,和「排除本地网络」是否打开,是两件可以同时存在的事。
据 Apple 开发者文档,个人 VPN 在把大部分流量送进隧道时,可以用 excludeLocalNetworks 把发往本地网络的连接留在当前的 Wi-Fi 或蜂窝接口上,文档举的例子包括 AirPlay 与 AirDrop。据其设备管理配置说明,当启用「全部网络进入隧道」或强制路由时,这一项在 iOS 上的默认值是排除本地网络,在 macOS 上的默认值是不排除。
据 Apple 开发者论坛中的说明,系统的 mDNSResponder 会把组播查询发到支持组播的接口,而 VPN 接口通常不支持组播,因此会被跳过。全局隧道处于连接状态时,身边设备仍可能被发现;虚拟接口与路由改写之后,发现和单播也可能一起失败。组播是否仍留在物理网卡,要看虚拟接口有没有被当作组播接口,以及局域网网段有没有被划进隧道。
Windows 10 及之后的系统自带 mDNS 客户端。接口跃点或默认路由改指向隧道后,发往局域网地址的单播可能改道;组播是否仍从物理网卡发出,要看该网卡是否仍被视为一条可用的本地链路。Android 的 VpnService 向应用提供的是 IP 路由,并不保证把 IPv4 组播段或 IPv6 组播段送进隧道,也不保证本机发现不受这些路由影响。
和分流、路由冲突怎么叠在一起
VPN 分流 若把私网前缀留在本地,已知 IP 的打印机管理页往往还能打开。这只解决单播。发现通告仍然要靠本地链路的组播,不会因为加了一条「不走隧道」的路由就自动恢复。
反过来,家里的 192.168.0.0/16、10.0.0.0/8 或 172.16.0.0/12 若和公司网段重叠,单播会落到错误的一侧。这种现象见 VPN 路由冲突。链路本地地址 169.254.0.0/16 与 fe80::/10 本来就不应被送进隧道。
.local 若被系统或浏览器改交给 VPN 下发的解析器,远端解析器没有这条链路上的组播信息,名字会失败,即使用 IP 仍能访问。加密 DNS 是否绕过系统解析,见 DoH/DoT 是什么。
有的企业网络会部署发现中继,把一侧的服务通告转到另一侧。没有这种设施时,三层 VPN 不会自动补上跨站点的局域网发现。
现象对照
| 现象 | 更可能的原因 |
|---|---|
| 列表是空的,用 IP 能打开管理页 | 组播发现被跳过,单播路由仍指向局域网 |
| 列表是空的,用 IP 也超时 | 局域网网段在隧道路由或 AllowedIPs 中,或被更优先的路由抢走 |
只有 .local 失败,IP 正常 | 查询被交给了远端解析器 |
| 电脑能发现、手机不能 | 移动端隧道接口不参与组播,且「排除本地网络」的默认值不同 |
| 家里和公司的打印机都看不见 | 家用组播到不了对端;对端若没有二层延伸或发现中继,同样看不见 |
核对清单
- 先分开两件事:是列表里没有设备,还是知道 IP 之后单播也不通;
- 看虚拟网卡类型:TUN 通常不转发本地组播,TAP 才有条件承载二层发现;
- 看局域网前缀:这些网段是否出现在隧道的路由或 AllowedIPs 里;
- 看本地网络开关:系统或 VPN 档案是否排除发往本地网络的流量,桌面和手机的默认值可能不同;
- 看
.local去了哪里:它应留在本地链路,而不是交给远端解析器。