摘要 : 对代理ARP技术的误读、无法完成代理ARP实验的故障分析问题的提出:网络工程技术人员和或者学习者面对ARP代理技术时,通常能理解ARP代理的作用和技术要点是什么,但是无法根据技术描述去实现ARP代理的功能!首先来看 ...
对代理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欺骗攻击的环境中。建议使用其它的冗余方案来替代它! |