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的虛擬路由**的實現不是很明顯，那還奢求什麼呢？
linux 與 的用法
可以把乙個命令的標準輸出插在命令列中的任何位置。在shell中有兩個實現方法 反引號 和 echo echo hostname 反引號實現 已經把 轉義成了特殊字元 列印出 hostname的值 echo echo hostname 並沒有被轉義 列印出的是 hostname echo echo h...
Linux與Windows的比較
linux的操作對照複雜,windows的對照簡單.linux速度對照快,安然性比windows好 然則有很多軟體只能在windows裡執行與linux相容的軟體正在斥地中.linux合用在收集方面.1 linux和windows一樣，都是完全的多工作業系統。它們支援同樣的使用者介面 網路和安全性。...
Linux的時間與時區
首先要說明的是我的系統是fedora，其他系統可能不完全相同。1，時間儲存在硬體實時鐘 rtc 中，rtc由主機板電池供電，即使關斷電源也不會造成時間丟失。2，系統啟動時從rtc獲取時間，這個步驟在rc.sysinit中做 a，首先從 etc sysconfig clock中獲取rtc相關引數utc...