OpenVPN 推送 DNS 后本地 Samba 共享消失

Samba 会在 OpenVPN 连接的那一刻丢失本地共享，而隧道几乎从来不是原因。挂载正常，NAS 在运行，隧道安装的解析器却在回答一个它从未见过的名字。Samba 在查找顺序的早期就询问这个解析器，相信了答案，并连接到一个没有任何服务在监听的地址。修复共享意味着修复答案，而不是修复挂载。

五项检查，按其每一步能排除最多可能性的顺序排列。

谁为短名作答

问操作系统，而不是文件管理器。resolvectl status 会打印每条链接上挂载的 DNS 服务器，并标出哪条链接是默认路由，而对短名的查询会报告作出应答的服务器。分别对 NAS 的名字和你知道存在于办公域中的名字各运行一次。如果两个答案来自不同的服务器，你就找到了分裂点。

检查该回复是否定答案还是一个地址。否定答案意味着 Samba 本应转向另一种机制，故障在别处。地址则意味着 Samba 连接到了真实的位置却什么也没拿到。

为什么 Samba 会相信错误的答案

Samba 通过 name resolve order 设定的固定顺序来解析名字。在大多数发行版中，默认值包含 host，也就是 DNS，它排在 NetBIOS 广播等仅限局域网的机制之前。因此推送解析器的隧道对每个共享名都获得第一次拒绝权，包括那些本不应离开大楼的单标签名字。

通常未知名字会返回否定应答，然后轮到下一个机制。有些解析器，尤其是消费级 ISP 和公共解析器，会改用搜索页或广告地址来回答未知名字。这个回复在解析器库看来像是成功，于是 Samba 停止查找，拨向一个与你的网络毫无关系的地址。

结果就是共享在没有错误对话框的情况下消失。这一顺序中没有任何一环是 VPN 路由故障，所以 ping NAS 仍然正常，而浏览它却不正常。

两种范围不同的修复

范围较窄的修复保留被推送的解析器，只改变 Samba 可以向它询问什么。在守护进程真正读取的 Samba 配置中加入两行，然后重启服务：

[global]
   name resolve order = wins lmhosts bcast
   dns proxy = no

该列表中没有 host 时，DNS 就退出了共享查找的路径，单标签名字留在本地网段。办公名字对其他所有程序仍能正常解析，因为这只改变 Samba。代价是 Samba 再也无法使用 DNS，因此用完全限定的办公名字寻址的共享就成了问题。

范围较宽的修复则消除原因：停止推送会为不属于自己的名字作答的解析器，或者推送拆分 DNS 策略，让只有办公后缀能到达办公解析器。在受管网络中这是更好的长期答案，因为它同时保护浏览器和包管理器，但它需要服务器端的管理权限，以及 一个遵从所推送设置的客户端。

请有意选择其中一种。更改解析器会同时改变所有应用程序的名字解析，这属于变更记录，而不是为支持电话做的编辑。

后缀可以解释一切

如果客户端还推送了搜索后缀，短本地名在被查询之前就会被改写成办公域。那么解析器根本没有说谎：有人就一个办公名字向它提出了合理的问题，它给出了正确的答案。要区分这种情况和广告地址的情况，请阅读解析器输出中被查询的名字，因为两种故障在文件管理器里看起来完全一样。

这里的解决办法要么使用完全限定的本地名字，要么添加一条拥有本地后缀的拆分 DNS 规则。两者都不需要改动 Samba。

在重连之后验证

在一次会话中测试三个名字：用短名访问本地共享、用名字访问办公主机，以及一个普通网站。如果第一个正常而第二个失败，说明修复只是搬动了故障而没有消除它。如果第三个失败，说明解析器的改动超出了预期，现在每次查找都可疑。

然后断开并重新连接隧道，再重复这三项。推送的选项会在每次连接时重新应用，所以只在运行时存在的修复可能在某次连接后消失，而配置文件毫无变化。记录每个后缀归属于哪个解析器以及生效的查找顺序，并写下日期，因为当这个问题再次出现时，下一次客户端更新就是明显的嫌疑。

如果五项检查之后共享仍然失败，请在改动其他任何东西之前，抓取确切的查询和确切的回复。这两行能区分解析器故障与真正不存在的名字，也是你能写下的最快的交接记录。