iptables rawテーブルを使用してip_conntrackを解決します：テーブルがいっぱいで、パケットのドロップの問題

Use Iptables Raw Table Solve Ip_conntrack

1）生のテーブルとは何ですか？これは何のため？

iptablesには5つのチェーンがあります：PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTING、4つのテーブル：filter、nat、mangle、raw。

4つのテーブルの優先順位は高いものから低いものへです：raw-> mangle-> nat-> filter

例：PRROUTINGチェーンにマングルテーブルがある場合、NATテーブルもあり、マングルによって処理されてから、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.マングルテーブルのPREROUTINGチェーンに移動します。ここで、TOSなどのデータパッケージを変更できます。
5. natテーブルのPREROUTINGチェーンを入力します。ここで、DNATを実行できますが、フィルタリングは実行しないでください。
6.ルートを決定して、ローカルホストに渡されるのか、他のホストに転送されるのかを確認します。

ここでは、2つの異なる状況について説明します。1つのケースは、パケットが他のホストに転送され、順番に渡される場合です。
7.マングルテーブルのFORWARDチェーンを入力します。これもここで特別です。最初のルーティング決定の後でも、最終的なルーティング決定を行う前に、パケットに対していくつかのデータを実行できます。いくつかの変更。
8.フィルターテーブルのFORWARDチェーンに移動します。ここで、転送されたすべてのパケットをフィルター処理できます。ここを通過するパケットは転送され、方向は双方向であることに注意してください。
9.すべてのルーティング決定が行われたマングルテーブルのPOSTROUTINGチェーンに移動しますが、パケットはまだローカルホスト上にあり、いくつかの変更を加えることができます。
10.ここでSNATを実行するために一般的に使用されるNATテーブルのPOSTROUTINGチェーンを入力します。ここでフィルタリングしないでください。
11.発信ネットワークインターフェースを入力します。終了しました。

別のケースでは、パケットはローカルホストに送信され、次に通過します。
7.マングルテーブルのINPUTチェーンを入力します。ここでは、ルートの後、ローカルホストの前に、対応する変更を加えることもできます。
8.フィルタテーブルのINPUTチェーンに移動します。ここでは、どのネットワークインターフェイスから送信されたかに関係なく、すべての着信パケットをフィルタリングできます。
9.アプリケーションを処理のためにローカルホストに処理します。
10.処理後、ルーティングを決定し、送信先を確認します。
11.接続追跡がローカルパケットを処理する前にあるrawテーブルのOUTPUTチェーンを入力します。
12.接続追跡はローカルパケットを処理します。
13.マングルテーブルのOUTPUTチェーンに移動します。ここで、パケットを変更できますが、フィルタリングはしません。
14.ファイアウォール自体によって送信されたデータをNATするために、NATテーブルのOUTPUTチェーンを入力します。
15.ルーティングの決定を再度行います。
16.フィルターテーブルのOUTPUTチェーンを入力して、発信パケットをフィルターで除外します。
17.前のケースのステップ9と同様に、マングルテーブルのPOSTROUTINGチェーンに移動します。ここで、ファイアウォールを通過するパケットだけでなく、ファイアウォール自体によって生成されたパケットも処理されることに注意してください。
18.前のケースのステップ10と同様に、NATテーブルのPOSTROUTINGチェーンに移動します。
19.発信ネットワークインターフェイスを入力します。終了しました。


3）iptablesrawテーブルの使用

生のテーブルを追加します。-jNOTRACKは、他のテーブルが処理される前に他のテーブルの処理をスキップします
州は、前の4つに加えてUNTRACKEDを追加します。

例えば：
'NOTRACK'ターゲットを使用して、ポート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の問題を解決します：テーブルがいっぱいで、パケットがドロップします


有効になっているiptablesWebサーバーでは、トラフィックが多いときに次のエラーが頻繁に発生します。

ip_conntrack：テーブルがいっぱいで、パケットをドロップしています


この問題の理由は、Webサーバーが多くの接続を受信するため、iptablesが有効になっている場合、iptablesはリンク追跡のすべてのリンクを実行するため、iptablesにはリンク追跡テーブルがあります。テーブルがいっぱいになると、上記のエラーが発生します。現れる。

iptablesのリンク追跡テーブルの最大容量は/ proc / sys / net / ipv4 / ip_conntrack_maxであり、さまざまな状態のタイムアウト後にリンクがテーブルから削除されます。

したがって、2つの解決策があります。

（1）ip_conntrack_max値を増やします

vi /etc/sysctl.conf

net.ipv4.ip_conntrack_max = 393216
net.ipv4.netfilter.ip_conntrack_max = 393216


（2）：ip_conntrackのタイムアウト時間を短縮します

vi /etc/sysctl.conf

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


上記の2つの方法は類似しています。水が沸騰したら、大きな鍋に変えます。通常の状況では問題は解決できますが、極端な場合はそれでも十分ではありません。私は何をすべきか？

このように、ボトムアップ方式を使用して、反対方向に進む必要があります。 iptablesのrawテーブルは、パケットのリンク追跡には使用されません。非常に大きな接続を持つリンクをiptablesrawテーブルに追加します。

Webサーバーがこれを行うことができるように：

iptables -t raw -A PREROUTING -d 1.2.3.4 -p tcp --dport 80 -j NOTRACK
iptables -A FORWARD -m state --state UNTRACKED -j ACCEPT


5）iptablesrawテーブル効果テスト

Webサーバーでテストを行います。最初に生のテーブルを使用せず、リンク追跡テーブル（/ proc / net / ip_conntrack）のサイズを観察します。

まず、iptablesの構成を確認します。
cat / etc / sysconfig / iptables

＃iptablesによって生成-2010年8月18日水曜日にv1.3.5を保存10:10:52
*フィルタ
：INPUT ACCEPT [0：0]
：FORWARD ACCEPT [0：0]
：OUTPUT ACCEPT [104076：12500201]
：RH-ファイアウォール-1-入力-[0：0]
-A入力-jRH-ファイアウォール-1-入力
-フォワード-jRH-ファイアウォール-1-入力
-ARH-ファイアウォール-1-INPUT-i lo -j ACCEPT
-ARH-ファイアウォール-1-INPUT-p icmp -m icmp --icmp-type any -j ACCEPT
-ARH-ファイアウォール-1-INPUT-p esp -j ACCEPT
-ARH-ファイアウォール-1-入力-pah -j ACCEPT
-ARH-ファイアウォール-1-入力-d224.0.0.251 -p udp -m udp --dport 5353 -j ACCEPT
-ARH-ファイアウォール-1-INPUT-p udp -m udp --dport 631 -j ACCEPT
-ARH-ファイアウォール-1-INPUT-p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state RELATED、ESTABLISHED -j ACCEPT
-ARH-ファイアウォール-1-INPUT-p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-ARH-ファイアウォール-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
コミット
＃2010年8月18日水曜日10:10:52に完了

別のマシンでabを使用してテストします。

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

Webサーバー上のリンク追跡テーブル（/ proc / net / ip_conntrack）のサイズを表示します。

[root @ xxxxx html] ＃wc -l / proc / net / ip_conntrack
5153 / proc / net / ip_conntrack

追跡テーブルに5153個のリンクがあることがわかります。大きい方の圧力は、ip_conntrack：table full、droppingpacketエラーとして報告される場合があります。


以下では、生のテーブルを有効にします。

最初にiptablesを更新します。

[root @ xxxxx html] ＃cat / etc / sysconfig / iptables
＃iptablesによって生成-2010年8月18日水曜日にv1.3.5を保存10:10:52
*フィルタ
：INPUT ACCEPT [0：0]
：FORWARD ACCEPT [0：0]
：OUTPUT ACCEPT [104076：12500201]
：RH-ファイアウォール-1-入力-[0：0]
-A入力-jRH-ファイアウォール-1-入力
-フォワード-jRH-ファイアウォール-1-入力
-ARH-ファイアウォール-1-INPUT-i lo -j ACCEPT
-ARH-ファイアウォール-1-INPUT-p icmp -m icmp --icmp-type any -j ACCEPT
-ARH-ファイアウォール-1-INPUT-p esp -j ACCEPT
-ARH-ファイアウォール-1-入力-pah -j ACCEPT
-ARH-ファイアウォール-1-入力-d224.0.0.251 -p udp -m udp --dport 5353 -j ACCEPT
-ARH-ファイアウォール-1-INPUT-p udp -m udp --dport 631 -j ACCEPT
-ARH-ファイアウォール-1-INPUT-p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state RELATED、ESTABLISHED、UNTRACKED -j ACCEPT
-ARH-ファイアウォール-1-INPUT-p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-ARH-ファイアウォール-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
コミット
＃2010年8月18日水曜日10:10:52に完了
＃iptablesによって生成-2010年8月18日水曜日にv1.3.5を保存10:10:52
*生
：PREROUTING ACCEPT [116163：9327716]
：OUTPUT ACCEPT [104076：12500201]
-事前設定-ptcp -m tcp --dport 80 -j NOTRACK
-A OUTPUT -p tcp -m tcp --sport 80 -j NOTRACK
コミット
＃2010年8月18日水曜日10:10:52に完了

赤い部分は新品です。

iptablesを再起動します。

service iptables restart

iptablesコマンドを使用して、正常に有効になっているかどうかを確認できます。

[root @ xxxxx html] ＃iptables -t raw -L -n
チェーンの事前ルーティング（ポリシーACCEPT）
ターゲットプロトオプトソース宛先
NOTRACK tcp-0.0.0.0 / 0 0.0.0.0/0 tcp dpt：80

チェーン出力（ポリシーACCEPT）
ターゲットプロトオプトソース宛先
NOTRACK tcp-0.0.0.0 / 0 0.0.0.0/0 tcp spt：80

次に、abでテストします。

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

リンク追跡テーブル（/ proc / net / ip_conntrack）のサイズを表示します。

[root @ xxxxx html] ＃wc -l / proc / net / ip_conntrack
1 / proc / net / ip_conntrack

追跡テーブルでは、1つのリンクのみが追跡されました。

[root @ xxxxx html] ＃cat / proc / net / ip_conntrack
tcp 6 431999 ESTABLISHED src = 192.168.20.26 dst = 192.168.20.10 sport = 22 dport = 50088パケット= 85バイト= 10200src = 192.168.20.10 dst = 192.168.20.26 sport = 50088 dport = 22パケット= 92バイト= 6832 [ASSURED ] mark = 0 secmark = 0 use = 1

iptablesがポート80の入出力のリンクを追跡していないことがわかります。テスト結果は、iptables rawテーブルがip_conntrackの問題を完全に解決できることを示しています：テーブルがいっぱいで、パケットがドロップしています。