Netfilter策略路由和uRPF

在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,www.linuxidc.com 不必再进行一次新的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的正向包策略路由,那还是可以正常通讯的。

相关推荐