注册 登录  
 加关注
查看详情
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

天马行空

宠辱不惊,闲看庭前花开花落;去留无意,漫观天外云展云舒……

 
 
 

日志

 
 
 
 

Netfilter策略路由和uRPF  

2013-05-10 16:08:32|  分类: 默认分类 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

在Linux中,往往会出现一些奇怪的现象,如果你仅仅知道一些皮毛,那么这些现象将会让你抓耳挠腮,因为Linux往往遵循RFC建议而有时却不会保持持久的大众化实现,毕竟,Linux并不是一个人搞定的,特别是网络协议栈这一方面。uRPF这个概念很多人都知道,Linux的实现却很不一致,在Linux实现中,它和策略路由的点点滴滴值得说一番,我们分为以下4个关键点来说明,当然这4点并不是全部关于uRPF的:
1.策略路由和OUTPUT链
Linux的Netfilter实现5个HOOK点,其中OUTPUT点在路由之后,那么如果我们将如下的路由:
route add -net 192.168.188.0/24 gw 192.168.40.254
移植到策略路由:
ip rule add $标签1 tab new
ip route add 192.168.188.0/24 via 192.168.40.254 table new
route del -net  192.168.188.0/24
iptables -t mangle -A OUTPUT -XXX -j MARK --set-mark $标签1
那么当我们从本机发包到192.168.188.0/24的时候,得到的结果将是“路由不可达”。这是因为Linux的基于标签的策略路由是为“过路包”设计的,在本机发包进入任何Netfilter钩子点之前首先要经过IP路由,也就是说OUTPUT链在IP路由之后,此时任何的打标签策略都还没有被应用,因此就会出现上述的奇怪现象。
2.CONNMARK target和MARK target
在Linux Netfilter中,有CONNMARK和MARK两个target,其作用都是set-mark,那么这两个target有何不同呢?很简单,CONNMARK是为一个“连接”即conntrack打上一个mark,而MARK仅仅是为一个packet打上一个mark,对于CONNMARK,如果想让后续的包或者返回包也被打上mark,不必再进行一次新的iptables规则匹配,只需要restore-mark即可,而对于MARK,则不能这么做,因此它是不依赖ip_conntrack的。
        因此,考虑以下现象:
路由:
ip rule add $标签1 tab new
ip route add 192.168.188.0/24 via 192.168.40.254 table new
route del -net  192.168.188.0/24
iptables规则:
iptables -t mangle -A PREROUTING -i $内网口 -XXX -j MARK --set-mark $标签1
rp_filter配置:
sysctl -w net.ipv4.conf.$所有网卡.rp_filter=1
访问192.168.188.0/24,将发现返回包无法经过网关,为何呢?很简单,rp_filter为1,显然为严格uRPF,此时返回包的反向路由必须被查找到且和策略路由的结果一致,然而策略路由是无法被命中的,因此返回包没有命中任何iptables打标签的规则而没有被打标签,进而不命中策略路由...,如果将iptables中的MARK改为CONNMARK呢?也不行,还缺少一条:
iptables -t mangle -A PREROUTING -j CONNMARK restore-mark
才行,因此请注意,始终将上述规则放在所有规则的靠前的位置且在其后加上RETURN target的规则,可以:第一,免除很多基于mark的iptables规则查找;第二,可以避免由于uRPF而导致的奇怪问题。
3.标签策略路由和NOTRACK target
如果还是出现了奇怪的问题,那么看一下是不是NOTRACK target导致的呢?我们知道raw表是所有规则的最前面的,因此如果在raw表中被NOTRACK了,那么就别指望后面的任何mark规则起作用了,所有的基于mark的策略路由也将无效,更隐蔽的是uRPF验证失败导致的包不可达将很难被发现。
4.路由cache与rp_filter
在IP路由查找的时候,首先要查找路由cache,在Linux的实现中,查找路由cache的过程不涉及任何的uRPF(在ip_route_input_XXX中没有任何fib_validate_source的调用),因此如果系统中有反向包的路由cache,即使你设置了rp_filter为严格uRPF,并且还故意配置NOTRACK以及基于mark的正向包策略路由,那还是可以正常通讯的。

  评论这张
 
阅读(365)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018