•  untoreh-light

TCSplitter

TCPまたはUDP接続を複数のTCP接続に分割するトンネル

ゴール

1つのTCP接続を複数の接続に分割するのはいつですか。通常、あなたは トンネル 達成するために 正反対 。私の使用例は、モバイルネットワークの帯域幅制限を回避することでした。そのため、計画にデータが残っていないSIMカードを使用してテストを実行しました。[1].

それはどのように機能しますか

NS トンネル で書かれました golang それは十分に高速であり、ネットワークツールに一般的に使用されているためです。さまざまな方法をテストしたときにほとんどのオプションが作り直されたため、CLIはほとんど使用できません。

当初は、発信(フリング)と着信(投げ縄)の接続数を分割するための「フリング」と「ラッソス」がありましたが、主な目的は発信接続と着信接続に異なるレート制限を提供するため、アップ/ダウン間のより高いレベルの分離が実用的であるように思われました。

サーバーは発信接続を開くことができないと想定しているため、クライアントはすべての接続をインスタンス化する必要があります。クライアントがユーザーアプリケーションから接続を受信すると、サーバーとの接続に必要なプールを設定し、受信したデータが何であれ、ユーザー定義の制限に従って専用接続に分割します。

次に、パケットはサーバーに送信されます。サーバーは、異なるTCP接続がいつでもデータストリームを終了できるため、正しい順序に再構築する必要があります(送信された順序は尊重されません。 ルーティングのため )、受信アプリに転送されます。

接続ごとに構成されたデータ制限に達すると、接続が閉じられ、新しい接続が開かれます。 shadowsocksプロキシは、データストリームの動作をマスクすることを目的として、異なるストリーム間でデータをトンネルします。ただし、トンネルは可能な限り頻繁にデータストリームを実行します。

なぜそれが機能するのですか

ここでの目的は、すべての接続が処理するデータの量を制御することです。私たちの目的のために、それは通常を超えたことはありませんでした MTU ウィンドウサイズ。 MTUは、ネットワーク全体を通過するデータの上限と考えることができます。これは、ゲートネットワークの帯域幅レート制限をバイパスしたかったため、私たちの目標でした。クライアントが通過できるデータの量を制限するには、次のことを行う必要があります。 カウント それでしょ?ロジックが次のようなもので機能する場合do-while

次に、する必要があります 少なくとも 受け取るpacket 。これが実際に起こっているのか、それとも私のトンネルが機能する理由が別のものなのかはわかりません。最初のパケットでも完全にチェックできるかもしれませんが、設計の観点からは、チェックする必要があります。 毎日 単一の接続。これにより、システムはDOS攻撃に対して弱くなります。データを非常に小さなパケットに分割できるため、私のトンネルは効率的なDOS /ストレスツールとして簡単に使用できます(つまり、TCP接続のリサイクル圧力は高くなります)。 )そしてあなたが好きなだけ大きな接続のプールを持っています。

さまざまなポートでのテストでも、 いくつか ポート、および制限はポート間で常に異なり、443 周りの高い窓の1つを与える20kb 、推測するのでTLS ハンドシェイクにはより多くのデータが必要であり、これらのレート制限は時刻に基づいて変更されます[2].

結果

データスループットの向上を期待して、イレイジャーコーディングを試しました。イレイジャーコーディングライブラリを使用し、データ自体をenc /デコードすることにより、また、 KCP 私の分割プロトコル上のプロトコル。 KCPを試してみると、スループットが低下するので待ち時間が長くなるため、逆のアプローチに思えるかもしれませんが、最初の想定では、送信中に接続が切断されたためにボトルネックが発生し、多くのパケットが破損するため、より高いスループットを達成できたはずです。エラー訂正を伴うスループット。

クライアントがネットワーク経由で送信できるTCP接続の数に対するレート制限であることが判明したため、DOS保護だけで何もできません。 X回の接続後SYN 試みは彼らの期限を受け取るのをやめますACK 、バックログを埋め、最終的にトンネルをストールさせます。試行錯誤の結果、4-8[3] 接続はいつでも開いており、MTUは500-1000 少なくとも周りに安定したストリームを維持できるバイト128kbps 、一定のストリームが必要でない場合は、より短い期間でより高速を達成できます。 破裂 オンデマンドで多くの接続。

対照的に、(真)DNS トンネルはかろうじて押すことができます56kbps 多数のDNS要求は、TCP要求よりも疑わしいように見えるため、すぐに抑制される可能性があります。私たちはそれを指定する必要がありますtrue DNSトンネルは、偽のサブドメインを介して(送信)データをエンコードし、DNSレコードをクエリすることによって受信した(受信)データをデコードしますが、DNSトンネルはDNSポートを介した生のUDP接続と見なされる場合があります。許可され、正しく転送されます。

結論

目標を達成したかどうかわかりません 効用 賢明なことに、そのような種類のトンネルを実行すると、電話が非常に熱くなり、多くのバッテリーを浪費する可能性がありますが、バックアップ接続として使用すると安心できます...実際に十分に安定させるためにわざわざした場合:)

[1]通常、SIMカードにWebを閲覧するためのデータがなくなると、Web要求はキャプチャゲートウェイにリダイレクトされます(データを追加購入するように指示するため)。
[2]モバイルデータプランは、夜間の接続を改善できます
[3]この数は、一般的なコア数にいくらか一致しているため、カーネルが何らかの形で接続を制限しているのではないかと思われるかもしれません。トンネルの接続が開いているというシナリオは間違いなく珍しいですが、Linuxノブを調整しても私の側では良い結果は得られませんでした。

投稿タグ: