Linux的rp_filter用于实现反向过滤技术，也即uRPF，它验证反向数据包的流向，以避免伪装IP攻击，但是它和Linux的策略路由却很容易发生冲突，其本质原因在于，uRPF技术强制规定了一个反向包的“方向”，而实际的路由是没有方向的。策略路由并没有错，错就错在uRPF增加了一个路由概念本身并没有且从不考虑的约束。典型的例子如下。
0.基本环境
内网口：eth0
外网口1：eth1
外网口2：eth2
1.配置一个内网服务器到外网返回包的策略路由
ip rule add fwmark 100 iif eth0 table lb1
ip rule add fwmark 200 iif eth0 table lb2
iptables -t mangle -A PREROUTING -i eth0 -p tcp --sport 123 -j 打上mark 100
iptables -t mangle -A PREROUTING -i eth0 -p tcp --sport 456 -j 打上mark 200
ip route add default via $R1 table lb1
ip route add default via $R2 table lb2
2.配置一个任意客户端到内网服务器的目标地址转换
iptables -t nat -A PREROUTING -p tcp --dport 123 -j DNAT --to-source $内网123服务
iptables -t nat -A PREROUTING -p tcp --dport 456 -j DNAT --to-source $内网456服务
3.以上配置的问题
如果Linux主机的对应网卡的rp_filter配置为1，以上的DNAT是不会成功的，因为在路由之后会验证反向路径，做法就是源IP和目标IP对调，查找到的出口必须是正向包进来的网卡。结果是什么呢？
反向路径的路由在策略路由中，而策略路由的查找条件是从内网进入且带有mark，对于正向路径，uRPF检查时的反向查找元素是简单反转源和目标地址构建的，因此不符合策略路由的查找条件，进而导致uRPF的失败。此时你就算查看/proc/net/ip_connrack文件或者用conntrack工具查看都不会得到任何信息，因为数据包是在in-process-out的中间，即process时被丢弃的，ip_conntrack不会被confirm，因此不会留下任何流轨迹。
4.解决方法
之一.想办法让uRPF查到策略路由；
之二.在main路由表或者default(更好一些)中配置专门为uRPF而设置的路由
之三.既然Linux的虚拟路由转发的实现不是很明显，那还奢求什么呢？