GFW の原理#
GFW に対抗するためには、何がアクセスできないか、何がアクセスできるかといった表面的な現象にとどまってはいけません。YouTube がアクセスできないことを知っても、翻墙には役立ちません。しかし、GFW がどのようにして私たちが YouTube にアクセスできないようにしているのかを知ることは、次の翻墙の選択と実施において重要な意味を持ちます。したがって、翻墙の方法を議論する前に、GFW がどのように封鎖しているのか、その原理を深く理解する必要があります。
一般的に、GFW は分散型の侵入検知システムであり、厳密な意味でのファイアウォールではありません。出入国の IP パケットがすべて GFW を通過する必要があるわけではありません。侵入検知システムとして、GFW はあなたが Facebook にアクセスするたびにそれを侵入と見なし、侵入を検知した後に対策を講じます。これが一般的な接続リセットです。
検知には 2 つの方法があります。一つは人工検知、もう一つは機械検知です。国新办のウェブサイトに通報することは、人工検知に参加することを意味します。人工検知で不和諧なウェブサイトが発見されると、国内のネットユーザーがそのウェブサイトにアクセスできないようにするための対策が講じられます。この種の封鎖に対しては、検知を回避することは技術的な問題ではなく、GFW が講じる対策に対して反制措置を取るしかありません。もう一つの検知は機械検知で、その検知プロセスはさらに細分化できます：
再構築とは、GFW がネットワーク上で過去の IP パケットを監視し、その中の TCP プロトコルを分析して、最終的に完全なバイトストリームを再構築することを指します。分析はこの再構築されたバイトストリーム上で具体的なアプリケーションプロトコル、例えば HTTP プロトコルを分析します。そして、アプリケーションプロトコルの中で不和諧な内容がないかを探し、どのような対策を講じるかを決定します。
したがって、GFW の機械検知の第一歩はバイトストリームを再構築することです。では、GFW はどのようにして元の IP パケットを取得するのでしょうか？本当の GFW の展開方法は、外部の人間には全くわかりません。推測によれば、GFW は国家の出口ルーターのバイパスに展開されており、「分光」の方法で IP パケットをコピーして別の光ファイバーに送ることで、すべての出入国の IP パケットを取得しています。下の図は gfwrev.blogspot.com からの引用です：
しかし、Google は北京に自社のデータセンターを持っています。そこで賢いネットユーザーは Google の北京データセンターが提供する GAE サービスを利用し、Goagent ソフトウェアを使って高速に翻墙を実現しています。しかし、あるユーザーは確認しました https://twitter.com/chengr28/status/260970749190365184 、北京のデータセンターでもバックボーンネットワークでパケットが失われることがあると。実際、Google の北京の谷翔データセンターには独立した AS（BGP の概念）が存在します。この AS は Google 本社と IPV6 の直接接続ラインを持っているため、このデータセンターを通じて IPV6 で制限を受けずに外に出ることができます。しかし、この AS は国内外の接続に関しても GFW を経由する必要があります。したがって、データセンターが北京にあっても、国内からのアクセスが壁に阻まれないことは保証されません。GFW はバックボーンネットワークの BGP ルーティングルールを設定することで、国内のデータセンターもそれを経由させることができます。もう一つの例は、私たちが封鎖されたウェブサイトにアクセスしたときに接続リセットがトリガーされると、しばしば 2 つの RST パケットを受け取りますが、TTL が異なります。もう一つの例は、封鎖された IP に対して、アクセスする IP パケットが国際出口に到達する前にすでに破棄されていることです。したがって、GFW は他の場所にもデバイスを展開していると考えられ、推測では省レベルのバックボーンルーターに配置されているとされています。
GFW がどこにあるのかという話題について、最近外国の友人が興味を示しました https://github.com/mothran/mongol。筆者は先人の研究を基に、より完全な検出ツールを作成しました https://github.com/fqrouter/qiang。その原理は、TTL という IP プロトコルの特性に基づいています。TTL は Time to Live の略です。IP パケットがルーティングを 1 回通過するたびに、ルーターは IP パケットの TTL を 1 減らします。TTL がゼロになると、ルーターは IP パケットを次のルーターに送信しなくなります。そして、GFW は不和諧な IP パケットを監視した後に RST パケットを返して TCP 接続をリセットすることがわかっています。したがって、異なる TTL を設定することで、あなたのコンピュータから GFW までにいくつのルーターを経由したかを知ることができます。例えば、TTL を 9 に設定すると RST をトリガーしませんが、10 にすると RST をトリガーします。つまり、GFW までに 10 個のルーターを経由したことになります。もう一つの IP プロトコルの特性は、TTL が尽きたときにルーターが TTL EXCEEDED の ICMP パケットを返し、自分の IP アドレスを SRC（ソース）として設定することです。この 2 つの点を組み合わせることで、IP パケットがどの IP アドレスのルーターに到達した後に GFW に検知されたのかを探ることができます。IP アドレスがわかれば、IP アドレスの地理的位置データベースと組み合わせることで、その地理的位置を知ることができます。得られた位置はおおよそ以下のようになります：
しかし、ここで検出された IP が GFW のものなのか、バックボーンルーターのものなのかはどうでしょうか？より可能性が高いのはバックボーンルーターの IP です。GFW はデバイスとして「分光」の方法でメインバックボーンルーターの隣に設置され、侵入検知を行っています。いずれにせよ、GFW は何らかの神秘的な方法で、あなたと国外のサーバー間のすべての IP パケットを取得することができることは確かです。より厳密な理論研究としては：Internet Censorship in China: Where Does the Filtering Occur?
GFW はこれらの IP パケットを取得した後、難しい決定を下す必要があります。それは、あなたとサーバー間の通信を続けるべきかどうかです。GFW はあまりにも過激になってはいけません。全国的に国外のウェブサイトにアクセスできないことは、GFW 自身の存在価値に反するからです。GFW は IP パケットの背後にある意味を理解した上で、あなたと国外のサーバー間の接続を安全に遮断できるかどうかを決定する必要があります。この理解は、前述の「再構築」というステップに基づいています。おおよそ図で表現すると、再構築がどのようなものであるかは以下の通りです：
再構築で行うべきことは、IP パケット 1 の GET /inde と IP パケット 2 の x.html H と IP パケット 3 の TTP/1.1 を組み合わせて GET /index.html HTTP/1.1 にすることです。組み立てられたデータは純テキストである可能性もあれば、バイナリ暗号化されたプロトコル内容である可能性もあります。具体的に何であるかは、あなたとサーバー間で合意されたものです。GFW は盗聴者として、あなたたちの会話内容を推測する必要があります。HTTP プロトコルについては非常に推測しやすいです。なぜなら、HTTP プロトコルは標準化されており、暗号化されていないからです。したがって、GFW は再構築後にあなたが HTTP プロトコルを使用していること、どのウェブサイトにアクセスしているのかを簡単に知ることができます。
このようなバイトストリームを再構築する際の難点は、膨大なトラフィックをどのように処理するかです。この問題については、このブログ http://gfwrev.blogspot.tw/2010/02/gfw.html で明確に説明されています。その原理はウェブサイトの負荷分散器と同様です。特定のソースとターゲットに対して、HASH アルゴリズムを使用してノード値を取得し、そのソースとターゲットに一致するすべてのトラフィックをそのノードに送信します。したがって、1 つのノードで TCP セッションの一方向バイトストリームを再構築できます。
最後に、議論を完全にするために、2 つの点を挙げます。GFW の再構築はバイパスで行われるため、分光によって実現されていますが、すべての GFW デバイスがバイパスにあるわけではありません。後で述べるように、GFW の一部の対策は、いくつかの GFW デバイスをメインバックボーンルーターに展開する必要があります。例えば、Google の HTTPS に対する断続的なパケットロスは、GFW が一部の IP のルーティング作業に関与していることを示しています。もう一つの点は、再構築は一方向の TCP ストリームであり、GFW は双方向の対話内容を気にしないということです。GFW は、監視された一方向の内容に基づいて判断を行います。しかし、監視自体は双方向であり、国内から国外に送信される場合でも、国外から国内に送信される場合でも、再構築されて分析されます。したがって、GFW にとって 1 つの TCP 接続は 2 つのバイトストリームに再構築されます。具体的な証拠は、後で GFW を直通する方法について詳しく説明します。
分析#
分析は、GFW がバイトストリームを再構築した後に行う第二のステップです。再構築に関しては、GFW は主に IP プロトコルとその上の TCP および UDP プロトコルを処理すればよいのですが、分析に関しては、GFW はさまざまなアプリケーション層の奇妙なプロトコルを理解する必要があります。さらには、私たち自身が新しいプロトコルを発明することもできます。
一般的に、GFW がプロトコル分析を行う目的は 2 つあり、似ていますが異なります。第一の目的は、不和諧な内容の拡散を防ぐことです。例えば、Google で「検索してはいけない」キーワードを検索することです。第二の目的は、翻墙ツールを使用して GFW の検閲を回避することを防ぐことです。以下に、GFW が処理できることが知られているプロトコルをいくつか挙げます。
GFW がどのようにして目的を達成するか、つまり不和諧な内容の拡散を防ぐことは、HTTP プロトコルや DNS プロトコルなどのいくつかのプロトコルの明文検査に関係しています。大まかな方法は以下の通りです。
HTTP のようなプロトコルは非常に明確な特徴を持っているため、第一歩は特に言うことはありません。GFW がパケットが HTTP パケットであることを発見すると、HTTP のプロトコルルールに従ってパケットを分解します。この分解プロセスは、GFW がプロトコルを理解する方法に基づいています。例えば、HTTP の GET リクエストからリクエストの URL を取得します。次に、GFW はこのリクエストの URL を使用してキーワードと照合します。例えば、リクエストの URL に Twitter が含まれているかを確認します。なぜ分解プロセスが必要なのでしょうか？まず、分解することでより正確に攻撃でき、誤検知を防ぐことができます。また、事前に分解することで、全文照合よりもリソースを節約できます。次に、xiaoxia と liruqi の同級生の jjproxy のコアは、GFW の HTTP パケット分解の脆弱性に基づいていますが、もちろんこのバグは修正されています。その原理は、GFW が HTTP パケットを分解する際に余分な \r\n のような状況を処理しなかったことですが、あなたがアクセスする google.com は余分な \r\n の状況を正しく処理できます。この例から、GFW はまずプロトコルを理解し、その後にキーワード照合を行うことが証明されます。キーワード照合は、いくつかの効率的な正規表現アルゴリズムを使用していると思われ、特に議論の余地はありません。
HTTP プロキシと SOCKS プロキシの 2 つの明文プロキシは、GFW によって識別される可能性があります。以前、筆者は GFW が HTTP プロキシと SOCKS プロキシを認識した後、その内部の HTTP プロトコルの本文を分解することができると考えていました。つまり、2 回の分解を行うということです。しかし、分析の結果、HTTP プロキシのキーワードリストと HTTP のキーワードリストは異なるため、筆者は現在、HTTP プロキシプロトコルと SOCKS プロキシプロトコルは別々のプロトコルとして処理されていると考えています。つまり、HTTP リクエストのペイロードを分解してから分析するのではありません。
現在知られている GFW が行うプロトコル分析は以下の通りです：
DNS クエリ#
GFW は 53 ポートの UDP プロトコルの DNS クエリを分析できます。クエリのドメイン名がキーワードと一致する場合、DNS ハイジャックが行われます。このマッチングプロセスは、正規表現に似たメカニズムを使用していることは確かで、単なるブラックリストではありません。なぜなら、サブドメインが非常に多いためです。証拠として、2012 年 11 月 9 日午後 3 時半から、防火長城は Google の汎用ドメイン .google.com に対して大規模な汚染を行い、すべての .google.com で終わるドメインが汚染され、正常にアクセスできなくなりました。その中には存在しないドメインも含まれています（出典 http://zh.wikipedia.org/wiki/%E5%9F%9F%E5%90%8D%E5%8A%AB%E6%8C%81）
現在まで、53 ポート以外のクエリはハイジャックされていません。しかし、TCP の DNS クエリはすでに TCP RST で切断できることが示されており、GFW にはそのような能力があることを示していますが、大規模に展開することには興味がないようです。また、TCP クエリのキーワードは UDP ハイジャックのドメインよりもはるかに少ないです。現在、dl.dropbox.com だけが TCP RST をトリガーします。関連する研究論文は以下の通りです：
Hold-On: Protecting Against On-Path DNS Poisoning
The Great DNS Wall of China
HTTP リクエスト#
GFW は HTTP プロトコルを識別し、GET の URL と HOST をチェックできます。キーワードと一致する場合、TCP RST がトリガーされて遮断されます。前述の jjproxy が使用する特殊な HTTP GET リクエストを構築して GFW を欺く方法はすでに無効になっています。現在、GFW は \r\n を見ただけで直接 TCP RST で遮断します（出典 https://plus.google.com/u/0/108661470402896863593/posts/6U6Q492M3yY）。関連する研究論文は以下の通りです：
The Great Firewall Revealed
Ignoring the Great Firewall of China
ConceptDoppler: A Weather Tracker for Internet Censorship
翻墙トラフィックの分析識別#
GFW の第二の目的は、翻墙ソフトウェアを封じ込めることです。この目的を達成するために、GFW が採用する手段はより暴力的です。理由は簡単で、HTTP プロトコルの封鎖がうまくいかないと、インターネットの正常な運用に影響を与えるからです。GFW はインターネットと共生しており、自らの存在を脅かすようなことはしません。しかし、TOR のようなほぼ純粋に翻墙のために存在するプロトコルは、検出されれば即座に排除されます。GFW がさまざまな翻墙プロトコルをどのように封じ込めるかについては、私もあまり詳しくはありませんが、事態は常に更新されています。しかし、GFW の高度な技術を証明するために 2 つの例を挙げます。
最初の例は、GFW が TOR を自動的に封じ込めることです。これは GFW がプロトコル自体を理解しようと最大限努力していることを示しています。このブログ https://blog.torproject.org/blog/knock-knock-knockin-bridges-doors によれば、中国の IP を使用してアメリカの TOR ブリッジに接続すると、GFW に発見されます。その後、GFW は（15 分後に）クライアントのふりをして、TOR プロトコルを使用してそのブリッジに接続します。もしそれが TOR のブリッジであることが確認されれば、そのポートが封じられます。ポートを変更すると、しばらくの間は使用できますが、再び封じられます。これは GFW がプロトコルの高度な検出能力を持っていることを示しており、国際出口のトラフィックからあなたが接続している TOR ブリッジを敏感に発見することができます。TOR の仲間によれば、これは TOR プロトコルのハンドシェイクプロセスが非常に明確な特徴を持っているからだそうです。もう一つの点は、GFW が自らクライアントのふりをして接続を試みるほどの努力をしていることです。
第二の例は、GFW が暗号化されたトラフィックの具体的な内容に敏感な単語が含まれているかどうかを気にしないことを示しています。疑わしい翻墙、特に複数の翻墙に商業サービスを提供している場合は、封じ込められます。この投稿 http://www.v2ex.com/t/55531 によれば、使用されている ShadowSocks プロトコルは、事前にキーをデプロイし、明確なハンドシェイクプロセスがなくても封じ込められます。GFW はすでに機械的にどの暗号化されたトラフィックが疑わしい翻墙サービスであるかを識別できるようにアップグレードされたと言われています。
GFW がどのようにして翻墙サーバーを識別し封鎖するかについて、最近私の推測を提起した記事を書きましたので、皆さんも見てみてください：http://fqrouter.tumblr.com/post/45969604783/gfw。
最近、GFW は OpenVPN と SSL 証明書に対してほぼリアルタイムで IP（ポート）を封じ込めることができるようになりました。その原理は、オフラインで深いパケット分析を行い、疑わしい IP リストを抽出し、人工確認の後に IP を封じ込めるというものです。OpenVPN は顕著なプロトコルの特徴を持っており、商業シーンではほとんど使用されないため、翻墙サービスであることを確認するのは非常に簡単です。しかし、SSL、つまり HTTPS で使用される暗号化プロトコルも「証明書」に基づいてフィルタリングされることは、驚くべきことです。Shadowsocks の作者 Clowwindy は、これに関して「なぜ SSL を使用して翻墙すべきではないのか」という記事を特別に書きました：https://gist.github.com/clowwindy/5947691。
要約すると、GFW はすでに目的のすべての作業をほぼ完了しています。明文のプロトコルは HTTP から SMTP まで分析され、キーワード検出が行われています。さらには、あまり一般的でないプロトコルである電驴さえも GFW は扱っています。原理的には、明文、分解、キーワードということです。GFW の最近の作業の重点は、ネットワークトラフィックの分析にあり、どのトラフィックが翻墙であるかを識別することです。この分野の研究はまだ少なく、顕著な特徴は、自分が使用する分には問題ないが、大規模に展開すると問題が発生しやすいということです。私は現在、GFW がどのように翻墙ツールを封じ込めるかについて多くの研究を行っているわけではなく、ただの噂を聞いているだけです。
対策#
IP 封鎖#
一般的には、人工検知の後の対応としてよく見られます。GFW の機械検知が直接 IP を封じ込める方法はまだ聞いたことがありません。一般的な現象は、GFW が機械検知を行い、その後 TCP RST でリセットすることです。しばらく経ってから IP が封じ込められ、明確な時間の規則はありません。したがって、私の推測では、全体的な IP 封鎖は人工的な介入が必要なものだと思われます。全体的な IP 封鎖と対照的なのは部分的な IP 封鎖で、例えば、あなたがその IP にアクセスした場合に 3 分間だけ封じ込められるが、他の人はアクセスできるというものです。これは完全に異なる封鎖方法であり、現象は似ていますが、ping も ping できないということです。観察したい場合は、twitter.com を ping すればいいでしょう。すでに長い間封じ込められています。
その実現方法は、無効なルーティングブラックホールをメインバックボーンルーターのルーティングテーブルに追加し、これらのバックボーン上のルーターに GFW が指定した IP へのパケットを破棄させることです。ルーターのルーティングテーブルは動的に更新され、使用されるプロトコルは BGP プロトコルです。GFW は封じ込められた IP のリストを維持し、BGP プロトコルを使用してそれを広めるだけで済みます。すると、国内のバックボーンネットワークのルーターは、まるで GFW の一部であるかのように、GFW の手助けをすることになります。
もし私たちが traceroute を使用してこのように全体的に封じ込められた IP をチェックすると、IP パケットが GFW の国際出口に到達する前に、すでに電信または聯通のルーターによって破棄されていることがわかります。これが BGP の広報の効果です。
DNS ハイジャック#
これもまた、人工検知の後の一般的な対応です。人工的に不和諧なウェブサイトを発見し、そのウェブサイトのドメイン名をハイジャックリストに追加します。その原理は、DNS と IP プロトコルの弱点に基づいています。DNS と IP の両方のプロトコルはサーバーの権威を検証せず、DNS クライアントは最初に受け取った答えを盲目的に信じます。したがって、あなたが facebook.com を検索すると、GFW は正しい答えが返される前に応答し、あなたが検索した DNS サーバーのふりをして間違った答えを返すことができます。
TCP RST 遮断#
TCP プロトコルは、RST パケットを見た場合、接続が直ちに中断されることを規定しています。ブラウザから見ると、接続がリセットされたことになります。このエラーについては、皆さんもおなじみでしょう。私の個人的な感覚では、この封鎖方法は GFW の現在の主要な対応手段です。ほとんどの RST は条件トリガーであり、例えば URL に特定のキーワードが含まれている場合です。現在、この待遇を受けているウェブサイトは非常に多く、著名なものには Facebook があります。また、いくつかのウェブサイトは無条件に RST されます。つまり、特定の IP とポートに対して、パケットの内容に関係なく RST がトリガーされます。比較的著名な例は、HTTPS の Wikipedia です。GFW の TCP 層での対応は、IPv4 プロトコルの弱点を利用しており、ネットワーク上にいる限り、誰にでもなりすますことができます。したがって、GFW は非常に簡単にあなたに RST が確かに Google からのものであると信じさせ、Google に RST があなたからのものであると信じさせることができます。
ポート封鎖#
GFW は、主にバックボーンルーターの隣に設置された侵入検知デバイスとして機能し、分光技術を使用してこのバックボーンルーターからパケットを取得して侵入検知を行っています（いわゆる IDS）。その上、このルーターはポートを封じ込めるためにも使用されます（いわゆる IPS）。GFW は侵入を検知すると、現在の接続を TCP RST で遮断するだけでなく、バックボーンルーターを利用して特定の IP またはポートに対して、ポート封鎖から IP 封鎖、選択的パケット破棄などのさまざまな封じ込め措置を設定できます。これは、バックボーンルーター上に「iptables」のような能力があることを意味します（ネットワーク層とトランスポート層のリアルタイム分解、マッチングルールの能力）。この iptables の能力は CISCO ルーター上では ACL Based Forwarding (ABF) と呼ばれています。また、ルールの展開は全国的に同期しており、1 台のルーターがあなたのポートを封じ込めると、全国の GFW が設置されたバックボーンルーターがそのルールを適用します。一般的に、このポート封鎖は翻墙サーバーに対して行われ、SSH や VPN などの方法で翻墙サービスを提供しているサーバーが検知されると、GFW は全国の出口バックボーンルーターにこの ACL ルールを展開し、そのサーバーとポートの下りデータパケットを封じ込めます。つまり、パケットが国外から国内に送信され、src（ソース IP）が封じられたサーバーの IP で、sport（ソースポート）が封じられたポートである場合、そのパケットはフィルタリングされます。このように展開されたルールの特徴は、上りのデータパケットはサーバーに届くことができ、下りのデータパケットはフィルタリングされることです。
もし封じられたポートの後にサーバーがポートを変更する対応を取ると、すぐに再び封じられます。また、何度も試みた後には IP が封じられます。初歩的な推測として、ポート封鎖は GFW の自動的な対応行動ではなく、ブラックリストと人工フィルタリングの方法で実現されていると思われます。推測の理由は、ネットユーザーの報告によれば、ポート封鎖はすべて昼間の勤務時間に発生するからです。
逆壁#
大部分の空港が使用する国内の中継サーバーは、GFW が非常に異常な国外の大量トラフィックを検知すると、特別な時期、例えば全国人民代表大会や国慶節の期間中に、そのサーバーを逆壁にします。具体的には、国外のサーバーがその逆壁にされた IP にアクセスできなくなることを示します。この国内サーバーの ping を測定すると、国外は一面赤く、国内は一面緑になります。解決策はあまり多くなく、IP を変更するか、敏感な時期が過ぎるのを待つか、自然に回復するのを待つことです。
翻墙の原理#
前述の GFW の運用原理に基づいて、翻墙の原理はそれに対応して 2 つの大きなカテゴリに分かれます。第一のカテゴリは、一般的に使用される迂回の方法です。IP パケットは第三者を介して暗号化された形式で GFW の検査を通過します。このような方法は「翻」壁に似ており、壁の外から回り込むものです。第二のカテゴリは、GFW の検知プロセスの中のいくつかのバグを見つけ出し、これらのバグを利用して GFW が正確なセッション内容を把握できないようにして通過させることです。
迂回法に基づく翻墙方法は、VPN でも SOCKS プロキシでも、原理は似ています。すべて、国外にプロキシサーバーがあることを前提とし、あなたがプロキシサーバーと通信し、プロキシサーバーがターゲットサーバーと通信します。
基本的な http L2TP sock5 などのプロキシプロトコルに加えて、現在主流の翻墙アクセス国外ウェブサイトのプロトコルは ss、vmess、ssr、vless、trojan、kcp、hysteria などです。
プロトコル（直接接続）#
Shadowsocks#
shadowsocks（ss）は、sock5 プロキシ方式に基づく暗号化伝送プロトコルです。初代バージョンは 2012 年 4 月 20 日にリリースされました。Shadowsocks は独自に設計したプロトコルを使用して暗号化通信を行います。暗号化アルゴリズムには AES、Blowfish、ChaCha20、RC4 などがあり、TCP 接続を確立する以外はハンドシェイクを必要とせず、各リクエストは単一の接続を転送するだけで、常に接続状態を維持する必要がないため、モバイルデバイス上では比較的省電力です。
現在、このプロトコルは GFW によって検知され、封じ込められることができます。これには、遮断、ポート封鎖、IP 封鎖などが含まれます。したがって、直接接続の SS の場合、基本的には頭を硬くして挑むことになります。
その低遅延のため、依然として多くの主流の空港の選択肢となっています。（空港は中継を使用しており、SS の直接接続ではないため、封じ込めは影響しません）
対応ソフトウェア#
その派生ソフトウェアである shadowsocks と shadowsocksr は基本的に淘汰されています。
clash/v2rayn/v2rayng/shadowrocket/quantumultx などの主流ソフトウェアは、このプロトコルに対応しています。
shadowsocksr#
shadowsocksr（ssr / 酸酸乳）は、ss のアップグレード版と言えます。SSR は、ユーザー名 breakwa11 によって発起された Shadowsocks の分岐で、Shadowsocks の基盤にいくつかのデータ混淆方法を追加し、一部のセキュリティ問題を修正し、QoS の優先度を向上させることができるとされています。その後、貢献者 Librehat も Shadowsocks にいくつかのこのような機能を追加し、Tor のようなプラグイン可能なトランスポート層機能を追加しました。
対応ソフトウェア#
その派生ソフトウェアである shadowsocks と shadowsocksr は基本的に淘汰されています。
clash/v2rayn/v2rayng/shadowrocket/quantumultx などの主流ソフトウェアは、このプロトコルに対応しています。
VMess#
VMess は TCP ベースの暗号化伝送プロトコルで、すべてのデータは TCP で伝送されます。入出力の 2 つの部分に分かれ、通常は V2Ray クライアントとサーバー間の橋渡しとして機能します。v2ray 内核に基づいています。
VMess はシステム時間に依存しており、V2Ray を使用するシステムの UTC 時間の誤差が 90 秒以内であることを確認してください。タイムゾーンは関係ありません。Linux システムでは、ntp サービスをインストールしてシステム時間を自動的に同期できます。
その暗号性から、現在も主流の暗号化プロトコルの一つです。直接接続ノードを構築する際には、主に vmess + websocket + tls + nginx偽装 プロトコルが使用され、理論的には最も壁に阻まれにくいプロトコルの一つです。
vmess プロトコルの主な特徴は厳重な暗号化ですが、それに伴う問題も明らかです。ハンドシェイクの回数が多くなると、ss/ssr に比べて遅延が自然に増加します。しかし、速度に関しては ss/ssr よりも速いです（テストにより、同じサーバーの ss と vmess+ws の速度を比較した結果、YouTube でも速度比較の動画があります）。
対応ソフトウェア#
その派生ソフトウェアである v2rayn/v2rayng は依然として非常に一般的で、現在はすべて xray-core をデフォルトで使用しています。
clash/v2rayn/v2rayng/shadowrocket/quantumultx などの主流ソフトウェアは、このプロトコルに対応しています。
Vless#
vless は vmess のアップグレード版とも言え、xray 内核に基づいています。VLESS はステートレスな軽量伝送プロトコルで、入出力の 2 つの部分に分かれ、V2Ray クライアントとサーバー間の橋渡しとして機能します。VMess とは異なり、VLESS はシステム時間に依存せず、認証方式は UUID ですが、alterId は必要ありません。
vmess に比べて、vless のプロトコル速度はより速く、遅延はほぼ同じです。
対応ソフトウェア#
vless は xray-core を使用する必要があります。
v2rayn/v2rayng/shadowrocket/quantumultx などの主流ソフトウェアはこのプロトコルに対応しています。clash は残念ながら対応していません。
trojan#
Shadowsocks とは異なり、Trojan は自分自身を隠すためにカスタム暗号化プロトコルを使用しません。代わりに、特徴的な TLS プロトコル（TLS/SSL）を使用して、トラフィックが通常の HTTPS ウェブサイトと同じように見えるようにします。TLS は成熟した暗号化システムで、HTTPS は TLS を使用して HTTP トラフィックを運びます。正しく構成された暗号化 TLS トンネルを使用することで、伝送の安全性を確保できます。
Trojan は vmess とは異なり、TLS 暗号化を追加するかどうかを自分で決定できますが、trojan は TLS 暗号化を強制的に使用します。つまり、trojan はドメイン名が必要です。
速度に関しては、trojan と vmess はほぼ同じです。しかし、trojan の最大の利点は、サーバー側の占有が非常に少なく、非常に軽量であり、低スペックのサーバーでも快適に動作することです。
対応ソフトウェア#
clash/v2rayn/v2rayng/shadowrocket/quantumultx などの主流ソフトウェアは、このプロトコルに対応しています。
Hysteria#
Hysteria は、悪化したネットワーク環境に最適化された機能豊富なネットワークツール（双方向加速）です。例えば、衛星ネットワーク、混雑した公共 Wi-Fi、中国から国外のサーバーに接続する際などです。修正版の QUIC プロトコルに基づいています。
Hysteria は、go で書かれた非常に優れた「軽量」プロキシプログラムで、富強魔法サーバーを構築する際の最大の痛点であるラインの不安定さを解決します。
魔法を唱える際に最も難しいのは、構築とメンテナンスではなく、夕方のピーク時の配信品質です。三大通信事業者の夕方のピーク時が「信号が途切れる、接続できない、移動できない」となると、私たちも感じるところです。UDP を使用していますが、obfs を提供するため、運営者からの QoS のターゲットにならない（obfs を使用しなくても QoS の影響はありません）。
これは最近非常に人気のある新しいプロトコルです。主な利点は、ラインが悪くても中継や CF CDN を使用せずに、hysteria を使用することで救済できることです。現在のところ、非国内の最適化されたラインに対しては非常に友好的です。
対応ソフトウェア#
v2rayn/shadowrocket の最新版は hysteria をサポートしています。
中継#
直接接続について説明したので、中継についても触れましょう。
中継は主に 3 種類に分かれます。一つは国内の大帯域幅サーバーを直接中継する方法です。主な利点は、直接接続に比べて国内の複雑な通信事業者のネットワーク状況により適合できることです。明らかに、国外で壁に阻まれた IP には手が出せず、逆壁を恐れています。また、単一の国内サーバーではすべての国外サーバーを引っ張ることはできません。国外サーバーが聯通に友好的であれば、電信のサーバーを使用して引っ張ると、非常に不安定になる可能性があります。
第二の方法はトンネル中継で、これは近年新たに登場した中継方法です。トンネル中継は、国内サーバーと国外サーバーの組み合わせです。国外サーバーは一般的に BGP セッションを持っており、複雑なネットワーク状況に対しても比較的良好に対応できます。トンネルの国外側からあなたのノードサーバーまでのラインは一般的に友好的です。また、トンネルの国外側から国内側に向かう際には暗号化が行われるため、国外の機械が壁に阻まれる状況を無視できます。しかし、国内サーバーも逆壁を恐れます。トンネルを使用すれば、基本的に 1 つのトンネルノードで大部分の国外サーバーを引っ張ることができます。
第三の方法は専用線中継で、最も高価です。1Gbps の専用線は月に基本的に 2.5 万 RMB 以上で、裕福な空港でなければ使用できません。実際、専用線はトンネルと比較的似ており、国内側と国外側に分かれています。専用線は IEPL と IPLC に分かれ、これらの定義については https://www.cheshirex.com/2005.html を参照してください。専用線の最大の利点は、低遅延で安定しており、壁に阻まれないため、ノードサーバーが壁に阻まれる問題や国内の逆壁の問題を心配する必要がありません。特別な状況を除いて、専用線は基本的にオフラインになることはありません。この点が非常に好まれています。
自建#
多くの初心者が自分でノードを構築したいと考えていますが、構築後に流れが途切れたり、再び壁に阻まれたりすることがよくあります。ここで統一して推奨するのは、vmess+ws+tls+nginx偽装またはvless+ws+tls+nginx偽装の構築方法が比較的合理的であるということです（中継のない直接接続の場合）。動的 IP のサーバーの場合は、vmess+wsを使用すれば、速度を確保しつつも遮断されることはありません。品質の悪いラインの小型サーバーには hysteria を使用できます。
小結#
GFW との知恵比べはまだ続いています～～～
転載編集補足自 http://www.oneyearago.me
https://cloud.tencent.com/developer/article/1740977