iptableのconntrackモジュールはいつパケットの状態を追跡しますか？

Aug 15 2020

最初に状態を保存する必要があります。私が使用した古いBSDファイアウォールでは、IPFWという名前だったと思います。以前は、「パケットの送信状態を追跡する」というルールを設定していました。これは、インターフェイスの送信方向に配置されていました。次に、アウトバウンド方向のルールによって作成された状態に対してそれらをチェックするインバウンド方向の別のルール。したがって、以前は2つのルールがありました。（1）状態テーブルにデータを入力するため、これはアウトバウンド方向であり、（2）状態テーブルをルックアップするため、これはインバウンド方向でした。

しかし、connntrackを使用すると、次のようなINPUTチェーンに適用されます。

iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

これは私に不思議に思います、そのステートメントは実際に何をしているのですか？

状態テーブルに情報を入力することで、そのルールに一致するパケットの追跡を開始すると言っているのでしょうか。
それとも、すでに状態情報があり、それに基づいてインバウンドメッセージに対して動作するということですか？（たとえば、以前に受け入れられた接続に属していた場合は受け入れますか？）。しかし、この場合、statesテーブルはどこに入力されましたか？それはどのルールですか？それとも、ルールがなく暗黙的ですか？

回答

5 A.B Aug 15 2020 at 21:43

Netfilterとconntrackの紹介プレゼンテーション

まず、NetfilterとGeneralNetworkingのパケットフローに関する必須の回路図：

Netfilterは、ネットワークスタックの残りの部分に自分自身を挿入するパケットフィルタリングフレームワークです（「ルーティング決定」およびその他の白い丸いエッジのボックスパーツで表されます）。Netfilterは、他のサブシステムと「クライアント」にフックとAPIを提供します。これらの部分の中には、conntrack（接続トラッカー）とiptables（またはnftables）があります。Netfilterとconntrackの分離はかなりあいまいです。conntrackはNetfilterの統合された部分と見なすことができます。

パケットが通過するさまざまなステップを説明する回路図では、ある時点（raw / PREROUTINGとmangle / PREROUTINGの間、またはraw / OUTPUTとmangle / OUTPUTの間）でパケットがconntrackを通過することがわかります。

この時点で、conntrackは独自のルックアップテーブル（カーネルメモリに保持されているミニルックアップデータベース）を検索します。

このパケットの特性が見つからない場合（およびrawテーブルでUNTRACKEDと宣言されていない場合）、新しいconntrack双方向タプルエントリ（プロトコル、特定のファミリおよびプロトコル情報：初期送信元とポート、初期宛先とポート、応答送信元とポート、フローを説明する応答の宛先とポート（NATまたはICMPのエコー要求に一致するエコー応答などの奇妙なプロトコルが関係しない限り、通常は逆になります）は、状態NEWで作成されます。
前のエントリと（任意の方向で）一致し、このフローの状態と互換性がある場合、フローの状態が変更される可能性があります（たとえば、以前はそうでなかった場合は、NEWからESTABLISHEDに変更します）。
何らかの特定の理由で、パケットがその特性を持っているにもかかわらず既存のフローと一致しない場合（たとえば、再送信がすでに正常に開始された後に受信された遅延TCPパケット、したがってシーケンスとSACK値に関してウィンドウ外にある）パケットにはINVALIDのタグが付けられます。
RELATEDのような他のいくつかのケースがあります。これは、フロー自体の一部ではなく、他の既存の（つまりデータベース内の）フローに関連付けることができる新しいフローに関連するパケットに関するものです。2つの例は、パケットの受信から作成されたICMPエラー（例：UDPポートに到達できません）nf_conntrack_ftp、またはconntrackサブシステムへのプラグインであるカーネルモジュールなどの特別なプロトコルヘルパーが、パケットが関連付けられた個別のデータフローの一部であることを検出した場合です。 FTPコマンドPASV / EPSVまたはPORT / EPRTをコマンドフロー（ポート21）で実行します。

質問への対応

このすべてが言われている、ここにあなたの2つの弾丸への答えがあります：

メインネットワークの名前空間では、conntrackは、そのモジュール（関連する可能性のあるプロトコル固有のサブモジュールを含む）がロードされるとすぐに接続の追跡を開始します。非初期ネットワーク名前空間（コンテナ...）の場合、これには、他のサブシステムがそれを参照する必要もあります（OPのiptablesのconntrackモジュールや、conntrack後で説明するコマンドの1回の使用など）。これはデフォルトであり、conntrackサブシステムがこのパケットを追跡しないようにする前に、パケットをUNTRACKEDとして明確にマークする必要があります。Linuxでは、追跡が必要ないケースはごくわずかですが、もちろんステートフルファイアウォールとステートフル/ダイナミックNATは利用できなくなります（そもそもUNTRACKEDを使用する必要があるかもしれないステレスNATは、引き続き利用できます。行って、ではないとのiptables。TCまたはnftables缶）。conntrackが一部のパケットを処理することを回避するために、この種のiptablesルールを使用できます（例：ポート80 / tcp）：
```
iptables -t raw -A PREROUTING -p tcp --dport 80 -j CT --notrack
iptables -t raw -A OUTPUT -p tcp --sport 80 -j CT --notrack
```
パケットがフィルター/入力を通過してこのルールに到達したとき：
```
 iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
```
iptablesのの特定のカーネルモジュールは、xt_conntrack照会接続追跡の（様々な関連するカーネルモジュールによって処理サブシステムnf_conntrack*）とそのルックアップデータベースにおけるこのパケットの状態について尋ねます。答えが「RELATEDまたは」の場合ESTABLISHED、パケットは一致し、ACCEPT判定に進みます。実際には、ルックアップが最初に行われたとき（通常はconntrackによって）、結果はすでにパケットにキャッシュされているため、これは安価な「ルックアップ」です。したがって、これは、以前にすでに受け入れられたフローを処理するための一般的なルールです。これらのフローは、最初は明示的に言及しているルール、または単に言及していないがこの一般的なルールの後に配置されているルールで受け入れることができます（ただし、通常は削除する前に削除する必要があるINVALID状態に注意してください）。-m conntrack --ctstate NEW
箇条書きの追加：着信パケットと発信パケットの処理は、PREROUTINGとOUTPUTの間で非常に対称的です（対称に見えなくても）：PREROUTINGとOUTPUTのconntrackインターフェイス（および他のいくつかの場所では、NATはconntrackを操作します。ただし、状態NEWの最初のパケットがiptablesのnatテーブルをトラバースします）。これは、IPFWについて書いた説明とは少し異なる場合があります。アプリケーションを実行しているサーバーが発信フローも制限している場合、すでに受け入れられている着信トラフィックの発信応答パケットを通過させるために、フィルター/出力とフィルター/入力の両方でこれと同じ汎用iptablesルールが必要になる可能性があります。

追加情報

対話するための専用ツールがあります接続追跡用のサブシステムのルックアップテーブル接続追跡・ツールが。

conntrack：conntrackによって処理されるルックアップテーブルの内容をクエリ、削除、または更新します。

いくつかの例。

追跡されたすべてのエントリ（追加のフィルターがないと大きくなる可能性があります）を次のように一覧表示できます。
```
conntrack -L
```
システムがNATを実行している場合（たとえば、プライベートLANの前にあるルーター、またはVMとコンテナーを実行している場合）、を使用するか--any-nat、--src-natまたは--dst-nat応答のみを表示することができます。すべてのNAT、すべての送信元NAT（マスカレード）、またはすべての宛先NAT（通常は転送ポート用）：

conntrackイベントのリアルタイム監視：
```
conntrack -E
```
conntrackd：（conntrack）フローアカウンティングと統計、または高可用性ステートフルファイアウォールクラスター状態の同期を2つの主な目的とするデーモン。

2 TeroKilkanen Aug 15 2020 at 20:46

接続追跡はNetfilterの独立した機能であり、IPTablesで構成されていません。

写真ではconntrack、INPUTパスに2つのステップがあり、OUTPUTパスに1つのステップがあります。これらの手順では、個々のパケットを接続追跡テーブルで追跡されている既存の接続に関連付けるか、テーブルに新しい接続追跡エントリを作成します。

Conntrack機能はLinuxカーネルモジュールであり、多くの場合、デフォルト構成でカーネルに含まれています。

Conntrackの動作は、net.netfilter.nf_conntracksysctl値を調整することで調整できます。

2番目の選択肢は何が起こるかです。状態情報はConntrack関数によって記録され、IPTablesルールは単にConntrackテーブルを参照して情報を取得します。