SMB 共享只在 VPN 上失败：是签名问题还是子网冲突？

一个在办公室可用、回家却超时的映射盘，本身几乎提供不了什么有用信息。隧道显然在传包，否则请求根本到不了服务器。真正失败的只有三层中的一层：名字解析到了错误地址，客户端拒绝为会话签名，或者旧会话活过了承载它的连接。三者的修法各不相同，其中两种在客户端一侧。

三种故障穿着同一个错误

盘符不会告诉你哪一层坏了，而错误文本通常笼统到三种都能套。用两个快问题把它们分开：服务器能否用 IP 地址应答，445 端口是否接受连接？

这些答案给出的是判断表，而不是猜测。IP 通、名字不通，指向解析。两者都通但登录被拒，指向签名。两者都通、但隧道中断后读文件卡住，指向过期会话。

请按这个顺序排查，因为解析到错误主机的名字会让后面每一项测试都失去意义。

先解析名字，再碰共享

如果服务器在它的地址上应答，而共享名超时，说明隧道在正常工作，客户端找错了地方。在远程访问中，这多半由两个原因造成。

第一是地址重叠。当办公室使用 192.168.70.0/24，而家里的路由器也发放同一网段时，解析到 192.168.70.20 的主机名可能指向本地设备，而不是隧道另一端的服务器。Windows 于是可能把请求发到本地、拒绝该路由，或解析到恰好占用该地址的打印机。修法是给一侧重新编址，而不是再加一条路由。

第二是 DNS 作用域。VPN 适配器没有内部 DNS 服务器，或该服务器经隧道不可达时，短名就会被交给公共解析器。碰共享之前，先读取适配器的 DNS 设置并直接查询内部名称：

> ipconfig /all | findstr /i "DNS Servers"
> nslookup files.corp.internal
Server: 10.90.0.2
Address: 10.90.0.2
Name: files.corp.internal
Address: 10.90.0.15

如果这次查询返回预期地址，解析这一层就排除了，问题在协议栈更上面。

两端的签名要求都要读

一个能连通、却拒绝所有登录的服务器，是策略不匹配的标志，而不是网络故障。Windows 可以要求客户端签名 SMB，而不会签名的服务器或 NAS 无论隧道多健康都无法完成会话。

不必翻遍策略编辑器，也能读出客户端设置：

> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnection

服务器端的对应值在服务器的 SMB 配置里，两边必须一致。在一个已报告的案例中，客户端由本地策略开启了该要求，而服务器根本不做签名；关闭要求并执行 gpupdate /force 后，共享立刻恢复。这是确认原因的诊断步骤，不是长久修法。

在服务器支持的前提下，优先在两端都开启签名。为让共享可用而更改安全设置，应连同原值与原因一起记录，免得下一次审计时谁都要重新发现一遍。

先清掉过期会话，再调计时器

只有在 VPN 断开并重连之后才卡住的共享，通常还攥着服务器早已丢弃的会话。服务器按 LanmanServer\Parameters 下的 Autodisconnect 计时器关闭空闲 SMB 会话，默认是 15 分钟；客户端则在 LanmanWorkstation\Parameters 下有自己的 SessTimeout。断开时间超过这些值，两端对会话的认知就不一致了。

按固定顺序复现，结果才有意义：连接隧道、打开共享、断开隧道两分钟、恢复，然后试着读一个文件。如果挂载自行恢复，就别动计时器。如果一直卡到你重新挂载，那就 在隧道起来之后重新连接共享，而不是在隧道存在之前去挂载，并检查挂载助手是否会重试。

对不稳定的链路，抬高超时是合理的最后一步，但它治标不治本。客户端为服务器已经忘掉的会话多等一会儿，仍然是在等。

最后，通过挂载读一个文件，再断一次、恢复一次隧道。这个验收测试一次覆盖三层，也是唯一与用户真实操作一致的测试。