udsオープンソーストンネルソフトウェアの説明

プロジェクトのアドレス#

注：開発者の発言は個人の意見を代表するものであり、コードはオープンソースであり、プロトコルに関する追加の説明は提供されません。

プロジェクトの特性#

利点
- 既存の TCP プロキシツールとシームレスに統合できる
- 検出、報告、スニッフィングに対抗する
- 平文モードでは中継デバイスのパフォーマンスにほとんど負荷がかからない
- コードはオープンソースであり、DPDK、eBPF などの技術を使用して大容量スループットを実現するために自分で変更できる
- 現在のすべてのファイアウォールの弱点に対処する（つまり、TCP の三元 / 四元組を使用して接続を追跡する）
欠点
- 暗号化されていない場合、バイナリマッチングに対して無力です
- 暗号化されたストリームはファイアウォールがトラフィックに対してより注意を払うため、遅延が増加したりパケットがドロップしたりすることがありますが、5TB の単方向ではポートブロックは発生しません。
- DDoS 緩和メカニズムの誤判定を引き起こし、トラフィックをブロックしたり既存の接続をリセットしたりする可能性があります。
おもちゃ

このプロジェクトは、作者のおもちゃであり、概念の検証であり、継続的なメンテナンスは行われません。

オープンの理由は、現在の環境に新しいアイデアを提供するためだけです。

実装#

イントロダクション#

現在、インターネット上には多くのフリーゲートウェイプロトコルがありますが、実装のレベルはまちまちですが、それぞれに問題があります。Shadowsocks をはじめとする完全な暗号化ストリームは、アクティブなスニッフィングと完全ランダムトラフィックの正確な識別の問題を解決した後も、まだ多くの人々の選択肢です。R 氏が開発したさまざまな TLS ベースのトリックは、個人のトラフィックが森の中の木を隠すことに成功しました。

しかし、これらのプロトコルは実際の適用の過程でまだ自分自身の弱点を持っています：ファイアウォールが審査、監視などの機能をエッジデバイスにオフロードするようになった今日、個人のユーザーデバイスからの完全な暗号化トラフィックは、コミュニティエリアネットワークの中の明るい光のようなものです。一般のユーザーは、R 氏が提供する証明書のスティール機能を中継デバイスで使用するときに、監視と監視の信管局からのスニッフィングを忘れがちです。

そして、両方の設計アイデアには深刻な問題があります：暗号化のオーバーヘッド。ほとんどのプロキシツールのクライアントデバイスは、5 年前に製造された CPU と完全な物理デバイスパフォーマンスを使用しており、OpenSSL 暗号化スイートの実行に必要なパフォーマンスを簡単に提供できます。一方、サーバー側は、厳格に制限されたパフォーマンスを持つ仮想ホストです。より高いスループット帯域幅を実現するために、主流の 1 コア 512MB の構成は既に制約があります。一般的な開発言語である Golang は、サーバーに対してメモリのオーバーヘッドをさらに増加させます。

目的#

ファイアウォールがトラフィックを監視する原理に基づいてプロトコルを設計し、サーバー側の暗号化強度を低下させることがこのプロジェクトの主な目標です。過去のさまざまなオープンソースプロジェクトを振り返った後、痛ましい事実が浮かび上がりました - 過去に提案された西厢計画は、現在、ファイアウォールの識別を回避し、外部ネットワークにアクセスする唯一の原理レベルのプロジェクトです。

現在の状況では、このような脆弱性をほとんど見つけることは不可能であり、ファイアウォールがトラフィックを識別する原理に基づいて処理する必要があります。現代のファイアウォールおよび市販のファイアウォールのトラフィックスニッフィングは、三元組またはより詳細な四元組に基づいています。

ひとつのアイデアが私たちの頭に浮かび上がりました：元々の三元組を 2 つの異なる三元組に分割した後、ファイアウォールはまだ内部パケットを関連付けたり監視したりする能力を持っているのでしょうか？

設計思想#

内部では、usenix23 で列挙されたファイアウォールトラフィックの免除ルールやそれ以上のものを事前にまとめていました。ほぼすべてのルールに合致するほぼ完全なハンドシェイク応答を設計しました。すべての印刷可能なバイトで構成され、文字レベルでランダムであり、バイナリレベルで低エントロピーです。

パブリック IP がないシナリオを考慮して、この設計ではすべての接続がクライアントがアクティブに確立し、データがサーバーに転送された後にマージされます。

一部の省市および特定の場所で使用されるファイアウォールおよびルールにはバイナリマッチングの能力がある可能性があるため、このプロトコルにはオプションの暗号化スイートも組み込まれています。

不足点#

平文のハンドシェイクパケットを使用してファイアウォールがこの TCP 接続を初期段階で無視するようにするが、この三元組の遅延増加度合いとパケットのドロップ状況を継続的に検出することはできず、大量のトラフィックの場合に現在発見されていない探査メカニズムが存在するかどうかを確認することはできません。
明示的なハンドシェイクパケットを使用してファイアウォールがこの TCP 接続を初期段階で無視するようにするが、この三元組の遅延増加度合いとパケットのドロップ状況を継続的に検出することはできず、大量のトラフィックの場合に現在発見されていない探査メカニズムが存在するかどうかを確認することはできません。
48 時間ほどの連続稼働後、モバイルは直接リンクをブロックしますが、どのメカニズムがトリガーされたのかはわかりません。電信と通信には異常はありません。
明示的なハンドシェイクパケットを使用してファイアウォールがこの TCP 接続を初期段階で無視するようにするが、この三元組の遅延増加度合いとパケットのドロップ状況を継続的に検出することはできず、大量のトラフィックの場合に現在発見されていない探査メカニズムが存在するかどうかを確認することはできません。

設定ファイル#

サンプル#

[app]
alignment=4096
mode=client
ip=::
port=30000
inbound-ip=localhost
inbound-port=10000
outbound-ip=localhost
outbound-port=20000
turbo=true
backlog=511
fast-open=true
keep-alived=true
connect.timeout=10
handshake.timeout=5
protocol=tcp

その他の設定については samples ディレクトリを参照してください。

パラメータの説明#

alignment

alignment_malloc メモリアライメントパラメータ
mode

実行モード、[client, server]
ip

実行モードが client の場合、リッスンする IP を指定します。実行モードが server の場合、元の宛先 IP を指定します。
port

実行モードが client の場合、リッスンするポートを指定します。実行モードが server の場合、元の宛先ポートを指定します。
inbound-ip

上行リンクをホストするために使用する TCP 接続に設定します。
inbound-port

上行リンクをホストするために使用する TCP 接続のポートを設定します。
outbound-ip

下行リンクをホストするために使用する TCP 接続に設定します。
outbound-port

下行リンクをホストするために使用する TCP 接続のポートを設定します。
turbo

TCP 接続の高速化
backlog

TCP 接続のバックログパラメータ
fast-open

TCP-Fast-Open を有効にする
keep-alived

TCP Keep-alive を有効にする
connect.timeout

TCP タイムアウト時間を設定します
handshake.timeout

プロトコルのハンドシェイクのタイムアウト時間を設定します
protocol

トランスポートプロトコル、TCP はハンドシェイクパケット以外は暗号化されません。

使用例#

warp+uds#

Cloudflare が提供する warp は、国際ルーティングを改善し、送信される可能性を減らすために、ネットワーク品質の低い仮想ホストにデプロイされるツールとしてよく使用されます。Cloudflare は、ほとんどの Linux ディストリビューションに対してパッケージマネージャーを介したインストール方法を提供しています。

WARP のインストール
ここでは、Cloudflare 公式チュートリアルを参照してください。
モードの切り替え
WARP を正常にインストールし、クライアントを登録した後、クライアントの実行モードをプロキシモードに切り替えます。
```
warp-cli set-mode proxy
```
WARP が使用するポートの変更（オプション）
WARP はプロキシモードでデフォルトで 1080 ポートをリッスンします。
```
warp-cli set-proxy-port [PORT]
```
WARP はデフォルトで 127.0.0.1 上のポートのみをリッスンするため、この socks5 ポートがスキャンされる心配はありません。
UDS サーバーの起動
次のような設定ファイルを使用します

[app]
alignment=4096
mode=server
ip=127.0.0.1
port=1080
inbound-ip=::
inbound-port=10000
outbound-ip=::
outbound-port=20000
turbo=true
backlog=511
fast-open=true
keep-alived=true
connect.timeout=10
handshake.timeout=5
protocol=tcp

UDS サーバーを起動します

./udss --config=config.ini

UDS クライアントの起動

[app]
alignment=4096
mode=client
ip=127.0.0.1
port=1080
inbound-ip=[remote IP]
inbound-port=10000
outbound-ip=[remote IP]
outbound-port=20000
turbo=true
backlog=511
fast-open=true
keep-alived=true
connect.timeout=10
handshake.timeout=5
protocol=tcp

接続
好きなツールで socks5://127.0.0.1:1080 に接続してください

Dante + UDS#

Cloudflare のように、国際ルーティングを改善し、送信される可能性を減らすために、ネットワーク品質の低い仮想ホストにデプロイされるツールとしてよく使用されます。Cloudflare は、ほとんどの Linux ディストリビューションに対してパッケージマネージャーを介したインストール方法を提供しています。

操作手順は warp と非常に似ているため、ここでは省略します。

既存の中継接続への UDS の統合#

テスト中は vless データストリームを暗号化せずに中継できます

ターゲットデバイスで udss をダウンロードします
サーバーサイドのターゲットポートを元のプロキシのリッスンポートに設定します
中継サーバーで udsc をダウンロードします
クライアント側の上りリンクと下りリンクをサーバーと対応させます
クライアント側のリッスンアドレスとポートを設定します

スムーズな移行が必要な場合は、元のポートを使用しないでください。UDS を起動する前に元のサービスを停止することをお勧めします。
UDS クライアントを起動します

結論#

uds は概念実装に過ぎず、本番環境での大規模な使用はお勧めしません。また、UDP over TCP の転送シナリオには適していません。UDP トラフィックが必要な場合は、コードを変更して実装してください。

uds のすべてのコードは MIT ライセンスに従います。