わかりました、この状況がやや異常であることは認識していますが、生のソケット (C では Linux) のみを使用して TCP 接続 (3 ウェイ ハンドシェイク) を確立する必要があります。つまり、IP ヘッダーと TCP ヘッダーを自分で構築する必要があります。 . 私はサーバーを書いています (そのため、最初に着信 SYN パケットに応答する必要があります)、何らかの理由でそれを正しく行うことができないようです。はい、私は SOCK_STREAM がこれを処理することを理解していますが、私が入りたくない理由から、それはオプションではありません。
raw ソケットの使用に関するオンラインで見つけたチュートリアルはすべて SYN フラッダーを構築する方法を説明していますが、元のパケットに基づいて応答を構築する必要がないため、これは実際に TCP 接続を確立するよりもいくらか簡単です。SYNフラッダーのサンプルが動作するようになり、受信SYNパケットを生のソケットから問題なく読み取ることができますが、クライアントからの受信SYNに対する有効なSYN/ACK応答を作成するのにまだ問題があります.
それで、SYNフラッダーの作成を超えた生のソケットの使用に関する優れたチュートリアルを知っている人はいますか、またはこれを実行できるコードを持っている人はいますか(SOCK_STREAMではなくSOCK_RAWを使用)? 私は非常に感謝されます。
MarkR は完全に正しいです。問題は、カーネルがポートが閉じていると考えているため、初期パケットに応答してリセット パケットを送信していることです。カーネルは私を応答に打ち負かし、接続は切断されます。私はすでに接続を監視するために tcpdump を使用していました。もっと注意を払うべきだったのですが、2 つの応答があり、そのうちの 1 つは物事を台無しにしていたリセットであり、プログラムが作成した応答であることに気付きました。ドー！
MarkR で提案されているように、iptables ルールを使用してアウトバウンド パケットをブロックするのが最も効果的と思われる解決策です。ただし、提案されているように、マーク オプションを使用するよりも簡単な方法があります。リセット TCP フラグが設定されているかどうかを照合するだけです。通常の接続の過程でこれが必要になることはまずありません。また、使用中のポートからのすべてのアウトバウンド リセット パケットをブロックしても、アプリケーションにとっては問題になりません。これにより、カーネルの不要な応答が効果的にブロックされますが、自分のパケットはブロックされません。プログラムがリッスンしているポートが 9999 の場合、iptables ルールは次のようになります。
iptables -t filter -I OUTPUT -p tcp --sport 9999 --tcp-flags RST RST -j DROP