☰

尝试访问 \\fqdn 时出现“53 未找到网络路径”，但 \\IP 工作正常

tag-icon • tag-icon windows routing smb netbios
尝试访问 \\fqdn 时出现“53 未找到网络路径”，但 \\IP 工作正常

我想从另一台 PC（192.168.54.110/24，Win 10 Pro，我们称之为客户端）访问 Windows PC（192.168.44.1/24，WinXP，我们称之为服务器 ;-)）的文件共享。192.168.54.x 中的客户端旁边还有一台 MacBook。

（WinXP 盒的唯一目的是在此实验室设置中测试 SMB 访问，当然不用于生产用途。）

中间的路由器/防火墙充当 192.168.54.1 的 DNS 服务器。

客户端上按预期运行的情况：

ping server
ping server.fqdn
net view \\192.168.44.1

另外，我可以在 MacBook 上成功安装“cifs:\\server.fqdn”。

但是在 Explorer 中输入 \\server.fqdn 失败，并且

net view \\server
net view \\server.fqdn

两者都失败并出现错误“53 未找到网络路径”。

我排除了 DNS 问题，因为 ping 可以使用主机名。我排除了防火墙问题，因为它可以使用 IP 地址，并且它可以在 MacBook 上运行。

对我来说这看起来像是一个客户端问题。

我已禁用 AV/防火墙软件。我尝试将 server.fqdn 添加到客户端上的 hosts 和 LMHOSTS 文件中，但没有成功。服务器是否需要能够通过 DNS 解析客户端的名称才能正确响应？我需要匹配 ptr 记录吗？

我没有（也不想）有 Wins 服务器。这可能是问题所在吗？

答案1

较旧的 Windows 系统仍使用 NetBIOS 会话层作为 SMB 传输，并坚持验证 NetBIOS“被叫名字“客户端提供的。它们只接受与服务器的实际主机名匹配的 NetBIOS 会话，或者是存储在注册表中的别名，或者是通配符（如果通过 IP 地址访问）。这可能是 NetBIOS-over-IPX 和 NetBIOS-over-Ethernet 时代的遗留。

要完全禁用此检查，请在服务器端添加注册表项：

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters]
"DisableStrictNameChecking"=dword:00000001

（对于现代 Windows 系统，如果它们启用了 SMBv1，则可以通过此操作完成Set-SmbServerConfiguration；对于 XP，只有手动选项。）

Microsoft 已记录此内容KB940684和KB3181029。请注意，该问题特定于 SMB-over-NetBIOS（端口 139），不应适用于原始 SMB-over-TCP（端口 445）。

它也不适用于 SMBv2/3，因为这些版本似乎专门使用原始 TCP。

相关内容