Netfilter的rpfilter技术-Linux的uRPF

作为IP路由的一种补充，uRPF(单播反向路径转发)可谓非常有用，它认证了IP数据报的源地址，在一定程度了保护了网络的安全，比如有效防止了洪泛攻击。然而直到Linux内核的2.6的高版本版本，Linux只能实现严格的uRPF，这是由fib_validate_source函数来完成的，具体配置在/proc/sys/net/ipv4/conf/$dev/rp_filter，对于Cisco上很简单的松散的uRPF，Linux却无能为力，kernel 2.6的高版本可以为/proc/sys/net/ipv4/conf/$dev/rp_filter设置3个值，分别为不检查，严格uRPF，松散uRPF。kernel 3.3增加了rpfilter机制，将uRPF从协议栈移到了Netfilter，使得Linux可以在协议栈之外实现严格/松散uRPF，然而即便如此，对于VRF(虚拟路由转发)，Linux还是没有实现，不过在rpfilter的基础上，这个VRF的实现应该很简单。

        反向路由查找并非那么简单，因为需要考虑策略路由的问题，这一切从何道来呢？rpfilter技术作用在Netfilter的PREROUTING这个HOOK点上，这是合理的，因为必须在标准路由之前进行反向路径查询，以保证没有任何数据从被拒绝的反向路径发出，这里主要是为了禁止ICMP包的回发，然而在PREROUTING这个点上，目标网卡是不知道的，因此也就不能像标准路由中的fib_validate_source那样设置flowi4的iif，既然rpfilter的目的只是裁决一下反向路径的出口，那么其入口就是无关紧要的了，并且我们知道，本机loopback口的通信是可信的，那么就将反向路径查询中的flowi4的iif设置成loopback即可，然而这还有问题，那就是策略路由的问题了，如果我们不查找策略路由表，就会漏掉在策略路由表中的条目而导致正向包被丢弃，而如果想查找策略路由表，由于我们将iif设置成了loopback，就可能会因为rule的iif不匹配而错过：

static int fib_rule_match(struct fib_rule *rule, struct fib_rules_ops *ops,
                           struct flowi *fl, int flags)
{
         int ret = 0;
         if (rule->iifindex && (rule->iifindex != fl->flowi_iif))
                 goto out;
         if (rule->oifindex && (rule->oifindex != fl->flowi_oif))
                 goto out;
         if ((rule->mark ^ fl->flowi_mark) & rule->mark_mask)
                 goto out;
         ret = ops->match(rule, fl, flags);
out:
         return (rule->flags & FIB_RULE_INVERT) ? !ret : ret;
}

策略路由中的FIB_RULE_INVERT标志和rpfilter中的XT_RPFILTER_INVERT标志是相互独立的两个取反标志，然而代表的含义基本一致，这可以让我们配置出各种组合，也就是说，你可能需要单独的配置一些针对正方向策略路由的反方向策略路由，是不是有点VRF的意思啊！

        rpfilter的核心代码如下：

1.match函数：

static bool rpfilter_mt(const struct sk_buff *skb, struct xt_action_param *par)
{
       const struct xt_rpfilter_info *info;
       const struct iphdr *iph;
       struct flowi4 flow;
       bool invert;

       info = par->matchinfo;
       invert = info->flags & XT_RPFILTER_INVERT;

       if (par->in->flags & IFF_LOOPBACK)
               return true ^ invert;

       iph = ip_hdr(skb);
       if (ipv4_is_multicast(iph->daddr)) {
               if (ipv4_is_zeronet(iph->saddr))
                       return ipv4_is_local_multicast(iph->daddr) ^ invert;
               flow.flowi4_iif = 0;
       } else {
               flow.flowi4_iif = dev_net(par->in)->loopback_dev->ifindex;
       }

       flow.daddr = iph->saddr;
       flow.saddr = rpfilter_get_saddr(iph->daddr);
       flow.flowi4_oif = 0;
       flow.flowi4_mark = info->flags & XT_RPFILTER_VALID_MARK ? skb->mark : 0;
       flow.flowi4_tos = RT_TOS(iph->tos);
       flow.flowi4_scope = RT_SCOPE_UNIVERSE;

       return rpfilter_lookup_reverse(&flow, par->in, info->flags) ^ invert;
}

2.路由查找以及结果判断逻辑：

static bool rpfilter_lookup_reverse(struct flowi4 *fl4,
                               const struct net_device *dev, u8 flags)
{
       struct fib_result res;
       bool dev_match;
       struct net *net = dev_net(dev);
       int ret __maybe_unused;

       if (fib_lookup(net, fl4, &res))
               return false;

       if (res.type != RTN_UNICAST) {
               if (res.type != RTN_LOCAL || !(flags & XT_RPFILTER_ACCEPT_LOCAL))
                       return false;
       }
       dev_match = false;
#ifdef CONFIG_IP_ROUTE_MULTIPATH
       for (ret = 0; ret < res.fi->fib_nhs; ret++) {
               struct fib_nh *nh = &res.fi->fib_nh[ret];

               if (nh->nh_dev == dev) {
                       dev_match = true;
                       break;
               }
       }
#else
       if (FIB_RES_DEV(res) == dev)
               dev_match = true;
#endif
       if (dev_match || flags & XT_RPFILTER_LOOSE)
               return FIB_RES_NH(res).nh_scope <= RT_SCOPE_HOST;
       return dev_match;
}

虽然基于Netfilter的rpfilter比内置的源地址判断更合理，但是由于Linux协议栈以及Netfilter本身的机制，还是有一些副作用的。