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

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

まず、状態を保存する必要があります。私が使用していた古い BSD ファイアウォール (IPFW という名前だったと思います) では、「送信パケットの状態を追跡する」というルールを設定していました。これは、インターフェイスの送信方向に配置されていました。次に、受信方向の別のルールで、送信方向のルールによって作成された状態と照合していました。つまり、以前は 2 つのルールがありました。(1) 状態テーブルにデータを入力するルール (送信方向)、(2) 状態テーブルを検索するルール (受信方向)。

しかし、connntrack では、次のルールのように、INPUT チェーンに適用されていることがわかります。

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

こうなると、この声明は実際何をしているのだろうかと疑問に思います。

  • 状態テーブルに情報を入れることで、そのルールに一致するパケットの追跡を開始するということでしょうか?
  • それとも、すでに状態情報を持っていて、それに基づいて受信メッセージに対して行動するつもりだと言っているのでしょうか? (たとえば、以前に承認された接続に属していた場合は受け入れるなど)。しかし、この場合、状態テーブルはどこで入力されたのでしょうか? どのルールで入力されるのでしょうか? それとも、ルールがなく暗黙的でしょうか?

答え1

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

まず、Netfilter と一般的なネットワークにおけるパケット フローに関する必須の図を示します。

Netfilter と一般的なネットワークにおけるパケットフロー

Netfilterは、ネットワークスタックの残りの部分(「ルーティング決定」と他の白い丸い角のボックス部分で表されます)に挿入されるパケットフィルタリングフレームワークです。Netfilterは、他のサブシステムと「クライアント」用のフックとAPIを提供します。これらの部分には、接続トラック(接続トラッカー)とiptables(またはnftables)。Netfilterと接続トラックかなり曖昧です。接続トラックNetfilter の統合された一部として。

パケットが通過するさまざまなステップを説明する図では、ある時点(raw/PREROUTINGとmangle/PREROUTINGの間、またはraw/OUTPUTとmangle/OUTPUTの間)でパケットが通過することがわかります。接続トラック

この時点で、接続トラック独自のルックアップ テーブル (カーネル メモリに保存されるミニ ルックアップ データベース) を検索します。

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

質問への回答

以上のことを踏まえて、あなたの 2 つの質問に対する答えは次のとおりです。

  • メインネットワーク名前空間内接続トラックモジュール(関連するプロトコル固有のサブモジュールを含む)がロードされるとすぐに、接続の追跡を開始します。非初期ネットワーク名前空間(コンテナなど)の場合、他のサブシステムがそれを参照する必要もあります(OPのiptablesのconntrackモジュールまたはconntrack後述のコマンドを一度だけ使用して)これはデフォルトであり、パケットはUNTRACKEDとして明示的にマークされる必要がある。前に接続トラックサブシステムは、このパケットが追跡されないようそれを確認します。Linuxでは、追跡しない必要があるケースはわずかですが、もちろん、ステートフルファイアウォールとステートフル/ダイナミックNATは利用できなくなります(そもそもUNTRACKEDを使用する必要があるかもしれないsteless NATはまだ実行できますが、iptablestcまたはnftables避けるために接続トラックパケットを処理する、この種の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
    
  • パケットがフィルター/INPUT を通過してこのルールに到達すると、次のようになります。

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

    iptablesの特定のカーネルモジュールxt_conntrackは、接続トラックサブシステム(さまざまな関連カーネルモジュールによって処理されますnf_conntrack*)でこのパケットの状態をルックアップデータベースで問い合わせます。答えがまたはの場合、RELATEDパケットESTABLISHEDは一致し、ACCEPT判定に進みます。実際には、結果はすでにキャッシュされたパケット最初に検索が実行されたとき(通常は接続トラック-m conntrack --ctstate NEW)なので、これは安価な「検索」です。これは、すでに受け入れられたフローを処理するための一般的なルールです。これらのフローは、明示的に言及しているルールまたは単に言及していないが配置されているルールで最初に受け入れられます。この一般的なルールに従います (ただし、INVALID 状態は、通常は実行する前に DROP する必要があることに注意してください)。

  • 箇条書きを追加します: 着信パケットと発信パケットの処理は、PREROUTING と OUTPUT 間で非常に対称的です (対称に見えなくても)。接続トラックPREROUTINGとOUTPUT(および他のいくつかの場所)のインターフェースは、NATと連携しています接続トラックただし、最初のパケットはNEW状態を通過する。iptablesのNATテーブル)。これは、IPFWについて書いた説明とは少し異なるかもしれません。アプリケーションを実行しているサーバーが送信フローも制限している場合は、おそらくこの同じ汎用的なiptablesすでに受け入れられた着信トラフィックの送信応答パケットが通過できるように、filter/OUTPUT と filter/INPUT の両方でルールを設定します。


追加情報

専用のツールがあり、接続トラックサブシステムのルックアップテーブルからconntrackツール

  • conntrack: 処理されるルックアップテーブルの内容を照会、削除、または更新する接続トラック

    いくつかの例。

    追跡されたすべてのエントリ (追加のフィルターなしでは大きくなる可能性があります) を次のように一覧表示できます。

    conntrack -L
    

    システムで NAT を実行している場合 (例: プライベート LAN の前にあるルーター、または VM とコンテナーを実行している場合) --any-nat、 、--src-natまたはを使用し--dst-natて、それぞれすべての NAT、すべてのソース NAT (マスカレード)、またはすべての宛先 NAT (通常は転送されたポート) のみを表示できます。

    リアルタイム監視接続トラックイベント:

    conntrack -E
    
  • conntrackd: フロー計算と統計を主な目的とするデーモン(conntrack)高可用性ステートフルファイアウォールクラスタ状態の同期。

答え2

接続追跡は Netfilter の別の機能であり、IPTables では構成されません。

ここに画像の説明を入力してください

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

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

Conntrack 操作は、sysctl 値を調整することで調整できますnet.netfilter.nf_conntrack

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

関連情報