今天碰到美国客户的一个问题, 防火墙在升级了新release的os image后,如下客户拓扑环境所示,pc2可以访问pc1,但是pc1无法访问pc2, 不过ping都可以通. 据说售后电话被打暴:(.大家压力不小.
实验室分析,发现原来是icmp redirect 报文惹得祸,代码中的错误导致的.
客户的配置:
pc2配置了一条缺省路由,指向10.20.1.1,防火墙上配置了一条静态路由,到目的地址10.20.2.0/24的报文,下一跳为10.20.1.10.
路由器上缺省路由指向10.20.1.1, pc1配置了缺省路由指向10.20.2.1.
分析:
(1) 从pc2发向pc1的报文, 根据路由会首先送到防火墙接口10.20.1.1, 根据icmp redirect规则, 防火墙会发icmp redirect报文给pc1, 指明从pc1去往目的地址10.20.2.20的下一跳网关应该是10.20.1.10, pc1的转发表里就会多一条到主机10.20.2.20的路由,之后的所有报文会直接发到10.20.1.10.
pc1可以正确收到pc2发过来的报文, 并且pc1返回给pc2的报文,通过路由器直接送到10.20.1.20.
从pc2到pc1的交互是没有问题的.
(2) 现在我们考虑从pc1主动发起的到pc2的TCP连接. pc1首先会发一个TCP同步syn报文给pc2, 当pc2收到这个报文后, pc2会回一个syn/ack报文给pc2, 根据路由表这个syn/ack报文会发到防火墙端口上.
现在问题就来了! 防火墙不同于路由器, 防火墙有大量安全特性. 当防火墙收到syn/ack报文时候, 在cache中确查询不到pc1发送的连接(syn)信息, 我们的防火墙代码会丢弃这个报文, 并且发一个TCP RST报文给pc2. 这样pc1就永远都没有办法与pc2建立起TCP连接了.
解决办法:
防火墙收到syn/ack的时候, 丢弃报文, 但是仍然会发一个icmp redirect报文给pc2. pc2中就有了一条主机路由.
防火墙仍然再发送一个TCP RST报文给pc2.(这个可以商榷)
现在pc1就可以主动与pc2建立起TCP连接了.
总结:
在设计拓扑环境的时候, 必须考虑数据流动的两个方向, 并且针对不同类型设备, 要做不同的网络方案考虑. 防火墙和路由器在很多方面不同, 防火墙有很多4-7层的特性是必须要考虑的.
ICMP 重定向报文的接收者必须查看三个IP地址：
- 导致重定向的IP地址，即ICMP重定向报文的数据位于IP数据报的首部
- 发送重定向报文的路由器的IP地址，包含重定向信息的IP数据报中的源地址
- 应该采用的路由器IP地址在ICMP报文中的4 ~ 7字节
关于ICMP重定向报文有很多规则：
首先，重定向报文只能由路由器生成，而不能由主机生成。
另外，重定向报文是为主机而不是为路由器使用的。假定路由器和其他一些路由器共同参与某一种选路协议,则该协议就能消除重定向的需要。重定向报文只会在主机上生成一条目的地址为32位主机的路由. 路由器不会处理重定向报文.
首先，重定向报文只能由路由器生成，而不能由主机生成。
另外，重定向报文是为主机而不是为路由器使用的。假定路由器和其他一些路由器共同参与某一种选路协议,则该协议就能消除重定向的需要。重定向报文只会在主机上生成一条目的地址为32位主机的路由. 路由器不会处理重定向报文.
在4.4,B,S,D系统中,当主机作为路由器使用时,要进行下列检查,在生成,ICMP,重定向报文之前这些条件都要满足,
- 出接口必须等于入接口
- 用于向外传送数据报的路由不能被ICMP重定向报文创建或修改过，而且不能是路由器的默认路由
- 数据报不能用源站选路来转发
- 内核必须配置成可以发送重定向报文
另外，一台4.4,B,S,D主机收到,ICMP,重定向报文后,在修改路由表之前要作一些检查,这是为了防止路由器或主机的误操作,以及恶意用户的破坏,导致错误地修改系统路由表
- 新的路由器必须直接与网络相连接,
- 重定向报文必须来自当前到目的地所选择的路由器,
- 重定向报文不能让主机本身作为路由器,
- 被修改的路由必须是一个间接路由,
关于重定向最后要指出的是,路由器应该发送的只是对主机的重定向，代码1或3，而不是对网络的重定向。子网的存在使得难于准确指明何时应发送对网络的重定向而不是对主机的重定向,只当路由器发送了错误的类型时,一些主机才把收到的对网络的重定向当作对主机的重定向来处理。
在举个例子分析上面的规则, 如下拓扑图所示, 配置如上图的客户配置, 当pc3发送报文到pc1的时候, 根据规则,
防火墙仍然会产生一个icmp redirect单播报文, 这个报文会经路由器转发到pc3.
但是pc3不会根据这个icmp redirect报文生成一条主机路由, 因为下一跳不在直连网络中.
本文转自jasonccier 51CTO博客，原文链接：http://blog.51cto.com/jasonccie/391024，如需转载请自行联系原作者
