ファイアウォールはどのようにしてRSTまたはFINなしでTCP接続を終了しますか？[閉まっている]

状況は次のとおりです。

http client ----> corporate firewall ----> http server

キープアライブにより、サーバーとクライアントはTCP接続を開いたままにし、クライアントはHTTPリクエストに接続プールを使用します。

ファイアウォールには、1時間後に長期のTCP接続を「強制終了」するルールがあります。問題は、HTTPクライアントがTCP接続が破壊されたことを検出せず、一定期間後にクライアントが「ハング」したように見えた、本質的に無効な接続を再利用しようとしたことです。おそらく新しい接続が確立されたため、要求がハングし、次の要求が機能しました。

ここでの問題は、 HTTPクライアントがTCP接続を検出できなかった方法でファイアウォールがTCP接続を強制終了するメカニズムは何ですか。私はいくつかの方法でこの動作をローカルで再現しようとしました：

1. VyosルーターのTCP接続を強制終了し、クライアント側のWiresharkがTCP FIN-ACKをキャプチャしました。OK
2. WindowsのTCPViewでTCP接続のクライアント側を強制終了し、Wiresharkがクライアント側でTCP RSTを検出しました。OK
3. クライアント側ファイアウォールへの接続が確立された後にポートをブロックすると、ソケットリセット例外が発生しました。OK

サーバー側にWiresharkダンプがあり、ファイアウォールがFINまたはRSTを送信しているかどうかを確認しようとしましたip.dst==serverip && (tcp.flags.reset==1 || tcp.flags.fin==1)が、何も表示されませんでした。

さらに、クライアント側のWiresharkキャプチャでは、HTTPリクエストが送信され、その後に数十のTCP再送信が続き、最終的にはどこにも送信されないという問題が示されています。

HTTPクライアントはJavaネイティブおよび/またはJetty HTTPクライアント（両方を試しました）であり、どちらも無効なTCP接続を検出できませんでした。動作をローカルで再現したいのですが、ファイアウォールが接続を強制終了しているので、どのような問題があるのか​​わからないので、考えられる答えを探しています。

ファイアウォールの種類については触れていませんが、ほとんどの場合、パケットをドロップするだけだと思います。

サーバー側にWiresharkダンプがあり、ファイアウォールがip.dst == serverip &&（tcp.flags.reset == 1 || tcp.flags.fin == 1）でFINまたはRSTを送信するかどうかを確認しようとしましたが、何もしませんでした現れた。

これを確認する傾向があります。

ファイアウォールがRSTパケットを送信せずにパケットをドロップした可能性があります。おそらく、なんらかのセッションタイムアウト値に達した後です。これは通常、設定可能な動作です。

私は個人的にそのRSTパケットを送信することを好みます。これはクライアントが正常に動作するのに役立つためです。ただし、潜在的な攻撃者へのフィードバックの提供を避けるために、外部に面するファイアウォールではこれを行うべきではないという意見を聞いています。

クライアントは通常、この種のシナリオを非常にエレガントに処理しないため、これがかなりの数の問題を引き起こすことを見てきました。基本的に、元のTCPセッション（現在は無効になっています）を通じて再試行を続け、新しいセッションを再確立しようとはしません。最終的にクライアント側のタイムアウトがトリガーされ、ユーザーは厄介なエラーメッセージを受け取ります。アプリに適切にHTTPキープアライブを設定すると、これを修正するのに役立ちます。

@Ron Trunkは正確です。ほとんどの場合、開いている接続はアクティブ（拒否ルールの挿入）またはパッシブ（既知の接続から削除され、synなしで再作成することはできません）でドロップされます。コメントの1つは、自分で試してみることを提案しました。これは、linuxネットワーク名前空間を使用してそうするためのレシピです。ホストのカーネルでIP転送が有効になっていて、あなたがrootであり、おそらく他のこともあると想定しています。

# Create network namespacs
ip netns add one; ip netns add two; ip netns add three
# Create interfaces between namespaces
ip link add dev i12 type veth peer name i21
ip link add dev i32 type veth peer name i23
# Bring interfaces up and assign them to respective namespaces
ip link set dev i12 netns one up
ip link set dev i21 netns two up
ip link set dev i32 netns three up
ip link set dev i23 netns two up
# Assign IP addresses
ip netns exec one ip addr add 1.1.1.1/24 dev i12
ip netns exec two ip addr add 1.1.1.2/24 dev i21
ip netns exec three ip addr add 3.3.3.3/24 dev i32
ip netns exec two ip addr add 3.3.3.2/24 dev i23
# Add routes when necessary
ip netns exec one ip route add default via 1.1.1.2
ip netns exec three ip route add default via 3.3.3.2

次に、3つのウィンドウ/シェル/画面/ターミナルが必要です。以下の各コマンドを異なる端末で実行します。

• サーバーでリッスンを開始します。 ip netns exec three socat TCP-LISTEN:5001 STDIO
• クライアントで送信を開始します。 ip netns exec one socat STDIO TCP:3.3.3.3:5001

これらのコマンドを実行した後、1つのウィンドウに入力したすべてのものが他のウィンドウにも反映され、その逆も同様です（returnキーを押した後）。そうでない場合は、IP転送を有効にする必要があります。

• 拒否ルールをインスタンス化します。 ip netns exec two iptables -I FORWARD -j DROP

次に、入力したものは何も許可されません。

次のような（テストされていない）転送ルールを使用して、アクティブでないドロップメソッドをシミュレートできます。

ip netns exec two iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
ip netns exec two iptables -A FORWARD -m tcp -p tcp -dport 5001 --tcp-flags ALL SYN -j ACCEPT
ip netns exec two iptables -A FORWARD -j DROP

/unix/127081/conntrack-tcp-timeout-for-state-stablished-not-workingおよびhttps://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctlを参照してくださいタイムアウトを調整する方法の詳細については、.txt -iptablesがネイティブで最大接続存続期間をサポートするかどうかは不明です。すべてのタイムアウトはアイドルタイムアウトであると思います。

でクリーンアップ ip netns del one; ip netns del two; ip netns del three

ファイアウォールは、ターゲットに到達できなかったことを示すICMPパケットを送信できます。TCP以外の場合、それが唯一の考えられるエラー表示です。たとえば、閉じたUDPポートにパケットを送信すると、理由コードが「ポート到達不能」に設定された「宛先到達不能」メッセージが生成されます。

TCPパケットへの応答として「port unreachable」メッセージを送信することも可能です。これにより接続も終了しますが、TCP規則はRSTでポートが閉じていることを示すため、パケットダンプを分析している人は誰でもこれが異常であることを認識します。

送信者は、受信したすべてのICMPエラーパケットを元の接続にマッピングして適切に処理する必要があるため、ファイアウォールで生成されたエラーパケットを使用してTCP接続を終了することもできます。ICMPパケットには、このマッピングを可能にする違反パケットのヘッダーのコピーが含まれています。