![未发送或答复 NetBIOS 名称服务请求](https://linux22.com/image/706034/%E6%9C%AA%E5%8F%91%E9%80%81%E6%88%96%E7%AD%94%E5%A4%8D%20NetBIOS%20%E5%90%8D%E7%A7%B0%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82.png)
我的系统存在严重的不一致,即 NetBIOS 名称服务请求是否在端点上运行。我正在使用 Win7 和 Server 2008R2 系统进行测试。我们没有 WINS 服务器,也不想有,但我最感兴趣的是不同的行为。这里的驱动程序是我们的 Nessus 扫描仪,它通过使用其插件 10150 向设备查询其 NetBIOS 名称来获取系统的名称,这显然与 的作用相同nbtscan
。
根据我的理解和观察,Nessus、nbtscan
运行nbtstat -A XX.XX.XX.XX
并向目标上的 UDP 端口 137 发送一个 netbios-ns 数据包,该数据包应该向请求者发送一个 UDP 端口 137 响应。当我在有问题的机器上使用 Wireshark 观察时,我看到数据包进来了,但没有发送响应。但有些系统按预期回复。我思考我已经排除了主机防火墙是罪魁祸首的可能性,所以现在我们先假设这一点。
此外——这可能是一件很奇怪的事情——在这些没有响应的系统上,它们似乎也没有试图发送当我发出命令时,UDP 数据包nbtstat -A XX.XX.XX.XX
。它们立即退出并显示“未找到主机”,Wireshark 不显示任何传出数据包(工作系统在放弃之前最多生成三个数据包)。
就好像这些系统上的 NetBIOS-NS 子系统被禁用了,并且它没有尝试使用它,但我找不到会导致这种情况的设置的证据。更令人沮丧的是,微软的文档似乎都没有承认这种单播名称解析方法的存在——您阅读的所有内容都只谈论广播或 WINS 服务器消息传递。说到这一点,工作和非工作系统都处于混合模式ipconfig /all
,我已经明确设置了接口以启用 TCP/IP 上的 NetBIOS,但这没有帮助。我看到netstat -an
内核是正在监听 UDP 端口 137,但这些消息没有得到答复。
是否存在导致我所看到的行为的设置?这似乎是最有可能的答案,但我的搜索没有找到任何结果。
更新
我现在还观察到 UDP 数据包是已传输如果查询是针对同一子网中的另一个 IP。所以,这很重要。但我还是不知道为什么在某些主机上的行为会有所不同。为什么我的某些系统只为本地子网上的 IP 发送(并响应)NetBIOS-NS 的 UDP 数据包?
答案1
我遇到一个问题,几台计算机无法访问旧版 Windows 95(是的,我知道……)机器上的 SMB 共享,这些机器联网在单独的 VLAN 上,没有互联网连接。很少有计算机能够连接共享,但随着时间的推移,它们逐渐停止工作。
我使用 wireshark 深入挖掘,发现最后一台正常工作的计算机发出了 NBNS 查询,而未正常工作的计算机则不会发出。与此情况完全一样,nbstat -A 立即返回“未找到主机”。将计算机移至同一 VLAN 使其再次正常工作,但这并不是真正的解决方案,因为连接到旧 PC 的计算机必须具有互联网连接。
经过几个月断断续续的研究,我终于解决了这个问题:
https://support.microsoft.com/en-us/kb/3161949
本地子网外的 NETBIOS 通信已得到强化。因此,默认情况下,某些依赖于 NETBIOS 的功能(如 SMB over NETBIOS)在本地子网外不起作用。要更改此新的默认行为,请创建以下注册表项:
子键:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters 值名称:AllowNBToInternet 类型:Dword 值:1 标志的默认值:0
将密钥添加到注册表并重新启动后,nbtstat -A xx.xx.xx.xx 开始发送查询,SMB 共享再次正常工作。希望这能对以后遇到此问题的人有所帮助。