通常、NAT は、そこから送信されるすべてのパケットに対してローカル エンドポイントのパブリック エンドポイントを同じに保つため、UDP ホール パンチングが簡単に可能になります。ただし、一部の NAT は、パケットが送信されるホストごとにローカル エンドポイントを異なるパブリック エンドポイントにマップするため、UDP ホール パンチングは不可能になります。
従来の UDP パンチングを実行する唯一の方法は、リモート エンドポイントを推測することです。ただし、ポートは 65,000 個以上あるため、この方法はあまり信頼性がありません。そのため、Skype などのアプリケーションは、ほぼすべての種類の NAT を介して通信できることを十分承知しているため、そのためにリレーを使用していると読みました。質問は次のとおりです。
リレーは、着信データをあるソケットから別のソケットに転送するだけのソケットです。推測したりリレーを使用したりせずに (リレーを使用すると、実際には「ホール パンチング」ではなくなります)、不正な NAT を介して UDP ホール パンチングを実行する他の方法はありますか?
答え1
非動作 NAT という用語は正しくありません。PAT (ポート アドレス変換) を使用して複数のプライベート アドレスを 1 つのパブリック アドレスに集約する NAT デバイスは、送信元ポートを再マップします。これが、PAT の「ポート アドレス」の参照先です。
2 つの内部デバイスが同じ送信元アドレスを使用して同じ宛先に接続し、NAT 処理後に送信元ポートが同じままであると期待することは不可能であり、複数の宛先をターゲットにするときに送信元ポートの一貫性を保とうとしても、セキュリティ体制にメリットはありません。したがって、これは通常、ファイアウォールの設計上の目的ではありません。
もちろん、これはここでは役に立ちません。接続のソース ポートを知りたいのですが、そのソースから実際にパケットを受信する必要はありません。エンドポイントがサード パーティを介して通信する場合、リレーが明らかなオプションです (はい、リレーは、提案されているように、ソケット間でパケットを転送するだけです。Skype サーバー内での実装はおそらくはるかに複雑ですが、原理的には同じです)。
エンドポイントは実行中の変換を認識しないため、何らかのサイド チャネル (中央サーバーにポートのみを登録して直接通信するなど) を介して送信元ポートを通信することさえできないため、他の方法でこれを行う方法はわかりません。