xtables_addons 1.46的幾個特性是比較有意思，本文不會列出所有的特性，僅僅針對少數幾個來分析。也不會給出太具體的配置，因為這些配置都可以從manual上得到或者被google到，以下所寫的都是自己的一些想法。
SYSRQ target：
機器死了，特別是置于機架上的網關死了，搬來一個顯示器和USB鍵盤趕緊插上，看看發生了什么，悲劇的是，什么也沒有顯示。畢竟此時可能已經kernel panic了，USB鍵盤識別早就失效了，按下什么鍵都不會觸發顯示器顯示信息。像個刑偵人員丟了犯罪現場一樣的苦悶！記住，即使kernel panic了，中斷還是可以響應的，且網絡處理中斷處在softirq上下文中，因此如果此時網卡收到了數據包，還是會執行諸如PREROUTING上的HOOK function的（如果kernel不是panic得很嚴重的話，大多數情況是這樣~~）。xtables_addons支持了SYSRQ target，可以遠程觸發sysrq，這樣只要有網線插著，并且設置了SYSRQ規則，80%的情況下，插上顯示器就能看到犯罪現場。
??????? 然而SYSRQ target是很危險的，如果有人遠程發送了一個reboot或者shutdown命令，你就哭吧！因此SYSRQ target設置了很多安全參數，比如密碼，摘要等；由于Linux不建議內核偵聽珍貴的TCP端口資源，所以這個target的執行不能依賴任何用戶態執行的服務，故而僅僅可以使用UDP來發送sysrq鍵。
Stateless NAT target
以前，在Linux上配置一個Stateless NAT要累死人，70%人都搞不定這個，因為需要使用tc工具進行超級繁瑣的配置，而Stateful NAT僅僅轉換一個IP地址卻需要動用耗資的ip_conntrack，使得Linux一直不能像Cisco那樣工作。如今xtables_addons支持了Stateless NAT，Linux也可以配置輕量級的NAT了。雖然說是類似Cisco的配置，卻還不一樣。Cisco的ip nat命令可以配置出兩類NAT，一類是基于pool的，另一類是static的，然而它倆并不是并列的關系，區別在于：
pool nat：和inside/outside接口有關，也就是和一個流的方向有關，類似Linux的ip_conntrack，系統中的映射表只有碰到流頭時才開始創建，因此反方向的連接將不會匹配到acl；
static nat：系統直接建立一個映射，因此在兩個方向均可以匹配，類似下面的規則：
ip nat outside source static 1.1.1.1 2.2.2.2
如果有數據包從inside到outside方向，且destination為2.2.2.2（而非規則中指定的source 1.1.1.1），它也會將數據包的destination轉為1.1.1.1，上述規則實際上建立了以下兩個映射：
1>目標為2.2.2.2的，目標轉為1.1.1.1
2>源為1.1.1.1的，源轉為2.2.2.2
對于pool nat則不會這么轉，因為它匹配不到類似下面的acl：
access-list 100 permit 1.1.1.1 0.0.0.0，
系統中既然沒有建立映射，因此反向進來的數據包將不會查找到需要轉換的映射條目。
IPMARK target
該target可以基于進入包的IP地址動態的計算需要打上的mark，而無需在數據包進來之前顯式配置一大堆的mark規則，如果算法精妙的話（無非就是對IP地址，掩碼進行位運算），一條規則可以替代數百條規則。
condition match
condition是一個match，初看它無非就是一個match，一個布爾值，實際上，其精妙之處在于該值可以在procfs中動態配置，比如以下的需求：擁有兩個默認網關，GW1，GW2，如果GW1掉電了，就走GW2，GW1又恢復了，搶占。我們可以配置如下的Policy routing：
ip rule add fwmark 100 tab G1
ip rule add fwmark 200 tab G2
ip route add 0.0.0.0/0 via G1_addr tab G1
ip route add 0.0.0.0/0 via G2_addr tab G2
iptables -t mangle -A PREROUTING -m condition --condition GW1 -j MARK --set-mark 100
iptables -t mangle -A PREROUTING -m condition --condition GW2 -j MARK --set-mark 200
規則以上就完全確定了，接下來就根據GW1/2的狀態來操作/proc/net/nf_condition/GW1和/proc/net/nf_condition/GW2兩個文件了，如果文件中寫入1，那么match匹配，寫入0則不匹配。cron腳本（或者不用cron這種輪詢機制，某種notify機制可能更好，網絡層的監控手段太多了！）可以如下：
if GW1斷電; then
??? ech0 0>/proc/net/nf_condition/GW1;
fi
...
另外如果和GWX是直連的話，還可以通過iface這個新的match來匹配端口狀態。condition技術結合iptables的statistic match，可以很酷的實現基于流的或者基于包的路由負載均衡功能。

總結：iptables非常強大，幾乎可以實現任何功能，你只需要在PREROUTING上掛一個function，就可以實現你自己的協議棧，最后該function返回一個STOLEN即可。iptables強大的表象背后是Netfilter設計的精妙，好像一座城市5個城門，任何數據包進出協議棧都要接受檢查，進來需要檢查，出去也要檢查，協議棧外面就兩條路，一條是鏈路層，另一條是用戶態，在這些關卡上，被哨位劫持是很正常的，他會安排另一條路讓你通過協議棧，或者發現你比較可疑直接扣押或者干掉...NF_STOLEN改為NF_HIJACK豈不更好！

?本文轉自 dog250 51CTO博客，原文鏈接:http://blog.51cto.com/dog250/1268886

總結

以上是生活随笔為你收集整理的iptables之xtables_addons浅度解析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。