VPN 上看不到网络共享？发现功能停了

输入路径时共享能打开，网络浏览窗口却什么都不显示。这种组合在隧道上很常见，通常并不是故障。发现是在问本地网段，可达性是在问某一台主机。有路由的隧道承载的是后者，而不是前者。

发现与可达性是两回事

浏览列表由向本地网段通告服务、并监听这些通告的协议产生。按名称打开共享，则是与单台主机建立直连。前者需要广播或多播域，后者需要一条路由和一个端口。

在隧道上，后者可以完全正常，而前者只返回一个空窗口。把空窗口当成故障，就会去找一条其实正在履职的坏隧道。

浏览列表为什么一直是空的

Windows 停用了 Computer Browser 服务并默认关闭 SMB 版本 1，旧「网上邻居」背后的机制因此消失。WS-Discovery、SSDP 和组播 DNS 之类的替代方案，面向的是只存在于本地链路上的广播或多播组。点对点隧道没有这样的链路，路由器默认也不转发这些组。每台主机都能访问，列表却仍可以是空的。

有些客户端会加上自己的发现助手。那个助手能用，是客户端的功能，不是隧道的属性。

用明确的名称，再确认能否访问

UNC 路径、映射驱动器，或用 Finder 连接 SMB 地址只要名称能解析、端口是开的，在隧道上就能用。解析可以来自 DNS，可以来自 VPN 下发的搜索后缀，也可以来自集中管理的 hosts 记录。在域里，目录查询能列出计算机对象，这份列表通常最接近有路由网络上的浏览视图。对已知前缀做端口扫描，只在自己运营、或明确获准测试的网络上才可接受。

能应答的主机并不保证共享会打开。NAS 可能有只允许自身子网的名单，会拒绝 VPN 地址池。文件服务器的防火墙规则也可能只写了本地子网。你为共享提供的账号，可能是那台服务器上从未创建过的本地账号，走 VPN 连上去也不会把它建出来。

有些企业客户端在隧道启用时，会刻意阻断本地和虚拟机的流量。这种连不上属于策略，改的是管理员，而不是客户端的路由表。

值得重复的诊断顺序

按层依次走：到达地址、解析名称、打开 445 端口、通过认证，最后读共享权限。每个答案都是独立的，跳着走只会得到一个很有自信的错误结论。等这些全都通过，再去查发现才有意义。

nslookup fileserver.example.com
nc -vz fileserver.example.com 445
smbclient -L //fileserver.example.com -U EXAMPLE/jdoe

留一份记录：服务器名、共享路径、解析到的地址，以及能用的账号。如果之后重启某个服务，浏览列表自己填上了，那就把当成发现的小脾气，而不是之前路由错的证据。正是这份记录，让下一个人能跳过那个空窗口。