簡単に言うと、その ACK は、ソケットが誰のものでもないときに送信されました。ユーザー 07 に属するソケットに関連するパケットを許可する代わりに 、ユーザー 11 からのソケットによって開始された接続に関連するパケットを許可します .
長い話。
この問題を理解するには、20 の仕組みを理解することが役立ちます。 HTTP リクエストは一般的に機能します。
で
wget http://cachefly.cachefly.net/10mb.test
38 40 への TCP 接続を確立します 、確立されると、HTTP プロトコルで次のような要求を送信します。「52 のコンテンツを送信してください (69 ) ところで、終了後に接続を閉じないでください (79) ）。これは、サーバーが同じ IP アドレスの URL へのリダイレクトで応答した場合に、接続を再利用できるためです。
これで、サーバーは次のいずれかで応答できます。 )、はい OK、接続を開いたままにします」. または、データのサイズがわからない場合は、「データは次のとおりです。申し訳ありませんが、接続を開いたままにすることはできませんが、いつできるかをお知らせします.接続を閉じてデータのダウンロードを停止してください。」
上記の URL では、最初のケースです。
94 は応答のヘッダーを取得し、10MB のデータをダウンロードするとジョブが完了したことを認識します。
基本的に、109 とは 10MB を受信して終了するまでデータを読み取ります。しかし、その時点で、やるべきことはまだあります。サーバーはどうですか？接続を開いたままにするように指示されました。
終了する前に、114 閉じる (126 システムコール) ソケットのファイル記述子。 139 、システムはサーバーから送信されたデータの確認を終了し、145 を送信します 「これ以上データを送信しません」と言う。その時点で 158 戻り値と 166 終了します。もう TCP 接続に関連付けられているソケットはありません (少なくともユーザーが所有するソケットはありません)。しかし、それはまだ終わっていません。その 177 を受け取ると 、HTTP サーバーは ファイルの終わり を認識します クライアントからの次のリクエストを読み取るとき。 HTTP では、これは「もうリクエストはありません。終了します」という意味です。そのため、FIN も送信して、「私も何も送信しません。その接続は切断されます」と伝えます。
その FIN を受信すると、クライアントは「ACK」を送信します。しかし、その時点で 182 いなくなって久しいので、ACK はどのユーザーからも送信されません。これが、ファイアウォールによってブロックされている理由です。サーバーは ACK を受信しないため、断念するまで FIN を何度も送信し、ドロップされた ACK がさらに表示されるようになります。これはまた、これらの ACK を破棄することで、(LAST-ACK 状態でソケットを維持する必要がある) サーバーのリソースをかなり長い間不必要に使用していることを意味します。
クライアントが「キープアライブ」を要求しなかった場合、またはサーバーが「キープアライブ」で応答しなかった場合、動作は異なります。
すでに述べたように、接続トラッカーを使用している場合は、ESTABLISHED および RELATED 状態のすべてのパケットを通過させ、199 のみを考慮する必要があります。
209 を許可する場合 ユーザー 218 からのパケット ユーザー 221 からのパケットではありません 、次にユーザー 231 によって確立された接続の他のパケット ユーザー 245 による接続を確立できないため、通過します。 (259 をブロックしているため 接続を確立するパケット)、ユーザー 264 のパケットはありません
<ブロック引用>
これにより、アカウント「useraccount」に対してのみポート 80 の送信が許可されます
— まあ、少なくともあなたが示したルールは、実際にはこれを暗示していません.
アドバイスの余地もあります — ESTABLISHED ストリームでユーザー チェックを行うのではなく、NEW でチェックするだけです。 Incoming ESTABLISHED をチェックするときに送信元ポートをチェックする意味もわかりません。ポートの違いは何ですか。conntrack の PoV からすでに ESTABLISHED 状態になっています。ファイアウォールは可能な限りシンプルでありながら効率的であるべきであるため、Occam のカミソリ アプローチが最適です。