udp over tcpダウンロード - udp over tcpソースコードのダウンロード

udp over tcp

その他のカテゴリー

v0.1.3

ダウンロード

udp-over-tcp

TCP 経由で UDP データグラムをトンネリングするためのコマンドラインツール。

SSH 経由で UDP をトンネリングする場合に特に便利です

このツールは主に、明らかなクライアント/サーバー関係なしで UDP 経由で相互に通信する必要がある 2 つのアプリケーションがあるユースケース向けに設計されました。つまり、どちらのアプリケーションでもパケットを開始でき、起動時にもう一方のアプリケーションのアドレスを設定する必要があります (つまり、ポートをランダムにすることはできません)。

両方のアプリケーションのホストでudp-over-tcp実行します。各インスタンスは、他方で実行されているアプリケーション上の一種のローカルレプリカとして機能します。 1 つのホスト上のアプリケーションが UDP ポート P でリッスンする場合、 udp-over-tcp他のホストの UDP ポート P でリッスンし、レプリカ P へのトラフィックが実際のアプリケーションのポート P に送信されるようにしudp-over-tcp 、両方のアプリケーションのポートに対してこれを同時に実行し、ポートを結合します。これは、各アプリケーションが他のアプリケーションに対してローカルで実行されているように事実上「ふり」ます。

具体的には、あるホスト上のアプリケーションがそのポート P から (ローカルレプリカ) ポート Q にデータグラムを送信すると、そのデータグラムは送信元ポート P を持つ実際の (リモート) アプリケーションのポート Q に到着します。これは、アプリケーションが常に同じ単一のアドレス (ローカルホスト) とポート (他のアプリケーションのポート) を参照し、その同じアドレスとホストのペアをアプリケーションのピア構成でも使用できることを意味します。

次の図がudp-over-tcpの設定を理解するのに役立つことを願っています。

インストール

このプログラムは、多くのプラットフォーム用に事前にコンパイルされており (cargo-dist に感謝!)、依存関係なしですぐに実行できるはずです。

あるいは、Cargo を通じてインストールすることもできます。

$ cargo install udp-over-tcp

使用法

ホスト X のポート A で実行されている UDP アプリケーションがあります。このアプリケーションが、ホスト Y のポート B で実行されている UDP アプリケーションと通信できるようにしたいと考えています。また、Y のアプリケーションが X の A と通信できるようにしたいと考えています。次のように：

いずれかのホスト (ここでは X) で、まず他のホストへの TCP トンネルを作成します。

 ssh -L 7878:127.0.0.1:7878 $Y

次に、両方のホストで udp-over-tcp を実行します (1 つは--tcp-listenを使用し、もう 1 つは--tcp-connectを使用します)。 --tcp-listen 、転送によって接続が許可されるホスト (ここでは Y) で使用する必要があります。どちらの順序でも実行できますが、ベストプラクティスは最初に聞くことです。

 Y $ udp-over-tcp --tcp-listen  7878 --udp-bind $A --udp-sendto $B
X $ udp-over-tcp --tcp-connect 7878 --udp-bind $B --udp-sendto $A

Y では、これは UDP ポート $A でリッスンし、それらを TCP 経由で X に転送し、そこから UDP ポート $A に配信します。 X では、これは UDP ポート $B でリッスンし、それらを TCP 経由で Y に転送し、そこの UDP ポート $B に配信します。

次に、X 上のアプリケーションを 127.0.0.1:$B に送信するように構成し、Y 上のアプリケーションを 127.0.0.1:$A に送信するように構成します。つまり、同じポート、ローカル IP アドレスです。

各引数には、ポート番号 (上記のとおり) または addr:port を使用してアドレスを指定します。 (アドレスのデフォルトは、listen/bind の場合は 0.0.0.0、connect/sendto の場合は 127.0.0.1 です)

代替案

この問題の解決に役立つツールは他にもありますが、それらのツールはこのツールとは異なる特性を持っています。

ncまたはsocatに依存するソリューションでは、UDP データグラム境界が保持されません。つまり、2 つの UDP sendmsgによって、単一の (結合された) メッセージのみがrecvfrom経由で到着する可能性があります。多くの UDP アプリケーションは、メッセージフレーミングを提供するために UDP に依存しているため、この問題に対する耐性がありません。

mullvad の udp-over-tcp は、一方向転送のみを提供します。ツールの追加インスタンスを実行して、他の方向に転送することもできますが、そうすると受信データグラムの送信元ポートが送信データグラムの宛先ポートと一致しなくなります。ただし、クライアントのポートが重要ではないクライアント/サーバースタイルのアプリケーションの場合は、これで十分である可能性があります。