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的虛擬路由轉發的實現不是很明顯，那還奢求什麼呢？
