在一次有关某公司aDesk桌面云产品网络问题排查的过程中，和400工程师沟通的时候突然发现了一个奇怪的现象，在抓包过程中发现所抓取的数据包中有ICMP的重定向，当初认为此现象和所排查现象（两台windows7关闭了防火墙的虚拟机桥接在同一个虚拟交换机下互相ping不通）有关联，所以工程师跟进了一下，后面顺利解决，我也做了一次实验重新验证了该问题以及ICMP重定向的原因。
据400工程师的解释是这样的：由于虚拟机配置了DNS地址，但是由于虚拟机配置了两个IP地址（一个是管理网段没有配置网关地址是用于连接VDS的管理口登录VMP以及VDC，另一个是内网网段配置了网关地址用于连接内网从而实现外网访问），所以当系统利用管理网段来探测DNS地址是否可用时当然是失败的（没有连通外网），此时系统会使用内网网段来重新探测DNS地址的可用性，由于windows系统是利用ICMP协议探测DNS地址可用性的所以导致了ICMP报文的重定向使其重定向到内网网段来探测DNS地址的连通性。（由于当时这个原理400工程师解释没有听很清楚，但技术需要实事求是，所以希望大家多多指正追根究底！）
好了，既然是ICMP重定向，那么肯定要弄明白ICMP重定向的原因啊，随后百度之……
网上有很多经典的案例，自己归纳理解了一下，实验……
先上拓扑图：
简单的没天理啊！！！
好吧，现实就是这么骨感，接受吧……
饼子画好了，那么现在就要开始实打实的实验了。
真机环境当然没有！
还是拿出当年大学做实验的必备神器吧——GNS3！
对，就是这个小蜥蜴（没有代言没有广告费）
好了不说了，第一次写废话太多了要被喷，求大神放过鄙人！
进入正题：
GNS3的实验环境迅速搭好！
备注：PC的网关指向R1，R1上配置到R2的静态路由。
路由配置简要如下所示：
interfaceLoopback0
ip address 1.1.2.1 255.255.255.0
!
interfaceFastEthernet0/0
ip address 1.1.1.253 255.255.255.0
duplex auto
speed auto
!
no iphttp server
no iphttp secure-server
ip route 1.1.3.0 255.255.255.0 1.1.1.254
interfaceLoopback0
ip address 1.1.3.1 255.255.255.0
!
interfaceFastEthernet0/0
ip address 1.1.1.254 255.255.255.0
duplex auto
speed auto
!
no iphttp server
interfaceFastEthernet0/0
ip address 1.1.1.1 255.255.255.0
no ip route-cache
duplex auto
speed auto
!
ipdefault-gateway 1.1.1.253
no iphttp server
至于交换机是一个傻瓜的就不写什么了。
接下来在PC中ping R2上的IP地址1.1.3.1，然后在交换机SW1的端口1用wireshark抓包。（由于时间比较零散，所以把抓下来的包先保存了，文档是后面抽时间写的）
这里可以看到在PC发起第一个即编号NO.9的ICMP数据包时，在ICMP这一层的信息中显示：[No response seen]，说明第一个ICMP报文看起来是没有回应的。
然后，第二个ICMP数据包即NO.10的数据包在ICMP这一层的信息中注明了：Gatewayaddress：1.1.1.254。此IP地址为R2的FastEthernet0/0接口地址，所以R1通告给PC应该将此数据报转发给网关1.1.1.254。
此后，PC所有的ICMP数据报都发向了R2，成功ping通了1.1.3.1。
总结：
ICMP重定向使得在客户端的管理工作量大大降低，转而将所有负担推向了路由器。当然弊端也显而易见，由于PC的报文总是需要在网关所直连的网段链路上重复传输，所以会增加网络流量负担。
上述是ICMP重定向所造成的性能问题，但是这样的方法也会导致一定的安全隐患。
比如：一台PC-1支持ICMP重定向，但是如果有一台恶意的PC-2给PC-1发送ICMP重定向，那么以后PC-1发出的所有到指定地址的报文都会流经PC-2所指定的网关（也可以是PC-2本身），从而达到窃听的目的。但是经过我多方资料收集发现windows系统会对发来的ICMP重定向报文进行检查，若不是自己网关发送的则会丢弃。为了再次实验验证一次这个现象，遂又用GNS3的拓扑稍作修改进行实验。
拓扑：
图中Host1是真机也就是我的电脑，将其有线网卡桥接到SW1上，电脑网卡手动配置了IP地址为1.1.1.10/24 GW:1.1.1.253，可结果就是怎么也ping不通PC 1.1.1.1以及网关1.1.1.253，习惯性地查看了下真机的路由表（断开了无线网卡）：
跃点数40最低，其他看着也没什么问题，更何况是同一二层环境下同一网段的通信根本用不着这个啊！
最令人郁闷的是当路由器R1以及PC在ping真机地址1.1.1.10时，在真机端抓包发现收发ICMP报文都正常！
R1 ping 真机：
PC ping 真机：
好了，在真机ping 网关R1和PC试试吧：
真机 ping R1：
真机 ping PC：
看来真机是ping不通GNS3里面的PC和R1了，检查真机的arp表同时核对一下R1和PC的接口MAC地址：
没毛病！ORZ……
百度之，搜索半天也没得出什么结果……
好吧，看来可能是GNS3抽风了……
小弟排错已经用尽了洪荒之力！如果有哪位大神看出什么端倪烦请回复小弟指点一二，感激不尽！（后面附上GNS3实验环境文件）
折腾了一组，实验最终还是以失败告终，不过观点还是保留前人所述应该没啥子问题，凑合用吧。
file://localhost/Users/ZJ/Library/Caches/TemporaryItems/msoclip/0/clip_image036.png
本来一个ICMP的重定向实验却牵出这么多的小插曲，真是累觉不爱，所谓在平坦的路面上曲折前行也不过如此了。技术还是要求真务实的，希望大侠们在这里能够建言献策，共同营造良好的技术氛围，快乐地奋斗、成长！
发表于 2016-11-17 11:34
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
