前言
在之前的學習中對iptables的語法有了一定的了解，對於在不太複雜的網路結構中的一些簡單的語句可以進行簡單的分析了。當然，如果對語句和相關架構不清楚的可以參考：（linux防火牆之netfilter）以及（iptables之語法初步）和（linux防火牆之牛刀小試）這些文中詳細介紹了linux下iptables防火牆的基礎情況。
測試
當你已經完全了解了iptables的語法規則後，那麼看看下面的幾個測驗題你能否通過，先介紹測試環境中的網路情況，如下圖所示：
問題一
如果11（指11.0.0.200下同）做以下規則：
iptables
-fiptables
-p input drop
iptables
-p output accept
iptables
-p forward accept
iptables
-l
當173（指173.16.0.200下同）的防火牆設定以下規則允許icmp包進入（允許其它機器ping它）時，
iptables
-fiptables
-p input drop
iptables
-p output accept
iptables
-p forward accept
iptables –t filter –a input –p icmp –j accept
iptables
-l
那麼在pc機11上執行
ping 173.16.0.200
此時機器能ping通嗎？為什麼？如果在173.16.0.200上啟用ssh服務端應用程式，同時關閉173.16.0.200防火牆服務；那麼在11.0.0.200上執行ssh客戶端的服務能夠正常連到173.16.0.200這台機器嗎？
結果一
不管答案是怎麼樣的，我們還是看看實際情況是怎麼樣的吧（這裡只給出ping測試的截圖，ssh的測試可以自行參考實現）。
如上圖所示，在11.0.0.200這台機上是沒辦法ping通173.16.0.200的。那麼是不是意味著173.16.0.200拒絕了11.0.0.200的ping請求呢，我們可以檢視173.16.0.200在被ping時的實際連線，使用以下命令：
netstat-s|
more
結果如下圖所示。
從上圖可知，對於173.16.0.200這台機來說它是接收到了icmp的包的，但11.0.0.200提示無法ping通。那麼問題出在哪呢？同樣的ssh的應用也無法連線。
答案
首先，假設173.16.0.200機器上啟動ssh服務，並且正常服務在tcp 22號埠的位置，接著在11.0.0.200上啟動ssh客戶端，假設客戶端使用的是tcp 12345號埠，然後，11.0.0.200使用tcp 12345向173.16.0.200的tcp 22號埠發出服務請求，這個請求包一定可以成功送到173.16.0.200這台機上，因為11.0.0.200的output沒有限制，只是此時當173.16.0.200收到這個請求包時就會以tcp 22回應11.0.0.200在tcp 12345上的請求，那麼，11.0.0.200的input策略允許這個包通過tcp 12345進來嗎？如果input沒有開放這個埠那麼這個請求就無法在11.0.0.200上響應。ping的情況也是如此。如下圖所示。
也許有人會認為直接在input中把tcp 12345開啟不就可以了！但實際情況是：客戶端的應用程式所使用的埠多為動態埠，所以不可能事先預知客戶端的應用程式會使用哪乙個埠，也就不可能預先把客戶端的埠開好等客戶端使用。
在以前的ipchains防火牆時代，要解決這種問題的做法是將1024以上的埠都開啟，只要確定客戶端應用程式使用的埠大於1024就行。這種解決辦法當然也適用現在的netfilter/iptables防火牆，但這樣做就無法確保安全。在netfilter/iptables時代，可以通過啟用state（狀態）模決來解決這樣的問題，它主要由xt_state.ko模組提供。
需要注意的是在標準和tcp/ip規範中，連線狀態分為12種，詳情可以參考rfc文件（而iptables中的連線狀態只有4種，分別是established、new、related、invalid。不能將tcp/ip規範中的連線狀態和這個混在一起，因為這個兩個完全不同的定義。例如，在tcp/ip規範描述下，udp和icmp封包是沒有連線狀態的，但在state模組的描述下，任何包都是有連線狀態的。
established
以下圖為例解決上面所提出的問題。established狀態與tcp、udp及icmp協議的關係解釋也用下圖描述。假設圖右邊為一台設定有單機防火牆的主機，並且在這台主機上分別執行以下3個實驗。
tcp包相關：先在防火牆主機執行ssh客戶端，對網路上的ssh服務提出服務請求，而這時送出的第乙個資料報就是服務請求資料報，如果這個資料報能夠「成功穿越防火牆」，那麼接下來①②方向的所有資料報狀態都會是established。
udp包相關：在防火牆主機上以firefox應用程式來瀏覽網頁，而瀏覽網頁的動作需要dns解析才能順利瀏覽到網頁，因此，firefox會送出乙個udp的資料報給dns伺服器，以請求網域名稱解析服務；如果這個資料報能夠「成功穿越防火牆」，那麼接下來③④方向的所有資料報狀態都會是established。
icmp包相關：在防火牆主機上以ping命令來檢測網路上其它主機是，ping送出的第乙個icmp資料報這個資料報能夠「成功穿越防火牆」，那麼接下來⑤⑥方向的所有資料報狀態都會是established。
所以，只要資料報能成功穿越防火牆，那麼之後的所有封包（包含反向的所有資料報）狀態都會是established。
解法一
出現上面的問題後，只需要在11.0.0.200這台機器上開放established狀態的連線就可以解決問題一了。如下面的命令所示：
iptables
-a input
-m state
--state established
-j accept
iptables
-l
未完待續中……
iptables中state模組的連線狀態
前言 在之前的學習中對iptables的語法有了一定的了解，對於在不太複雜的網路結構中的一些簡單的語句可以進行簡單的分析了。當然，如果對語句和相關架構不清楚的可以參考 linux防火牆之netfilter 以及 iptables之語法初步 和 linux防火牆之牛刀小試 這些文中詳細介紹了linux...
iptables配置FTP的主動和被動模式
iptables配置ftp的主動和被動模式 ftp協議有兩種工作方式 port方式和pasv方式，中文意思為主動式和被動式。port模式 ftp server tcp 21 client dynamic ftp server tcp 20 client dynamic pasv模式 ftp serv...
Flex中State和ViewStack的區別
最近在乙個flex遺留系統上工作，flex部分承擔的主要是使用者註冊的業務。使用者註冊需要多個步驟，比如填寫完基本資訊，通過驗證之後，來到聯絡資訊填寫表單，等等。步驟之間的切換通過改變當前頁面的state來實現 state控制不同控制項的顯示 掩藏等。直覺不應該這麼實現，今天看了 flex 3權威指...