解决Samba作为WINS服务器时总是把某个服务器名称解释为错误IP地址的问题

　　手头的LINUX网关兼任了很多工作，其中包括了作为内网的WINS服务器。这个设定的原因是...算了不表。某天，突然发现之前好好的某个网络共享死活连不上去。于是进行各种检查，最重要的表现是：

• 用IP地址访问网络共享是否可行？是。
• 用服务器名访问网络共享是否可行？否。

　　照旧怀疑是否各种IP设置的问题？是否WINDOWS的某些网络相关服务（尤其是 TCP/IP NetBIOS Helper 这个服务）是否被停掉？甚至怀疑了WINSOCK是否被破坏......一番折腾，仍然不行。

　　没辙了，上网乱找，找到一个很旧很旧的小软件： NBLOOKUP （https://support.microsoft.com/en-us/kb/830578）。这个软件一直都没有被 Microsoft 纳入到正式的NetBeui工具（比如常用的NBTSTAT）家族中。用这个工具检查发现，它返回的服务器名称解释结果是不正常的，具体一点，就是服务器的名称未能解释成正确的IP地址，而是解释成了这台服务器在之前使用的另外一个地址。下面是这个工具的输出例子：

C:Userssender>nblookup wings

Recursion is on

Querying WINS Server: 192.168.1.6
NetBIOS Name: wings
Suffix: 20

Name returned: WINGS
Record type: Unique
IP Address: 192.168.1.10 （注：实际应该是192.168.1.33）

　　这就有点奇怪了。按说NETBEUI的工作机制，它是不存在名称缓存，所有的解释都是即时发组播包去查询的。由于客户端计算机设置了LINUX网关作为WINS服务器，于是开始怀疑问题出在网关的Samba上。通过在网关上直接抓包（WireShark也是必须要掌握的工具），发现网关的Samba服务对于WINS解释请求都是立即回应，没有进行任何组播查询的。仔细去看文档，原来Samba负责进行WINS解释的nmbd服务的工作方式和WINDOWS本身的实现有所不同。Samba的nmbd服务可能是出于减少网络广播的目的，会在内部维持一个服务器的解释列表，文件名是wins.dat。通过locate找到这个文件的位置是：

/var/cache/Samba/wins.dat

　　停掉服务然后删除这个文件，再重启服务：

service smb stop
rm /var/cache/Samba/wins.dat
service smb start

　　目测wins.dat文件自动被重建。再在客户端上通过nblookup进行测试，一切正常了。附带一提的是在Linux下，Samba也提供了类似nblookup的工具，名称为nmblookup，这里就不浪费时间去介绍了。

　　最后一个问题是为何这个IP地址改了这么久，直到今天才出事？认真想了一下，才发现其实是很多事情掩盖了这个问题：
　　1、改IP后为了保证兼容性，旧IP被作为第二IP地址依然保留在适配器的设置中，直到最近几天才删掉；
　　2、删掉旧IP后直到发现问题的这一段时间内，这个网络共享都是通过之前创建的、基于新IP而不是服务器名称的网络驱动器去访问的；
　　3、直到网络大调整，网络驱动器删除重建时，问题就跳了出来。

　　结论就一个字：囧。

本站微信订阅号：

本页网址二维码：