出错的DHCP服务器

《网管员世界》  上海博科资讯股份有限公司 陈运栋

    一大早赶到公司,像往常一样打开我的网管电脑,咦,怎么登录的时间要那么久,正常的情况



 



只要30秒就可以进入桌面。我拔掉网线,一下子就登录进去了,但是我心里估计,一定没有登录到



 



域,而只是登录到本地。果然,我PING了一下域控服务器,没反应,一查IP地址,是



 



192.168.136.113,我们公司是采用DHCP分配IP地址的,网段应该是172.16.10.x才对,怎么会分配



 



到192.168.136.x网段了呢,肯定是有另外的一台DHCP服务器。此时同事们已纷纷打来电话说网络



 



不正常,无法上网,当时我想得很简单,找出那台DHCP服务器,关掉被误配置的服务,再通知大家



 



重新启动就能全部搞定,可是没想到的是更复杂的情况在等着我呢。



 



    我使用IPCONFIG/ALL命令获取该DHCP服务器的IP地址为192.168.136.254,我再使用ping -a 



 



192.168.136.254命令想获取该计算机的名字,因为在我们公司计算机名就是使用者的名字缩写,只要知道了



 



计算机的名字也就知道了该台计算机在哪里,可是令我失望的事情发生了,非但无法获取该台计算机的名称,



 



192.168.136.254根本连ping都ping不通。可是它的确是分配给我ip地址的一台计算机啊!



 



    我开始疑惑了,为进一步了解获取ip地址的过程,我打开了网络抓包工具Sniffer pro4.5,在



 



开始抓包之前,我先拔掉了网线,因为一旦插上网线,第一步就是获取ip地址,而我只需要看最前



 



面的几个包就可以,这样可以减少需要查看的包的数量。结果发现192.168.136.254那台计算机用



 



的网卡居然是VMWare,造成现在网络瘫痪的罪魁祸首是一台安装有VMWare的计算机。可是现在如何



 



找到它呢?我们公司的网络拓扑是将近二十个交换机层层级联在一起,相当于一个广播域,当时摆



 



在我面前有两个办法:一是逐台检查24小时开机的服务器,因为我今天一大早就到公司了,不可能



 



是某人的工作用计算机;二是用二分法,逐交换机再逐端口地找出那台有问题的DHCP服务器。  



 



  由于考虑到第一种方法收效太慢,因此还是采用二分法,先关掉一半交换机,拿一台笔记本电脑



 



插在剩余的交换机上,运行ipconfig/renew命令,如果能renew且为错误的ip地址,则证明那台



 



DHCP服务器在这一半的交换机里,如此重复几次,则可以定位到一台交换机上,再逐端口找到那台



 



问题计算机,一共花了大约半个小时的时间,明确那个网口是E24,PowerEdge 600服务器,直接打



 



开VMWare WorkStation,查看“Virtual Network Setting",如图1。



 



    一眼就可以发现该虚拟机在Vmnet0(Bridge)上打开了DHCP服务,再查看”DHCP",如图2.



 



   可以看到,VMnet0上DHCP分发的IP地址正是192.168.136.x网段。把Vmnet0上的DHCP服务器删除



 



之后再通知大家重新启动,网络恢复正常。



 



   这次从发现网络故障到网络恢复正常一共花了近一个小时时间,恢复时间较长主要因为时间都\



 



浪费在找到那台计算机上,通过这次故障我得出以下结论:



 



    VMWare在使用中,尽量不要对Vmnet0做什么操作,如开DHCP等,该软件在实施这样的操作之前



 



会提示使用者这样会影响到真实的网络,但是对于初学者来说很难理解。



 



  另外,DHCP服务有缺陷。本来我以为只有“Authorize"过的DHCP服务器才有权向局域网内计算机



 



分发IP地址,其实并非如此。由于计算机在获取IP地址之前根本无法与域控服务器通信,更无法受



 



到域安全策略的管理,DHCP的原理就是需要IP地址的计算机发一个广播包(DHCP REQUEST),哪台



 



DHCP服务器先收到,回复一个DHCP ACK包,其中包含了分配的IP地址,这也就解释了此次故障发生



 



时部分同事的计算机获取的是正确的IP地址,因为他们机器的广播被获得授权的DHCP服务器先接



 



收,而部分同事因为获取了错误配置的DHCP服务器的响应从而获取了错误的IP地址。



 


转载于:https://blog.51cto.com/6167422/1179392