パケットが「iptables」によって無効と見なされた理由を理解するにはどうすればよいですか？

iptables無効なパケットをログに記録してドロップするようにいくつかのルールを設定しました（--state INVALID）。ログを読んで、パケットが無効と見なされた理由を理解するにはどうすればよいですか？たとえば、次のとおりです。

Nov 29 22:59:13 htpc-router kernel: [6550193.790402] ::IPT::DROP:: IN=ppp0 OUT= MAC= SRC=31.13.72.7 DST=136.169.151.82 LEN=40 TOS=0x00 PREC=0x00 TTL=242 ID=5104 DF PROTO=TCP SPT=80 DPT=61597 WINDOW=0 RES=0x00 ACK RST URGP=0

linux iptables firewall

— ムベイトフ
ソース

ステートフルパケットインスペクションを使用すると、パケットはさまざまな状態になる可能性があります。

新規：パケットは既知のフローまたはソケットの一部ではなく、TCPフラグはSYNビットがオンになっています。
確立：パケットCONNTRACKはによって追跡されるフローまたはソケットと一致し、TCPフラグを持っています。最初のTCPハンドシェイクが完了した後、パケットが確立された状態になるには、SYNビットがオフである必要があります。
関連：パケットは既知のフローまたはソケットとは一致しませんが、それを述語する既存のソケットがあるため、パケットは予期されます（これの例は、ポート21に既存のFTPセッションがある場合のポート20のデータ、またはUDPデータです。 TCPポート5060の既存のSIP接続の場合）。これには、関連付けられたALGが必要です。
無効：上記のいずれの状態にも該当しない場合、パケットは状態にありINVALIDます。これは、さまざまなタイプのステルスネットワークプローブが原因であるか、CONNTRACKエントリが不足していることを意味している可能性があります（ログにも記載されているはずです）。または、単に完全に無害な場合もあります。

あなたの場合、引用したパケットは、TCPフラグACKとRST、および送信元ポートがであることを示しています80。つまり、のWebサーバー31.13.72.7（たまたまFacebook）がリセットパケットを送信したということです。その前に来たパケット（もしあれば）を見ずに理由を言うことは完全に不可能です。しかし、ほとんどの場合、コンピュータが無効であると考えるのと同じ理由でリセットを送信しています。

— バハマト
ソース

それで、カーネル（またはiptables）に、無効であることの理由を保持する一種の「署名」をパケットに追加するように依頼する方法はありませんか？

— mbaitoff

当然、違います。無効とは、既知の状態と一致しないことを意味します。つまり、これは「なぜこのパケットを受け取ったのか分からない」というカーネルです。

— bahamat

特定のINVALIDパケットをデバッグするには、それらをWiresharkのダンプから見ると機能する可能性があります... SACKフィールドを持つパケットを見ました（実際には、通常のシーケンス番号はファイアウォールによって変更され、SACKオプションのパケットは変更されないため、SACKになります。無効な値）ファイアウォールが無効として削除されたことにより破壊された...

— Gert van den Berg