iptables，raw表

1)  什麼是raw表？做什麼用的？

iptables有5個鍊:PREROUTING,INPUT,FORWARD,OUTPUT,POSTROUTING,4個表:filter,nat,mangle,raw.

4個表的優先級由高到低的順序為:raw-->mangle-->nat-->filter

舉例來說:如果PRROUTING鍊上,即有mangle表,也有nat表,那麼先由mangle處理,然後由nat表處理

RAW表隻使用在PREROUTING鍊和OUTPUT鍊上,因為優先級最高，進而可以對收到的資料包在連接配接跟蹤前進行處理。一但使用者使用了RAW表,在某個鍊上,RAW表處理完後,将跳過NAT表和 ip_conntrack處理,即不再做位址轉換和資料包的連結跟蹤處理了.

RAW表可以應用在那些不需要做nat的情況下，以提高性能。如大量通路的web伺服器，可以讓80端口不再讓iptables做資料包的連結跟蹤處理，以提高使用者的通路速度。

2)  iptables的資料包的流程是怎樣的？

(流程介紹來源：http://selboo.com.cn/post/721/)

一個資料包到達時,是怎麼依次穿過各個鍊和表的（圖）。 

基本步驟如下： 

1. 資料包到達網絡接口，比如 eth0。 

2. 進入 raw 表的 PREROUTING 鍊，這個鍊的作用是趕在連接配接跟蹤之前處理資料包。 

3. 如果進行了連接配接跟蹤，在此處理。 

4. 進入 mangle 表的 PREROUTING 鍊，在此可以修改資料包，比如 TOS 等。 

5. 進入 nat 表的 PREROUTING 鍊，可以在此做DNAT，但不要做過濾。 

6. 決定路由，看是交給本地主機還是轉發給其它主機。 

到了這裡我們就得分兩種不同的情況進行讨論了，一種情況就是資料包要轉發給其它主機，這時候它會依次經過： 

7. 進入 mangle 表的 FORWARD 鍊，這裡也比較特殊，這是在第一次路由決定之後，在進行最後的路由決定之前，我們仍然可以對資料包進行某些修改。 

8. 進入 filter 表的 FORWARD 鍊，在這裡我們可以對所有轉發的資料包進行過濾。需要注意的是：經過這裡的資料包是轉發的，方向是雙向的。 

9. 進入 mangle 表的 POSTROUTING 鍊，到這裡已經做完了所有的路由決定，但資料包仍然在本地主機，我們還可以進行某些修改。 

10. 進入 nat 表的 POSTROUTING 鍊，在這裡一般都是用來做 SNAT ，不要在這裡進行過濾。 

11. 進入出去的網絡接口。完畢。 

另一種情況是，資料包就是發給本地主機的，那麼它會依次穿過： 

7. 進入 mangle 表的 INPUT 鍊，這裡是在路由之後，交由本地主機之前，我們也可以進行一些相應的修改。 

8. 進入 filter 表的 INPUT 鍊，在這裡我們可以對流入的所有資料包進行過濾，無論它來自哪個網絡接口。 

9. 交給本地主機的應用程式進行處理。 

10. 處理完畢後進行路由決定，看該往那裡發出。 

11. 進入 raw 表的 OUTPUT 鍊，這裡是在連接配接跟蹤處理本地的資料包之前。 

12. 連接配接跟蹤對本地的資料包進行處理。 

13. 進入 mangle 表的 OUTPUT 鍊，在這裡我們可以修改資料包，但不要做過濾。 

14. 進入 nat 表的 OUTPUT 鍊，可以對防火牆自己發出的資料做 NAT 。 

15. 再次進行路由決定。 

16. 進入 filter 表的 OUTPUT 鍊，可以對本地出去的資料包進行過濾。 

17. 進入 mangle 表的 POSTROUTING 鍊，同上一種情況的第9步。注意，這裡不光對經過防火牆的資料包進行處理，還對防火牆自己産生的資料包進行處理。

18. 進入 nat 表的 POSTROUTING 鍊，同上一種情況的第10步。 

19. 進入出去的網絡接口。完畢。

3)  iptables raw表的使用

增加raw表，在其他表處理之前，-j NOTRACK跳過其它表處理

狀态除了以前的四個還增加了一個UNTRACKED

例如：

可以使用 “NOTRACK” target 允許規則指定80端口的包不進傳入連結接跟蹤/NAT子系統

iptables -t raw -A PREROUTING -d 1.2.3.4 -p tcp --dport 80 -j NOTRACK

iptables -t raw -A PREROUTING -s 1.2.3.4 -p tcp --sport 80 -j NOTRACK

iptables -A FORWARD -m state --state UNTRACKED -j ACCEPT

4) 解決ip_conntrack: table full, dropping packet的問題

在啟用了iptables web伺服器上，流量高的時候經常會出現下面的錯誤：

ip_conntrack: table full, dropping packet

這個問題的原因是由于web伺服器收到了大量的連接配接，在啟用了iptables的情況下，iptables會把所有的連接配接都做連結跟蹤處理，這樣iptables就會有一個連結跟蹤表，當這個表滿的時候，就會出現上面的錯誤。

iptables的連結跟蹤表最大容量為/proc/sys/net/ipv4/ip_conntrack_max，連結碰到各種狀态的逾時後就會從表中删除。

是以解決方法一般有兩個：

(1) 加大 ip_conntrack_max 值

vi /etc/sysctl.conf

net.ipv4.ip_conntrack_max = 393216

net.ipv4.netfilter.ip_conntrack_max = 393216

(2): 降低 ip_conntrack timeout時間

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 300

net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120

net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60

net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120

上面兩種方法打個比喻就是燒水水開的時候，換一個大鍋。一般情況下都可以解決問題，但是在極端情況下，還是不夠用，怎麼辦？

這樣就得反其道而行，用釜底抽薪的辦法。iptables的raw表是不做資料包的連結跟蹤處理的，我們就把那些連接配接量非常大的連結加入到iptables raw表。

如一台web伺服器可以這樣：

5)  iptables raw表的效果測試

我們在一台web server上做測試，先不使用raw表，觀察連結跟蹤表(/proc/net/ip_conntrack)的大小：

先看下iptables配置：

cat /etc/sysconfig/iptables

# Generated by iptables-save v1.3.5 on Wed Aug 18 10:10:52 2010

*filter

:INPUT ACCEPT [0:0]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [104076:12500201]

:RH-Firewall-1-INPUT - [0:0]

-A INPUT -j RH-Firewall-1-INPUT

-A FORWARD -j RH-Firewall-1-INPUT

-A RH-Firewall-1-INPUT -i lo -j ACCEPT

-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT

-A RH-Firewall-1-INPUT -p esp -j ACCEPT

-A RH-Firewall-1-INPUT -p ah -j ACCEPT

-A RH-Firewall-1-INPUT -d 224.0.0.251 -p udp -m udp --dport 5353 -j ACCEPT

-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT

-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT

-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited

COMMIT

# Completed on Wed Aug 18 10:10:52 2010

在另一台機器上用ab測試：

ab -c 1000 -n 5000 http://192.168.20.26/index.html

在web server上檢視連結跟蹤表(/proc/net/ip_conntrack)的大小：

[root@mongo html]# wc -l /proc/net/ip_conntrack

5153 /proc/net/ip_conntrack

可以看到跟蹤表内有5153個連結，再大一些的壓力可能就要報ip_conntrack: table full, dropping packet的錯誤了。

下面我們啟用raw表：

先更新iptables：

[root@mongo html]# cat /etc/sysconfig/iptables

-A INPUT -j RH-Firewall-1-INPUT 

-A FORWARD -j RH-Firewall-1-INPUT 

-A RH-Firewall-1-INPUT -i lo -j ACCEPT 

-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT 

-A RH-Firewall-1-INPUT -p esp -j ACCEPT 

-A RH-Firewall-1-INPUT -p ah -j ACCEPT 

-A RH-Firewall-1-INPUT -d 224.0.0.251 -p udp -m udp --dport 5353 -j ACCEPT 

-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT 

-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT 

-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED,UNTRACKED -j ACCEPT

-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 

-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT 

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited 

*raw

:PREROUTING ACCEPT [116163:9327716]

-A PREROUTING -p tcp -m tcp --dport 80 -j NOTRACK 

-A OUTPUT -p tcp -m tcp --sport 80 -j NOTRACK 

紅色部分是新增的。

重新開機iptables：

service iptables restart

可以用iptables指令檢視是否啟用成功了：

[root@mongo html]# iptables -t raw -L -n

Chain PREROUTING (policy ACCEPT)

target     prot opt source               destination         

NOTRACK    tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80 

Chain OUTPUT (policy ACCEPT)

NOTRACK    tcp  --  0.0.0.0/0            0.0.0.0/0           tcp spt:80 

然後再用ab測試：

檢視連結跟蹤表(/proc/net/ip_conntrack)的大小：

1 /proc/net/ip_conntrack

跟蹤表内隻跟蹤了一個連結了。

[root@mongo html]# cat /proc/net/ip_conntrack  

tcp      6 431999 ESTABLISHED src=192.168.20.26 dst=192.168.20.10 sport=22 dport=50088 packets=85 bytes=10200 src=192.168.20.10 dst=192.168.20.26 sport=50088 dport=22 packets=92 bytes=6832 [ASSURED] mark=0 secmark=0 use=1

可以看到iptables已經不跟蹤進出端口為80的連結了。測試結果表明用iptables的raw表可以完美解決ip_conntrack: table full, dropping packet的問題。