NATは、SYNが送信された後に受信したSYNの送信元ポートを確認しますか？
この質問がstackoverflowとserverfaultのどちらに適しているかわかりません。 Stackoverflowに適していると思われる場合は、お知らせください。これを削除して移動します。
STUNTを実装しています。 STUNTが何であるかわからない場合は、別々のNATの背後にある2つのピア間で直接TCP接続するために使用されるプロトコルです。簡単な概要を説明しますが、私の質問ではありません。プロトコルに直接関係します。
これは、サードパーティを使用して、各ピアのNATが次の発信接続をマップするポートを予測することによって行われます。次に、サードパーティは各ピアに互いの予測ポートを通知し、両方が予測ポートで相互に接続しようとします。それらがSYNパケットを相互に送信すると、そのポートのNATに「穴」が開き、SYNパケットが通過してハンドシェイクが実行されます。
私の同僚の1人は、STUNT接続を開始するピアに、予測されたポートが別のアプリケーション（またはアプリケーション）によって使用される場合に備えて、予測されたポートと次の4つのポートへのSYNパケットの送信を試みることを提案しました。接続が試行されますが、予測が行われた後です。
この例では、他のピアがポート80から接続しようとしているが、別のアプリケーションがポート80を使用することになるため、接続は実際にはポート81から行われます。しかし、SYNパケットを5つの異なるポートに送信すると、（理論的には）80、81、82、83、または84からのパケットであれば成功します。
ただし、そうではありません。テストすると、最初のSYNパケットのみが成功する可能性があります。最初のSYNパケットが間違ったポートに送信されても、次の4つのうちの1つが正しいポートに送信された場合でも、それらはすべてサイレントにドロップされます。応答がなく、接続の試行がタイムアウトします。
簡単な例：
ピアAはピアBへのSTUNT接続を開始しています。
ピアAはポート1000からピアBに接続すると予測されています。
ピアBはポート2000からピアAに接続すると予測されています。
サーバーは1000をピアBに送信し、2000をピアAに送信します。
ピアBのコンピューター上の別のアプリケーションが新しい接続を確立し、ポート2000を引き継ぎます。
ピアAのコンピューター上の別のアプリケーションが新しい接続を確立し、ポート1000を引き継ぎます。
ピアAは、ポート2000、2001、2002、2003、および2004でピアBへの接続を同時に試みます。接続の試行は、ポート1001、1002、1003、1004、および1005から行われます。
ピアBはポート1000でピアBに接続しようとします。接続の試行はポート2001から行われます。
ピアAとピアBのNATのポート1001と2001にそれぞれ穴が作成されます。 SYNパケットの通過を許可する必要があります。
私が信じているのは、ピアBのNATは、接続が1000から来ると予想していたが、1002から来たため、ポート2001を介したピアAのSYNパケットを許可していないということです。 NATがSYNパケットの送信元を確認していることを確認してください。
ただし、私が読んだところによると、STUNTの欠点の1つは、接続を作成するときに、別のソースによって接続が乗っ取られる可能性がある脆弱性のウィンドウがあることです。 NATが着信接続のソースを確認するのが標準的な動作である場合、この脆弱性のウィンドウがどのように存在するかはわかりません。
私の実装には欠陥がないことに注意してください。予測されたポートのいずれかが正しい場合、接続は成功します。この問題は、予測された両方のポートが間違っていて、一度に複数のポートを試行する場合に発生します。
プロトコルに精通している人への補足として、実際の接続を試みる前にサイレントに期待するSYNを送信する方法を使用しています。低TTL実装を使用していません。
私のNAT SYNパケットは、予期されたポートから送信されていないために拒否されますか、それとも他の何かがそれらを拒否していますか？それが私のNATの場合、これは期待されていますか？ /標準の動作？拒否されるとは、「サイレントドロップ」を意味することに注意してください。RSTまたは応答がまったく返されないため、接続がタイムアウトするだけです。
編集：問題のルーターはどちらもウォルマートで家庭用に購入する種類のものであり、大企業が使用する種類のものではありません。
簡単な答え：はい-あなたのNATは、パケットが期待どおりではないため、パケットを拒否しています。これは、NATの実装からNATの実装までさまざまです。
社説はさておき：私は以前にスタントのことを聞いたことがありませんでした...（スタント、はい-スタントではありません）。ああ、うん...なんてハックだ。インターネットがこのNATトレーラーパークに変わったこと、そして私たちがこのようなハッキングに頼っていることに私は泣きます。
読んだ後 紙 私は彼らがしていることを理解します。基本的には、各「エンドポイント」にパケットスニッフィングのビットが追加され、最初のシーケンス番号をスニッフィングし、任意の着信TCP接続を受け入れることができるネット上のサードパーティを介してそれらをトレードアップするのはSTUNです。実はかわいいトリックです。
このような100％信頼できる通信は決して得られません。これを最初に実装した研究者は、ポート予測にかなりよく似ている テスト結果 を持っていることがわかります...それは実際には非常に興味深いですが、密度が高く、小さなチャートです。このホワイトペーパーでは、すべての予測の問題について詳しく説明し、成功率を示しています。実際、彼らがとてもうまくやっていたのは私にとって衝撃的です。
正常なNAT実装では、少なくとも、送信元IP、宛先IP、プロトコル、プロトコル送信元ポート、およびプロトコル宛先ポートを使用して「接続」を識別します。 （うまくいけば、彼らはシーケンス/確認応答番号も追跡しています。）
SYNがデバイスのNATテーブルに格納されているこれらの属性の組み合わせと正確に一致しない場合、NAT実装は実際にサイレントにドロップする必要があります。それは私が期待する振る舞いでしょう。