Linux的rp_filter與策略路由

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的虛擬路由轉發的實現不是很明顯，那還奢求什麼呢？ --------------------- 本文來自 dog250 的CSDN 博客 ，全文地址請點擊：https://blog.csdn.net/dog250/article/details/7947705?utm_source=copy