tunnelダウンロード - tunnelソースコードのダウンロード

tunnel

その他のカテゴリー

1.0.0

ダウンロード

トンネル

@nwtgck によるパイピングサーバーをリレーとして使用する、安全な多重化された TCP/UDP ポートフォワーダー。主に (複数の) NAT/ファイアウォールの背後にあるピア間の p2p 接続用に設計されています。

特徴

ピア間の TCP/UDP トンネル。各ピアは (複数の) NAT の背後にある可能性があり、つまり、パブリックインターネットからは到達できません。
送信 http(s) 接続のみが使用されるため、ファイアウォールは問題を引き起こしません。
セキュリティ: 接続するには、ピアはサービスを提供するピアの一意の ID と共有秘密キーを知っている必要があります。ピアとリレー間のトラフィックは暗号化されます (TLS)。リレーには何も保存されません。
多重化: 各トンネルは複数の同時接続をサポートします。接続は全二重です。
多対 1: 転送ピアはクライアントとして機能し、転送先ピアはサーバーとして機能します。サーバーはいつでも複数のクライアントをサポートできます。各ノードはサーバーとクライアントの両方として機能できます。
回復力: 接続が断続的になった場合でも、ピアは自動的に再接続します。
スーパーユーザー権限は必要ありません。
独自のリレーサーバーをホストするオプション (簡単かつ無料)。
KISS: たった 1 つの、小さくて移植可能なシェルスクリプトです。
インストーラーとアップデーターが組み込まれています。

コマンドライン

IPFSの特殊なケースについては、以下の #examples を参照してください。

ID:すべてのノードには一意の (base64) ID が与えられます -

tunnel -i

ID はハードウェア (MAC アドレス) と環境変数 USER、HOME、および HOSTNAME にバインドされます。同僚と一度だけ共有してください。注: 同じマシン上の 2 人のユーザーには、USER 変数と HOME 変数が異なるため、別々のノード ID が与えられます。

サーバーモード:秘密文字列を共有するピアにローカルポートを公開します -

tunnel [options] [-u] [-k < shared-secret > ] < local-port >

クライアントモード:ローカルポートをピアの公開ローカルポートに転送します -

tunnel [options] [-u] [-k < shared-secret > ] [-b < local-port > ] [-I < IP > ] < peer-ID:peer-port >

-bオプションを使用してローカルポートが指定されていない場合、 tunnelランダムな未使用のポートを使用します。使用されるポートは、常に標準出力で報告されます。

-Iオプションは、サーバーが存在する LAN に時々接続されるラップトップ上でクライアントが実行されている場合に便利です。プライベート IP = <IP>を持つサーバーが LAN 上で見つかると、 tunnel LAN 経由で接続します。

クライアントとサーバーが相互に接続できるようにするには、同じシークレットを使用する必要があります。シークレット文字列は、環境変数TUNNEL_KEYを使用して渡すこともできます。 -kで渡されたシークレットが優先されます。

-uフラグは、デフォルトの TCP の代わりに UDP を使用することを示します。使用する場合は、両方のピアで使用する必要があります。

デフォルトでは、すべてのログは stderr にあります。ただし、 -l <logfile>オプションを使用すると、 <logfile>にログをダンプしてtunnelバックグラウンド (デーモンモード) で起動できます。デーモンのプロセス ID は起動中にユーザーに表示されるため、ユーザーはいつでもデーモンを強制終了できます。

tunnel -K < procID >

オプション:

オプションの完全なリストについては、 tunnel -hを参照してください。

インストールとアップデート

以下でダウンロードします:

curl -LO https://raw.githubusercontent.com/SomajitDey/tunnel/main/tunnel

実行可能にします。

chmod +rx ./tunnel

次に、次のようにしてシステム全体にインストールします。

./tunnel -c install

sudo権限がない場合は、代わりにローカルにインストールできます。

./tunnel -c install -l

インストール後にいつでも更新するには:

tunnel -c update

依存性/移植性

このプログラムは、標準の GNU ツール ( socat 、 openssl 、 curl 、 mktemp 、 cut 、 awk 、 sed 、 flock 、 pkill 、 dd 、 xxd 、 base64など) に依存する実行可能なbashスクリプトです。これらのツールは、標準の Linux ディストリビューションですぐに利用できます。

システムにこれらのツールのいずれかが欠けており、ネイティブパッケージリポジトリ (例: sudo apt-get install <package> ) からインストールするために必要なsudo権限がない場合は、ポータブルバイナリをダウンロードして${HOME}/.binにローカルにインストールしてみてください。 ${HOME}/.bin .

例

SSH :

ピア A はローカル SSH ポートを公開します -

tunnel -k " ${secret} " 22

ピア B が接続します -

tunnel -b 67868 -k " ${secret} " -l /dev/null " ${peerA_ID} :22 " # Daemon due to -l
ssh -l " ${login_name} " -p 67868 localhost

IPFS :

ピア A に IPFS ピア ID: 12orQmAlphanumericを持たせます。彼女の IPFS デーモンはデフォルトの TCP ポート 4001 でリッスンします。彼女はそれを - で公開します。

tunnel -k " ${swarm_key} " ipfs

swarm_keyは、ピア A が、 tunnelを使用してピアに swarm 接続できる人を制御するために使用する秘密の文字列です。

ピア B はファイル共有、pubsub、または p2p のためにピア A に接続します -

tunnel -k " ${swarm_key} " 12orQmAlphanumeric

この最後のコマンド swarm は、パイピングサーバーリレーを介してピア A に接続し、接続を維持するためにバックグラウンドで数秒ごとに swarm 接続を続けます。

tunnel IPFS デーモンがまだアクティブでない場合、バックグラウンドで起動します。

IPFS リポジトリへのパスは、オプション-rを使用して渡すことができます。それ以外の場合は、環境変数IPFS_PATHまたはデフォルトのパス~/.ipfsが通常どおり使用されます。例： tunnel -r ~/.ipfs -i IPFS ピア ID を与えます。

リモートシェル:

自宅のマシンから職場の Linux ボックスでコマンドを定期的に起動する必要があるとします。そして、何らかの理由でtunnel経由で SSH を使用したくない、または使用できない場合があります。

職場のコンピューターで、ランダムなローカル TCP ポート (例: 49090) を公開し、そのポートにシェルを接続します。

tunnel -l " /tmp/tunnel.log " -k " your secret " 49090 # Note the base64 node id emitted
socat TCP-LISTEN:49090,reuseaddr,fork SYSTEM: ' bash 2>&1 '

自宅に戻ります:

tunnel -l " /dev/null " -b 5000 -k " your secret " " node_id_of_workplace:49090 "
rlwrap nc localhost 5000

rlwrap の使用は必須ではありません。ただし、GNU Readline を使用し、入力履歴 (ローカルの bash セッションと同様に上/下矢印キーでアクセス可能) を記憶するため、エクスペリエンスがより快適になることは確かです。

レディス:

ピアまたは自分自身がホストするリモート Redis インスタンスに接続する必要がありますか?リモートホストで、 redis-server実行される TCP ポート (デフォルト: 6379) をtunnelを使用して公開します。

ローカルマシンで、 tunnel使用して TCP ポートをリモートポートに転送します。 redis-cli転送されたローカルポートに指定します。

アプリケーション

以下は、私が思いつくtunnelのランダムな使用例です。大まかに言うと、NAT/ファイアウォールトラバーサル (TURN を使用しない WebRTC など) やリモート LAN への参加を伴うものであれば、 tunnel役立つはずです。以下のアイデアのいくつかはかなり大ざっぱで、まったくテストされておらず、機能しない可能性がありますが、それでも、少なくとも当面は、インスピレーションのためにここに文書化されています。これらのいずれかが役立つ、または役に立たない、またはtunnelのまったく新しいアプリケーションを見つけた場合は、ディスカッションに投稿してください。私がテストしたこれらのケースは「動作中」とラベル付けされています。

IPFS ピアに接続中 (動作中)。
P2P チャット、メール、VoIP、ストリーミング、ゲーム、画面共有、ファイル共有、ギャンブル、トラブルシューティングなど。
IoTデバイスを接続します。
SSH (動作)、RDP、または VNC を使用して、ワークステーションを自宅のコンピューターまたはラップトップに接続します。
貝殻掘り出し（作業）。
セルフホスト型またはピア提供の VPN を使用してファイアウォールを突破します。
自宅からインターネットを介して (オフィス LAN 経由で) イントラネットオフィスチャットに参加します。たとえば、BeeBEEP と LAN Messenger は、 tunnelを使用してオフィス内のノードから転送されたローカルポートを使用する場合があります。
P2P (サーバーレス) オーディオ/ビデオ。たとえば、ローカル TCP/UDP ポートをピアのローカルホストに転送し、p2p クライアントをそこにポイントします。既製の FOSS: Jami、Jitsi、Toxchat、Retroshare。
Teamviewer または Anydesk を使用したサーバーレスリモートコントロール。ローカルポート、たとえば 6000 をピアのローカル TCP ポート 5938 (TV 用) および 7070 (Anydesk 用) に転送し、ピアのIP:portタプルとして127.0.0.1:6000を使用します。
ローカル (Web) ポートをパブリックにアクセスできるようにする、つまりインターネットからアクセスできるリバースプロキシを作成する: Heroku でtunnel実行し (無料)、環境変数PORTに保存されているポートを公開したいローカルポートに転送するだけです。そして、パブリック URL は https://your-app-name.herokuapp.com になります。
ユニバーサルネットワークカメラアダプタを使用してリモート IP Web カメラからフィードにアクセスする: WLAN 経由でモバイルカメラにアクセスできるリモートノードにローカルポートを転送します。
VLC によるストリーミング: 映画と音楽、ウェブカメラ [コマンドライン]。 tunnel使用してサーバーとクライアントを接続するだけです。

安全

リレーが https を使用している場合、 tunnelピアとリレー間のすべてのトラフィックを TLS で暗号化します。ピア自体の間にはエンドツーエンドの暗号化自体はありません。ただし、パイピングサーバーリレーはストレージレスであると主張されています。

クライアントピアは、同じ秘密キー (TUNNEL_KEY) を使用する場合にのみ、サービングピアに接続できます。キーは主に中継段階でのピアの検出に使用されます。転送されたローカルポートへの新しい接続ごとに、クライアントはランダムなセッションキーをサービス提供ピアに送信します。その後、ピアはこのランダムキーに基づいて別の中継ポイントで新しい接続を形成し、実際のデータ転送が行われます。部外者、つまり。 TUNNEL_KEY を知らない悪意のある者がこの流れを妨害することはできません。

ただし、悪意のあるピアは次のことを行う可能性があります。彼は TUNNEL_KEY とサービス提供ピアのノード ID を知っているため、後者になりすますことができます。したがって、何も疑わない接続ピアからのデータが偽装者に転送され、本物のサーバーが枯渇してしまいます。 tunnelの今後の更新/実装では、公開キー暗号を使用してこの脅威に対処する必要があります。 [その場合、転送される新しい接続ごとに生成されるランダムなセッションキーは、本物のサーバーだけで復号化できます。

tunnel本質的にトランスポート層であることを考えると、SSH や IPFS などのほとんどのアプリケーションはアプリケーション層でデータを暗号化するため、上記の点に気を落とす必要はありません。すべてのデータ転送のtunnelをエンドツーエンドで暗号化すると、遅延が増加するだけです。ただし、必要に応じて、 tunnelとの低レベルピアリングを確立した後、いつでも SSH トンネルを作成できます。

リレー

tunnelで使用されるデフォルトのリレーは https://ppng.io です。このリストにある他のパブリックリレーを使用したり、Heraku が提供するような無料サービスで独自のインスタンスをホストしたりすることもできます。言うまでもなく、接続するには、2 つのピアが同じリレーを使用する必要があります。

必要に応じて、sertain などの単純なツールを使用して、 tunnelで使用される独自のリレーを作成することもできます。リレーサービスにpiping-serverと同じAPIがあることを確認してください。リレーコードがオープンソースである場合は、ディスカッションでそれを紹介することを歓迎します。

こちらも参照

gソケット ;回線リレーが有効になっている ipfs p2p ; go-piping-duplex ;ピペト.me ;アップリンク;ローカルホスト.run ;ングロク ;ローカルトンネル ; sshreach.me (期間限定の無料トライアル) ;もっと

注:

パイプサーバーとは異なり、これらのほとんどは、非常に重要なリレーやリバースプロキシの簡単で無料のセルフホスティングを提供しません。これらのサービスがダウンしたら、あなたは破滅するでしょう。ただし、 tunnelとパイピングサーバーを使用すると、独自のリレーインスタンスをデプロイし、そのパブリック URL をピアと完全に共有し、同じものを.bashrc内のTUNNEL_RELAYとしてexportだけで準備完了です。また、冗長性を確保するために複数のパブリックパイピングサーバーを使用できます。
これらのサービスの一部は、無料枠でセッションごとに新しいランダムなパブリック URL を提供しますが、これは断続的な接続 (IoT アプリケーションなど) で問題になります。一部の無料プランでは、接続がアイドル状態でなくても、一定時間が経過するとセッションが期限切れになります。
ローカルポートを Web トラフィックのみに公開するものもあります。非 Web プロトコルを HTTP 経由で転送する責任は、あなたとあなたのピアに残されています。

今後の方向性

IPFS (完了):

IPFS への接続ははるかに簡単になります。

公開するにはtunnel -k <secret> ipfs 、接続するにはtunnel -k <secret> <IPFS_peerID>使用します。

これらは、オフラインの場合、IPFS デーモンを独自に起動します。後者のコマンドは、指定されたピアへの swarm 接続を 30 秒間隔で繰り返し実行します。 IPFS ピア ID はノード ID として使用されるため、ピアはノード ID を個別に共有する必要がなくなります。デフォルト以外の IPFS リポジトリパスは、オプション-rを使用して渡すことができます。またはIPFS_PATH 。

SSH:

ローカルポートとピアポートの間に SSH トンネルを作成するのは次のように簡単です。

tunnel -k <secret> sshを公開し、

作成するtunnel -sk <secret> -b <local-port> <peerID>:<peer-port> 。

接続中にログイン名を入力する必要がないことに注意してください。デフォルトでは、サービングノードの${USER}がログイン名として使用されます。ただし、必要に応じて、環境変数またはオプションを使用して、デフォルト以外のログイン名をいつでも渡すことができます。

GPG:

クラウドシェルや dyno で使用される仮想マシンには、永続的な一意のハードウェアアドレスがありません。したがって、このような VM のノード ID はセッションごとに変化し続けます。将来のtunnelは、 GPG 秘密鍵をtunnelに渡す-gオプションが追加される予定です。ノード ID は、IPFS と同様に、このキーのフィンガープリントから生成されます。これにより、 tunnel安全性も高まります。

アルゴン2:

オプション [ -a ] は、使用前に TUNNEL_KEY をハッシュするために argon2 を使用し、弱いシークレットがあまりにも脆弱にならないようにします。