VPN 主机名不通而 IP 可用：该从哪里查

用地址能打开共享，同一个共享用名字却失败，这说明隧道在传包，而名字这一层没有。仅凭这一点就能省去在防火墙和路由上绕一圈的工夫。名字需要后缀、解析器和查询路径，而 VPN 客户端可以只装路由、这三样一样都不装。按顺序做完下面四项检查，在第一项失败处停下。

名字问的是地址不问的问题

地址是协议栈可以立刻使用的目的地。短名字则是一个问题：必须先按后缀展开，再发给解析器，并由认识该区域的东西回答。只装路由而不装解析器的隧道，会让前者可用、后者失效。这就是为什么在不同的 VPN 产品上，症状看起来如此一致。

从地址往外查：先试完整名字，再试裸主机名，并记下三者中哪个可用。这个规律会告诉你，在打开任何一个配置界面之前该看哪一层。FQDN 明明能解析却去猜路由，是白费力气。

读一读隧道实际安装的解析器

问操作系统哪个解析器在处理内部区域的查询，而不是看 VPN 客户端界面在宣传哪个。推送了公共解析器却不带内部区域的服务器，产生的正是这种失败，它属于配置错误，而不是路由故障。

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

在加入域的 Windows 客户端上，命名空间路由策略决定哪些查询走哪个解析器，而 VPN 适配器自己的 DNS 设置会出现在适配器详细信息里。要读生效的策略而不是配置文件，因为缓存的策略可能比安装它的那次连接活得更久。如果解析器能回答完整名字却答不上短名字，问题就已经转移到后缀列表了。

Get-DnsClientNrptPolicy
ipconfig /all

如果内部区域能通过正确的服务器解析，就到此为止。解析器不是你的问题。

后缀解释了为什么短名字会失败

单标签名字在发出查询之前，会按连接的后缀列表展开。如果 VPN 不下发内部后缀，fileserver 就永远不会变成 fileserver.corp.example，查询会以一个公共解析器都不认识的名字发出去。推入后缀，或者直接输入完整名字，都能在不改动服务器的前提下验证这个假设。

nslookup fileserver.corp.example
ping -a 192.168.50.20

在 Linux 上，解析器服务把 DNS 服务器绑定到某个链路和一组路由域，所以没有关联到隧道链路的推送服务器会表现得像不存在一样。要查按链路的状态，而不是可能只指向本机解析器的 stub 文件。同样的分裂在反方向也会出现：搜索域存在却没有应用到隧道接口上，就会产生看起来随机的短名字失败。

如果加上后缀就能修好，剩下的工作就是把该后缀通过 VPN 配置文件下发，而不是让每个用户自己输。

NetBIOS 和 WINS 是另一套机制

旧式 SMB 仍可用 NetBIOS 名称服务查找裸名字，它通过广播或经 WINS 服务器应答。广播留在一个广播域内，遇到第一个路由器就停，因此跨不过隧道；WINS 之所以可用，是因为客户端有一个单播地址可供注册和查询。这就是为什么只承载 IP 的 VPN，在配置好 WINS 且可达时，仍能支持旧式名字。

nbtstat -n
nbtstat -R

对现代 SMB，应当依赖 DNS 和完整名字，并让旧式路径退役。如果它确实是旧式的，就提供 WINS 或替换应用；折中方案就是一条永远不会清空的工单队列。

当你能说出是哪一层失败时，这趟排查就结束了：解析器、后缀还是旧式发现。记下作答的解析器和可用的名字形式，因为下一个人会从同样的症状开始。