三通IT学院 门户 网络技术 查看内容

2014-7-22 15:17
对代理ARP技术的误读、无法完成代理ARP实验的故障分析

摘要 : 对代理ARP技术的误读、无法完成代理ARP实验的故障分析问题的提出:网络工程技术人员和或者学习者面对ARP代理技术时,通常能理解ARP代理的作用和技术要点是什么,但是无法根据技术描述去实现ARP代理的功能!首先来看 ...

时光与梦2014-7-22 15:172730

对代理ARP技术的误读、无法完成代理ARP实验的故障分析

                            

问题的提出:

    网络工程技术人员和或者学习者面对ARP代理技术时,通常能理解ARP代理的作用和技术要点是什么,但是无法根据技术描述去实现ARP代理的功能!

 

首先来看一般对代理ARP的定义:

 

 

    通常根据上述文字的描述,就意味着在如图1所示的环境中,主机192.168.2.2/24可以在不配置默认网关的情况下成功的与路由器R2的192.168.3.2/24通信。其实这种理解是没有错的,但是当用户使用实验来证实代理ARP的作用时,结果却非常的意外,如果在主机192.168.2.2/24上不配置任何网关,路由器R1启动了代理ARP功能,不能让192.168.2.2访问192.168.3.2,对,不能,永远不能,那这是为什么呢,难道是理论定义有错,现在我们来做分析。

 

 

首先看验证代理ARP技术时各个通信节点上的原始配置:

 

计算机192.168.2.2上的配置,如图2所示,确定只配IP地址不配置默认网关:

 

路由器R1和R2的配置如下所示,默认情况下路由器的代理ARP技术是被启用,可以通过指令showip interface e1/0在路由器R1上来查看并确认,R1的E1/0接口的代理ARP的确是被启动的,如图3所示。

 

路由器R1的配置:

interfaceEthernet1/0

 ip address 192.168.2.1 255.255.255.0

 

interfaceEthernet1/1

 ip address 192.168.3.1 255.255.255.0

 

routerrip

 version 2

 network 192.168.2.0

 network 192.168.3.0

 no auto-summary

 

路由器R2的配置:

interface Ethernet1/1

 ipaddress 192.168.3.2 255.255.255.0

 

router rip

 version 2

 network 192.168.3.0

 noauto-summary

 

按照上述的原始配置,那么主机192.168.2.2/24在没配置默认网关的情况下应该就能ping通192.168.3.2,但事实上,如图4所示,结果出乎意外,192.168.2.2根本就无法ping通192.168.3.2。

 

然后大众会发出几种对故障的猜想和推论:

 

1 关于代理ARP技术的理论的定义不正确,所以导致了无法完成的实验

能被列入RFC文档的论述,都是得到了比应用级更高的专家(研发级)共同认同的公理,虽然不能说100%就是定论,但是在多数情况下是不被推翻的,所以由于这种原因产生故障的可能性不太,要么就是应用级人员没有彻底理解文档,要么就是实施有误。

 

2 路由器IOS存在bug(漏洞),所以无法完成实验

种个厂商的IOS的确会存在bug(漏洞),但是这种bug通常会被顶尖的高手和黑客所发现,然后厂商会立即作出反应,对bug进行修复,并公开bug,典型的情况就是用户在查看IOS版本时,比如出现IOS12.2(14),说明这个版本已经经过了14次的修改,修改的次数越多,存在的bug就越少,所以对于代理ARP这种技术存在bug,而没被厂商发现的可能性太小了。

 

3 不同厂商的设备可能对ARP代理的定义和限制是不同的

这种原因就更不可能,因为网络公理,就相当于数学几何中的证明公理一样,它具备开放和开源性,差别只在于实现的指令和配置方式不同而已,再加上OSI模型的产生,所以所有厂商的技术,除私有特性技术外,都是一样,且必须一样,不然它将无法满足市场兼容性的需求,最终被踢出局。所以这种可能基本不会发生。

 

注意:任何一种对故障原因的分析和判别,都必须建立在数据、理论、取证三大元素之上,而且三大元素必须联动起来形成一种对故障现象非常有针对的“链条线”!尊重实验事实!

 

故障原因的分析思路与解决方案:

根据代理ARP的定义,如果主机192.168.2.2/24没有配置默认网关,那么它发出对192.168.3.2的ARP请求,将被路由器的R1的E1/0接口所接收,然后R1将代理源主机192.168.2.2去请求192.168.3.2的MAC地址,然后完成不同网络的通信。

一个关键过程是:如果路由器R1确认已经启动代理ARP功能,那么主机192.168.2.2是否发送对192.168.3.2的ARP请求,如果没发送,为什么?如果发送,路由器R1是否成功的执行了代理ARP的这个过程,并将结果返回给主机192.168.3.2,所以这是需要取证的第一个过程,所以在需要在主机192.168.2.2ping192.168.3.2时取证这个过程,如下图5所示,对ping行为的取证时,整个过程主机192.168.2.2都没有发送任何ARP请求,既然通信源主机对目标192.168.3.2的ARP请求都没有,何谈代理ARP的过程,所以确认实验故障是在主机192.168.2.2上,那么,为什么会出现这个故障,主机192.168.2.2为什么不发送针对192.168.3.2的ARP请求。

 

 

 

主机192.168.2.2/24不发送ARP请求的原因:

     基于IPv4的主机在发送ARP请求之前,它会将目标的IP地址拿来和自已的子网掩码求“与”运算,如果目标主机的IP地址与自己的子网掩码在求“与”运算后,确定目标主机和自己的IP不在同一子网,那么该主机在没有配置默认网关的情况下不会发送任何ARP请求,如果配置了默认网关那么该主机会把ARP请求发送给默认网关,在代理ARP这个实验中,主机192.168.2.2子网掩码为255.255.255.0,请大家注意看目标主机192.168.3.2与自己的子网掩码求与得出的网络ID是192.168.3.0;而自己属于192.168.2.0,并没有配置任何默认网关,所以主机192.168.2.2/24根本不会发送任何ARP请求,所以路由器R1上的代理ARP功能根本就没法工作起来,实验怎会不失败!

 

故障解决方案并验证代理ARP的工作过程:

    然仍保持不配置任何默认网关,然后如下图6所示,将主机的子网掩码改为255.255.0.0(即16位的子网),那么目标主机192.168.3.2和255.255.0.0求“与”运算,得到网络ID为192.168.0.0/16,而改变子网掩码后,自己也属于192.168.0.0/16这个网段,所以主机192.168.2.2可以发送ARP请求,即便是192.168.2.2没有配置默认网关,由于路由器R1的E1/0接口启动了代理ARP,所以R1将代理主机192.168.2.2去对192.168.3.2进行ARP解析,此时即便主机192.168.2.2没有配置任何默认网关也能成功的与192.168.3.2通信如图7所示。

 

 

 

    如果用户在完成主机192.168.2.2改变子网掩码为16位,再ping192.168.3.2时,启动了协议分析器,那么就该能捕获如图8所示的数据帧,主机192.168.2.2在网络上询问谁是192.168.3.2的MAC,然后路由器在代理192.168.3.2对主机192.168.2.2做应答,R1使用自己E1/0的MAC地址来应答192.168.2.2。

 

致此为止,描述了对代理ARP故障的分析与解决,如果此时将路由器R1的E1/0接口的代理ARP功能关闭,会发生什么情况?答案是:主机192.168.2.2在没有配置默认网关的情况下再也无法ping通192.168.3.2,因为现在的连通性是代理ARP在维持。

 

关闭路由器R1的E1/0接口的代理ARP功能:

R1(config)#intee1/0

R1(config-if)#noip proxy-arp  *关闭代理ARP功能

 

注意:在关闭代理ARP功能以后,用户在作新的测试之前,如下图10首先在主机上使用ARP –a功能,查看主机的ARP缓存,如果缓存还存有没关闭代理ARP功能之前的解析结果,那么将误导您对代理ARP实验的认识,所以需要使用ARP –d清除缓存中所有的ARP记录,确认主机的ARP表已经被清空,再次ping192.168.3.2,结果是由于在R1上关闭了代理ARP的功能,连通性丢失!

 

 

     如果在这个过程中,您再次启动协议分析器分析实时通信的数据帧,如下图10所示,只有主机192.168.2.2的N个ARP请求,但是没有应答,原因就是关闭了路由器R1的代理ARP功能,又没有配置默认网关,所以不会对该请求作应答,除非再次启动路由器R1的代理ARP功能。

 

 

 

在实践环境中代理ARP一般用在什么地方,它的优势与不足是什么?

    一般在一些网络工程环境中,工程师为了防止用户错误的配置默认网关而导致通信丢失,可能会启动代理ARP功能,或者需要实现对子网划分的透明化,或者三层冗余时也会启动ARP代理。代理ARP有一定冗错的作用,但本人强烈反对这种做法,因为这会造成额外的流量,并构成很大的安全风险特别是在有可能发生ARP欺骗攻击的环境中。建议使用其它的冗余方案来替代它!


鲜花

握手

雷人

路过

鸡蛋
收藏 分享 邀请

最新评论

返回顶部