如上图，你会发现，会有两个其它不同的IP来回复这个数据ping包，挺怪！因为这两个IP（192.168.10.64和192.168.10.108）是绑定在两个无线路由器上WAN口的IP地址。
刚开始没有注意这个细节，只注意到TTL=127这不正常。不曾察觉到回复的IP不是192.168.10.252这台服务器，所以以为是客户机有问题，但经检查发现，客户机与内网的其它主机都能ping通，回复IP为192.168.10.252（TTL=128），故又回过来看这个ping的结果。细查就发现了上述这样的问题。
然百思百试不得其法，无奈将本客户机的IP改为其它的IP地址。如192.168.10.109，之后尝试ping服务器，这时如下图所示：
此时一切正常。
改过来192.168.10.97，现象又重现了。
所以，只要避开这个IP(当然不与其它IP冲突即可)，设置成其他的本网段的内网IP均能正常访问服务器。
因为服务器作了IP-MAC的批处理绑定，而且此主机的IP有过更改的印象，所以想来可能是服务器的ARP绑定条目还没有更新。故到服务器，编辑所做的批处理，发现192.168.10.97这个IP绑定的MAC地址并非是此主机的MAC地址。将MAC地址正确绑定更新后，重新运行批处理，进行服务器的ARP表的更新，然后再到客户端，将IP更改回97，此时，一切恢复正常了，BugFree页面能正常打开，网络文件的共享也能进入了。
问题虽然解决了，但至今仍未知，为什么一个在服务器ARP表的一个错误绑定，会导致内网的无线路由器来替服务器回应这个ping包。
求解中。。。。
评论