Toxメッセンジャーの分散された性質

著作権所有者が集中型Telegramブロックする一方で、分散型Toxメッセンジャーのユーザーコミュニティが成長しています。 今日、サイトwww.toxstats.comの統計によると、ロシアはユーザー数で米国に次ぐ第2位であり、わずか30〜50ノット遅れています。



この出版物では、このメッセンジャーの分散性、Tox DHTネットワークの一般原則、 およびノード数で「 アメリカに追いつき追い越す 」方法についてお話したいと思います。



toxロゴ










はじめに



各Toxノードは、そのIPアドレス、ポート番号、および256ビットの公開鍵によって識別されます。 ノードには2つの条件付きタイプがあります。





ノードの公開鍵は、このノードに送信されるパケットを暗号化するために使用されます。 パケットは、256ビットの秘密キーを使用してノード側で復号化されます。 UDPプロトコルは、DHTパケットの送信に使用されます。



Toxネットワークに「入る」には、すでにネットワーク上にあるToxノードとの接続があれば十分です。 通常、インターネット上の既知のブートストラップノードのリストがこれに使用されます。 さらに、 libtoxcoreライブラリは、ブロードキャストアドレスへのパケットの送信を使用します。これにより、インターネットに接続しなくてもToxネットワークに接続できます(ネットワークセグメントに必要なノードがある場合)。 また、インターネットにアクセスしなくても、2つ以上のToxノードが孤立したToxネットワークを形成し、ローカルクライアントが対話できるようにします。



DHTネットワークの自己組織化



各Toxノードには公開キーの形式の一意の識別子があるため、任意の2つのノード間の関係は、これらのキーに基づく人工的なメトリックとして表現できます。 このメトリックは、キー間の距離です。 距離は、2つのキー間のモジュロ2加算(ビット単位のXOR)として計算され、符号なし整数として解釈されます。



Xor








XOR演算のプロパティから、ゼロ距離は同じキー(ノードキー)の間のみになり、ノードキーに関するキースペース全体の半分は最大距離になります-いくつかの慣例では、そのようなキーを持つノードは「到達不能」と見なされます»また、同様のノードとの相互作用はかなりまれなイベントです。



Toxネットワークに入るプロセスは、「 Nodes request 」パケットを既知のブートストラップノード(1つ以上)に送信することから始まります。ここで、パケットのコンテンツは、求められた公開鍵です。 Nodes要求パケットを受信したノードは、既知の公開キーのうち、必要なキーから最短距離のキーを検索し(自身と要求されたキーを除く)、1から4個のキーと対応するノード(IP /ポート)。 クライアントノード応答からノードへの「ノード要求」要求を繰り返し繰り返すと、検索中のキーから最短距離で別のノードを見つけることができます(同時に、既存の中間ノードに関する情報を受信します)。



toxノードはタイムラインを要します








クライアントノードが自身のキーを検索キーとして示す場合、キー間の最小距離で見つかったノードは「隣接ノード」になります。 クライアントノードが要求されたノードのキーを必要なキーとして示し、検出されたノードが要求されたノードの隣接ノードである場合、これがネットワーク統計計算の仕組みです。



近隣ノードのトックス








既知の各ノードの活力は、「 Pingリクエスト 」パケットを定期的に送信することで確認されます。受信者はこれに「 Ping応答 」パケットで応答する必要があります。 さらに、クライアントノードは、一定の周期で「Nodes Request」パケットをランダムな(既知の)ノードに送信して、DHTネットワークの変更に関する情報を受信します。 応答しないノードは、タイムアウト後に既知のノードのリストから削除されます。



既知のノードの大きなリストに対して「Ping要求」パケットを頻繁に送信する必要があるため、不当なネットワーク負荷が発生します。 同時に、最近傍に関する情報のみを保存すると、不明なノードの検索時間が長くなります。 バランスをとるために、キーインデックスの概念がlibtoxcoreライブラリに導入されました。これは、ノードキーに関して最初に異なるキービットのインデックスです。 新しいキーごとに、そのインデックスが計算され、各インデックスごとに、カーネルは最大8つのキーを格納し、最大距離のキーを置き換えます。 さらに、カーネルは、同じ押し出しアルゴリズムで最近傍の8つのキーを保存します。



トックスノドデンデックス








現在のlibtoxcoreの実装では、インデックスの長さは128個の「バスケット」に制限されています。これにより、各ノードは1024ノードに関する情報を格納できます(ネットワークが非常に小さい間、それぞれ32バスケットと190ノードが使用されました)。 82バイトの最小パケットサイズ(「Ping要求」)で、60秒ごとに各ノードをポーリングすると、最大負荷インデックスで最大22Kビットのトラフィックが得られます。



バスケットインデックスの計算ルールから、2つのキー間の距離が小さいほど、インデックスのキーが大きくなり、そのようなキーを満たす可能性が低くなることもわかります。 libtoxcoreライブラリの実装では、127を超えるインデックスを持つキーは、距離に応じて「隣接」になるか、128番目のバスケットに分類されます。



トックスノードフルメッシュ








したがって、各Toxネットワークノードは、隣接ノードだけでなく、「最前線」のノードとも効果的な接続を維持し、ネットワーク負荷と他のノードの検索時間のバランスを維持します。



DHTネットワーククライアント



Tox DHTネットワークの任意のクライアントが知っている、または取得できるDHTノードとは異なり、クライアントアプリケーションは外部のオブザーバーから隠されています-連絡先(公開キーを含む)のToxIDを知っているだけでは、この連絡先の場所を確立することはできません。 2つのToxアプリケーションを接続するには、 タマネギルーティングメカニズムが使用されます。



2つのクライアント間の通信を確立するメカニズムは、次のように表すことができます。 2つのクライアント(AおよびZ)は、3つのランダムな中間DHTノードを介して最も近い(公開キーの)ノードで公開キーをアナウンスします。各ノードは、パケットルーティングでネイバーのみを認識しますが、パケットのコンテンツを読み取ることはできません。



トックスオニオンアナウンス








最初の(A)に接続したい2番目のクライアント(Z)も、3つのランダムなDHTノードを介して、目的のキー(A)に最も近いノードへの接続を確立する要求を行います。 2番目のクライアントからの要求。



玉ねぎリクレスト








最初のクライアント(A)は、接続要求を受け入れる場合、2番目のクライアント(Z)の最も近いDHTノードに対して逆の操作を実行します。



毒玉ねぎ反応








互いの場所と一時キーに関する情報を交換した後、クライアントは直接接続できます。



tox onion UDP接続続








クライアントが自分の場所に関する情報を連絡先と共有したくない場合、クライアントはTorのようなプロキシを通じてTCPリレーをサポートするノードを使用できます。



tox TCP接続続








TCPリレーの機能は、443(HTTPS)および3389(RDP)の「よく知られた」プロトコルを使用しようとすることです。これにより、追跡および識別が困難になります。



「追いつき、アメリカを追い抜く」



分散ネットワークをほとんどの既知の脅威から保護するために、単純な経験則を使用できます。ネットワーク内の信頼できるノードが多いほど、攻撃に対する耐性が高まります。 さらに、一部の種類の攻撃では、各信頼できるノードを無力化するには、12人または2人の攻撃者が必要です。



上記の説明に基づいて、Toxクライアントを使用する場合、すでにネットワークノードになっています(ただし、ノードはToxIDに接続されていませんが、両方が同じホスト上にあることを除きます)。 Toxをまだ使用していないが、プロジェクトを支援したい場合、ブートストラップノードをユーザーが制御するサーバーとコンピューターにインストールできます-古き良き時代のFolding @ homeとは異なり、大量のトラフィックやコンピューティングリソースを消費しません。



ノードのアセンブリとインストールの詳細な説明は、「 Toxコミュニティに参加するか、5分でノードをインストールする 」リンクに記載されています 。 ただし、ほとんどの一般的なLinuxディストリビューション用にtox-easy-bootstrapパッケージをコンパイルすることにより、このプロセスを可能な限り簡素化しようとしました。



tox-easy-bootstrapパッケージをインストールするには、プロジェクトリポジトリへのリンクに従って、ディストリビューションを選択し、簡単な指示に従ってリポジトリを追加し、システムにパッケージをインストールします。



パッケージインストーラーは、パブリックブートストラップノードの最新リストを自動的に受け取り、構成ファイル/etc/tox-bootstrapd.confを作成し、別のシステムユーザーの下でtox-bootstrapdデーモンを起動します。 cronによって週に1回、特別なスクリプトが構成ファイル内のパブリックブートストラップノードのリストを更新するため、サーバーの再起動(「設定して忘れる」)の際にその関連性を心配する必要はありません。



サーバーが「通常閉じている」ファイアウォールを使用する場合、UDP:33445およびTCP:3389,33445(TCPポート:443は使用されません。プロセスは特権のないユーザーの下で開始されるため)で受信トラフィックのルールを許可する必要があります-潜在的な「破壊」を回避するために、この部分を自動化しませんでした。



-A INPUT -p tcp --dport 3389 -j ACCEPT

-A INPUT -p tcp --dport 33445 -j ACCEPT

-A INPUT -p udp --dport 33445 -j ACCEPT







パッケージ/etc/tox-easy-bootstrap.confの構成ファイルを使用すると、デフォルト設定(ほとんどの場合に適しています)を変更できます。たとえば、すべてのパブリックノードが使用できない場合にプライベートノードのいくつかを「リンク」します。ネットワーク内の任意の1つのノードが、ネットワーク内の2番目のノードにアクセスします。



パブリックノードリストにあるノードに関するデータを公開するかどうかの問題は、個人の判断に委ねられます。技術的な観点から、プライベートノードはパブリックノードと変わりません。



おわりに



Toxプロトコルを使用すると、 ボットの作成 、メッセージ、ファイルの交換、または音声ビデオ通話を行うだけでなく、他のネットワークタスクの基本プロトコルとしても使用できます。



そのため、たとえば、 tuntoxおよびtoxvpnプロジェクトはToxプロトコルを使用して、 フルメッシュVPNソリューションのリストに追加するNATのP2Pホスト接続を編成します。



メールメッセージを整理するための実験的なtoxmailプロジェクト、リモートデスクトップにアクセスするためのtoxscreen 、信頼できる人々の間でファイルを共有するためのtoxshareがあります。



新しいアプリケーションを書く実験のために、他の言語やプラットフォームのラッパー(サポートされているがあまりサポートされていない)を使用できます: pythonrustgonode.js-新しいアイデアやプロジェクトのためのほぼ無限のスコープ



参照資料






All Articles