揪出局域网中私自为DHCP分配IP的元凶

　　我们单位的住宅小区是通过雷科通的易线宽产品进行的双向网改造，组网示意图如1所示：

　　图1 利用雷科通的易线宽产品进行组网

　　如上所示，这种组网方式是利用雷科通设备+有线电视分支分配网络将互联网信号送至楼幢内，再通过楼幢内交换机+五类线入户，这样就可以有效的保护已有的投资，终端PC用户设置为自动获取IP地址模式，通过前端机房的DHCP服务器获取IP地址、子网掩码、网关、DNS服务器等信息，总体来说，这套设备运行是稳定的，DHCP服务器我们是通过LINUX平台实现的，也没什么问题，但是最近一段时间老是用户反映上不去网。

　　我们跟踪了一下故障，发现故障现象也很明显，即上不去网的用户家里微机获得了一个以192.168.1打头的IP地址，网关为192.168.1.1，这明显是通过一台宽带路由器获得的IP地址，随后我们在该用户微机的浏览器上登录192.168.1.1这个地址，即打开了一台宽带路由器的管理界面，好在这台路由器的用户名/密码是默认的admin/admin，我们登陆进去，将该路由器的DHCP功能关闭，进行完以上操作后小区的网络又稳定了一段时间，但是前几天又有用户反映说是上不去网了，我们查了一下，故障现象跟上次的一样，但是由于这次路由器被更改了登陆密码，所以我们不能通过关闭该路由器的DHCP功能来解决问题了，这次到了彻底解决问题的时候了，一定要在局域网中揪出这台私自为用户分配IP地址的宽带路由器，才有可能保证局域网的安全稳定运行，下面是我们的操作步骤。

　　一、在CISCO3550交换机上定义该路由器所在的端口

　　由于CISCO3550交换机是位于网络的最顶层，所以我们本次的操作只是对该宽带路由器的位置大致做一个定位，登录到CISCO3550交换机上，有两条命令相结合即可以搞掂。

　　3550#show ip arp | i 192.168.1.1

　　Internet 192.168.1.1 4 000f.1f66.0c58 ARPA Vlan66

　　3550#show mac-address-table | i 000f.1f66.0c58

　　66 000f.1f66.0c58 DYNAMIC Fa0/7

　　从中可以看出这台宽带路由器是位于CISCO3550的第7口，即雷科通头端所在的位置，我们初步定位完以后，就可以进行下一步的操作了。

　　小技巧：如果ping不通一台网络设备，可以知道它的MAC地址吗?如果是在一台微机上，不通过专门的软件是很难实现的，但是在CISCO3550交换机上就没有问题，执行一次ping操作，交换机会自动通过ARP协议得到IP地址与MAC地址的对应关系，同时也会给出该IP所在的端口位置，这也算是CISCO3550交换机的一个高级应用吧。

　　二、定位该宽带路由器位于哪台终端设备下面

　　要实现这个目标的思路是这样的：通过第一步的排查，可以肯定宽带路由器肯定是位于某一台终端设备下面，那么我们就在机房用一台微机一直ping这台宽带路由器的IP地址(192.168.1.1)，然后在这个过程中依次重启终端设备，如果在重启哪台终端设备的时候ping不通该宽带路由器的IP地址了，说明那台宽带路由器就位于这台终端设备下面。当然重启终端设备是不用到现场去拨电源的，在雷科通设备的网管软件上就可以实现。一种方法是通过图形界面执行重启操作，另一种方法是通过命令行实现，第二种方法稍微复杂一点，操作步骤如下:

　　1、登陆到头端设备

　　telnet 192.168.168.2

　　输入用户名和密码：root/*****

　　2、查看当前终端设备的信息

　　ND:->:show-topology;

　　Type ID MAC Address Hop State Board Type

　　CPE 05 00:17:73:60:13:0c 1 Normal One Port

　　CPE 02 00:17:73:60:13:08 1 Normal One Port

　　CPE 01 00:17:73:60:13:0a 1 Normal One Port

　　CPE 11 00:17:73:60:13:02 1 Normal One Port

　　CPE 09 00:1b:9e:9a:83:8f 1 Normal One Port

　　CPE 08 00:17:73:60:12:fa 1 Normal One Port

　　CPE 13 00:17:73:01:08:4a 1 Normal Two Port

　　CPE 12 00:1b:9e:9c:15:7d 1 Normal One Port

　　CPE 04 00:17:73:60:13:06 1 Normal One Port

　　CPE 10 00:1b:9e:9a:82:d5 1 Normal One Port

　　CPE 07 00:17:73:60:12:fc 1 Normal One Port

　　CPE 06 00:17:73:60:13:04 1 Normal One Port

　　CPE 03 00:17:73:60:12:f8 1 Normal One Port

　　Total Node Number: 13

　　3、执行重启某台设备的操作

　　ND:->:reboot-node:id=1,time=0;

　　Succeed in rebooting Node(0x01).

　　这个命令是重启的1号终端，其它的终端以此类推，我们可以看一下，重启时的设备状态：

　　ND:->:show-topology;

　　Type ID MAC Address Hop State Board Type

　　CPE 05 00:17:73:60:13:0c 1 Abnormal One Port

　　CPE 02 00:17:73:60:13:08 1 Normal One Port

　　CPE 01 00:17:73:60:13:0a 1 Reseting One Port

　　这里也有一点经验，即重启两台终端设备的间隔时间不能太短，因为终设设备重启的速度很快，如果间隔时间太短的话，很难判断是宽带路由器是位于哪台终端设备后面。

　　通过以上的方法就可以找到定位到下面带有宽带路由器的终端设备，下面的工作就是到现场去了。要迅速找到那台终端设备的位置要快也容易，那就是原来维护有一个终端设备的MAC地址和具体位置的对应表，如果没有的话，那就麻烦一点了，到现场去一台一台的找，在每台终端设备上都贴着对应的MAC地址，一台一台的找就可以看到了。

　　在交换机上查找具体哪根网线连接到该宽带路由器上，进行的操作就是纯手工了，还是让机房的同事一直ping着那台宽带路由器的IP地址，我将交换机的网线一根根拨出，如果拨到哪根网线时PING不通宽带路由器了，说明就是使用那根网线的用户家里接了一台宽带路由器，事实上我们的运气很好，才拨第一根网线就找到了，到了该用户家一看，差点没气的背过气去，原来他不是把交换机过来的网线插在宽带路由器的WAN口上，而是接到LAN口了，这样就形成了一台威力强大的DHCP服务器，为整个头端下面所有PC都自动分配IP地址，结果造成大面积的网络故障，那个用户还一脸无辜的样子，“我还没报修呢，你们怎么就上门了?”大哥，你可以害得我们好苦啊。(真想着揣他几脚)，出现故障网络拓扑如图2所示：

　　图2 交换机过来的网线插到了宽带路由器的LAN上

　　三、故障原因反思及解决方法

　　针对这一故障现象，我们和工程部的同事研讨了好久，认为这种现象的危害是严重的，因为不论用户是有意还是无意，只要按这个接法做，都会造成大面积的网络故障，而且对于这种实现起来难度系数极小的“破坏”活动，确实是防不胜防。

　　通过与厂家的沟通，我们制定了三套预防的方案。

　　(一)让用户使用固定的IP地址

　　这种方案，实际上就是在我们单位办公室的局域网上网采用的方法，缺点是家庭用户种种条件的限制，很难记住为自己微机分配IP地址，而且如果出现IP地址冲突之类的故障，也很难通过电话等远程的方法指导用户修改IP地址。不过这个方案确实是不怕用户家里自己接一个宽带路由器(而且还是反着接)。

　　(二)让雷科通的设备只从指定的DHCP服务器获取地址

　　这个功能是我们非常需要的，在一次次追查那台“捣乱”的宽带路由器未果的时候，我们就在想，如果终端设备上能够设置只通过指定的DHCP服务器获取IP地址的话，这样终端设备就不会被那台宽带路由器所干扰，我们也就不用找得这么辛苦了。但是厂家的技术人员告诉我们，这个想法很好，但是从目前的技术体系来说，是不可能实现(-_-!)。

　　(三)让用户通过PPPOE的形式上网

　　这种形式有很多的好处，由于局域网用户上网时不是通过DHCP的方式(当然也不用设置静态IP地址)，而是通过PPPOE拨号获得一个IP地址，这样就不会受到非法的DHCP服务器的干扰了。其实PPPOE服务器的好处不仅如此，一来架设一台PPPOE服务器不是一件容易的事，二来通过PPPOE的方式上网，局域网内也不会发生ARP地址欺骗攻击的问题了。有关架设PPPOE服务器的文章，请参看我们以前在IT168上发表文章，链接如下：

　　利用LINUX6.0桌面版架设PPPoE服务器：http://net.it168.com/a2008/1211/260/000000260035.shtml

　　架设pppoe服务器拨号上网 防止ARP欺骗：http://subject.it168.com/Article/articleview.aspx?id=212533&type=cms

　　总之，经过我们不懈的努力，终于把这个故障解决了，真是去了一块心病，不过从中发现我们需要注意的问题还真不少，局域网故障排除就是这样的，会不断的寻到新的问题，但只要用心，总可以找到解决的办法的。