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 51CTO部落格，原文連結:http://blog.51cto.com/dog250/1268930