tunneler

トンネラー

このリポジトリには、他のネットワーク プロトコルを介して TCP および UDP トラフィックをトンネルできるようにするクライアントとサーバーが含まれています。

現在サポートされているトンネルは次のとおりです。

• DNS (権威サーバーまたは直接接続)
• TLS（相互認証）
• TCP

メインツールは Rust で書かれ、エンドツーエンドのテストは Python で書かれています。

インストール

オプション 1: クライアントとサーバーの Docker イメージ

docker pull ghcr.io/dlemel8/tunneler-server:latest
docker pull ghcr.io/dlemel8/tunneler-client:latest

オプション 2: ソース コードからコンパイルする

cargo --version || curl --proto ' =https ' --tlsv1.2 -sSf https://sh.rustup.rs | sh
cargo build --release

ローカルの docker イメージを構築したい場合は、docker ファイルもあります

使用法

オプション 1: クライアントとサーバーの Docker イメージ

docker run -e LOCAL_PORT=45301 
           -e REMOTE_PORT=5201 
           -e REMOTE_ADDRESS=localhost 
           -e TUNNELED_TYPE=udp 
           --rm -p 45301:45301 ghcr.io/dlemel8/tunneler-server:latest tcp

オプション 2: ローカルでコンパイルされたバイナリ

./target/release/client 
  --tunneled-type tcp 
  --remote-address 1.1.1.1 
  --remote-port 53 
  --log-level debug 
  dns 
  --read-timeout-in-milliseconds 100 
  --idle-client-timeout-in-milliseconds 30000

詳細については、 --helpを指定して docker イメージまたはコンパイルされたバイナリを実行してください

テスト

単体テストの実行

cargo test --all-targets

エンドツーエンドのテストを実行する

python3 -m pip install -r e2e_tests/requirements.txt
PYTHONPATH=. python3 -m pytest -v

例

このリポジトリには、Docker Compose を使用したサーバー デプロイメントの例がいくつか含まれています。

• 速度テスト - サポートされているすべてのトンネル経由で iperf3 サーバーが公開され、トンネル速度を比較できます。
• 権威 DNS - ポート UDP/53 の DNS トンネル経由で公開される Redis サーバー。トンネルはクライアントを検証しないため、Redis 認証が必要です。
• パイプライン - TLS トンネル経由で公開される Redis サーバー自体が DNS トンネル経由で公開されます。トンネルはクライアントを検証するため、Redis 認証は使用されません。

各サンプルはローカルで実行することも、Terraform と Ansible を使用してデプロイすることもできます。詳細については、こちらをご覧ください。

建築

各実行可能ファイルには、クライアント ストリームのチャネル (バイト リーダーとライターのタプル) を介して通信する 2 つのコンポーネントが含まれています。

• クライアント リスナーはソケットをバインドし、受信トラフィックと送信トラフィックを新しいストリームに変換します。
• クライアント トンネラーは、ストリーム リーダーとライターをトンネル プロトコルに変換します。
• Server Untunneler は、トンネル プロトコルに従ってソケットをバインドし、トンネルされたトラフィックを元のストリームに変換します。
• サーバー フォワーダーは、ストリーム ライターとリーダーをトラフィックに変換します。

TCP ベースのトラフィックは簡単にストリームに変換されます。 UDP ベースのトラフィック変換は、トンネル プロトコルに依存します。

UDP ベースのトラフィックには、セッションを継続するために既存のクライアントを識別する方法も必要です。この解決策は、クライアントの識別子をそのストリームにマップするメモリ内のクライアント キャッシュです。

プロトコル

トンネル化された UDP

UDP トラフィックをストリームに変換するために、2 バイト サイズのヘッダー (ビッグ エンディアン) が各パケット ペイロードの前に置かれます。

UDP リスナーは、受信パケットのピア アドレスをクライアント キャッシュのキーとして使用します。

DNSトンネリング

ここにはいくつかの課題があります。

• DNS ペイロードは英数字である必要があります。
• 次のメッセージを送信する前に、すべてのメッセージに応答が必要です。
• 各 DNS クエリはランダム化された送信元ポートとトランザクション ID を使用するため、それらをクライアント キャッシュ キーとして使用することはできません。

これらの課題を解決するために、各クライアント セッションはランダムなクライアント ID (4 つの英数字) を生成することから始まります。クライアントはデータを読み取ってトンネリングし、エンコーダーのパイプライン経由で実行します。

• データは 16 進数でエンコードされます。
• クライアントIDが付加されます。
• クライアントサフィックスが追加されます。サーバーが権威 DNS サーバー上で実行されている場合、サフィックスは「.<あなたのドメイン>」です。

エンコードされたデータは、TXT DNS クエリの名前として使用されます。

権威 DNS サーバーを所有している場合、クライアントは再帰 DNS リゾルバーにリクエストを送信できます。リゾルバーはドメイン名レジストラーから IP を取得し、リクエストを IP に転送します。もう 1 つのオプション (より高速ですが、トラフィック アナライザにとってより明白です) は、要求を IP (ポート UDP/53 またはサーバーがリッスンしている他のポート) に直接送信するようにクライアントを構成することです。

サーバーはデータをデコードし (クライアント以外のトラフィックは無視します)、クライアント ID をクライアント キャッシュのキーとして使用します。

大きなサーバー応答と空の TCP ACK を処理するために、クライアントとサーバーの両方で読み取りタイムアウトが使用されます。読み取りタイムアウトが経過すると、空のメッセージが送信されます。クライアントとサーバーの両方がアイドル タイムアウトを使用して、転送を停止し、ローカル リソースをクリーンアップします。

TLSトンネリング

相互認証を実装するには、プライベート認証局を使用します。

• 自己署名 CA 証明書は秘密キーから生成されます。
• サーバーの秘密キーはランダムに生成され、その公開部分は CA 証明書によって署名された証明書で使用されます。
• クライアント秘密キーはランダムに生成され、その公開部分は CA 証明書によって署名された証明書で使用されます。

クライアントとサーバーは両方とも、TLS ハンドシェイクでキーと証明書を使用するように構成されています。 CA 証明書はルート証明書として使用されます。

Server Name Indication 拡張機能が使用されているため、クライアントは特定のサーバー名を要求し、サーバーはその名前が要求された場合にのみ証明書を提供します。サーバー名も、たとえばサブジェクトの代替名として証明書の一部である必要があります。