グレートチャイニーズファイアウォールをどのように突破したか (パート 2)

Привет！

会社のシステムエンジニアであるニキータがまた一緒です SEMrush。 この記事では、私たちがどのようにして回避策を思いついたのかについての話を続けます。 中国のファイアウォール 当社のサービスsemrush.com用。

В 前の部分 私は言いました：

• 「当社のサービスを中国で稼働させる必要がある」と決定した後にどのような問題が発生するか
• 中国のインターネットにはどのような問題があるのでしょうか?
• なぜ ICP ライセンスが必要なのでしょうか?
• Catchpoint を使用してテストベッドをテストすることにした方法と理由
• Cloudflare China Network に基づいた最初のソリューションの結果はどうなりましたか
• Cloudflare DNS のバグを発見した方法

私の意見では、ステージングの特定の技術的な実装に焦点を当てているため、この部分が最も興味深いです。 そして、私たちは次のように始めます、あるいはむしろ続けます。 アリババクラウド.

アリババクラウド

アリババクラウド はかなり大規模なクラウド プロバイダーであり、クラウド プロバイダーと名乗ることができるすべてのサービスを備えています。 外国人ユーザーも登録できることと、サイトのほとんどが英語に翻訳されているのは良いことだ（中国にとってこれは贅沢だ）。 このクラウドでは、世界の多くの地域、中国本土、オセアニアアジア (香港、台湾など) と連携できます。

IPSEC

私たちは地理から始めました。 テスト サイトは Google Cloud 上にあったため、Alibaba Cloud を GCP に「リンク」する必要があったため、Google が存在する場所のリストを公開しました。 その時点ではまだ香港に独自のデータセンターを持っていませんでした。
最も近い地域であることが判明しました アジア東1 （台湾）。 阿里は中国本土で台湾に最も近い地域であることが判明 cn-深セン (深セン)。

ととも​​に テラフォーム GCP と Ali のインフラストラクチャ全体について説明し、構築しました。 雲の間にある 100 Mbit/s のトンネルはほぼ瞬時に立ち上がりました。 深センと台湾側では、プロキシ仮想マシンが取り上げられました。 深センでは、ユーザー トラフィックは終端され、トンネルを介して台湾にプロキシされ、そこから深センのサービスの外部 IP に直接送信されます。 米国東部 (アメリカ東海岸)。 トンネル経由で仮想マシン間で ping を実行する 24ms、それほど悪くはありません。

同時にテストエリアを配置しました。 アリババクラウド DNS。 ゾーンを NS Ali に委任した後、解決時間は 470 ミリ秒から 50ミリ秒。 これ以前は、ゾーンは Cloudlfare にもありました。

トンネルと並行して アジア東1 深センから直接、別のトンネルを建設しました。 米国東部4。 そこで彼らは、より多くのプロキシ仮想マシンを作成し、Cookie または DNS を使用してテスト トラフィックをルーティングする両方のソリューションのテストを開始しました。 テストベンチを次の図に概略的に示します。

トンネルの遅延は次のようになりました。
Ali cn-深セン <—> GCP asia-east1 — 24ms
Ali cn-深セン <—> GCP us-east4 — 200ms

Catchpoint ブラウザ テストでは、優れた改善が報告されました。

XNUMX つのソリューションのテスト結果を比較します。

ソリューション
稼働時間
中央値
75パーセンタイル
95パーセンタイル

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

これは、IPSEC トンネルを使用するソリューションからのデータです。 アジア東1。 us-east4 では結果はさらに悪く、エラーも多かったので、結果は示しません。

XNUMX つのトンネルのこのテストの結果に基づいて、XNUMX つは中国に最も近い地域で終了し、もう XNUMX つは最終目的地で終了し、中国のファイアウォールの下からできるだけ早く「脱出」することが重要であることが明らかになりました。可能な場合は、高速ネットワーク (CDN プロバイダー、クラウド プロバイダーなど) を使用します。 ファイアウォールを通過して目的地に一気に到達しようとする必要はありません。 これは最速の方法ではありません。

一般に、結果は悪くありませんが、semrush.com の中央値は 8.8 秒、75 パーセンタイルは 9.4 秒です (同じテストで)。
次に進む前に、叙情的な余談を少ししたいと思います。

叙情的な余談

ユーザーがサイトに入った後 www.semrushchina.cn、「高速」中国 DNS サーバーを通じて解決されるため、HTTP リクエストは当社の高速ソリューションを通過します。 応答は同じパスに沿って返されますが、ドメインはすべての JS スクリプト、HTML ページ、および Web ページのその他の要素で指定されます。 semrush.com ページのレンダリング時にロードする必要がある追加のリソースについては、 つまり、クライアントは「メイン」A レコードを解決します。 www.semrushchina.cn そして高速トンネルに入ると、すぐに応答を受け取ります。これは、次の内容の HTML ページです。

• sso.semrush.com からあれこれの js をダウンロードします。
• cdn.semrush.com から CSS ファイルを取得します。
• dab.semrush.com から写真を撮ることもできます
• などなど。

ブラウザはこれらのリソースを求めて「外部」インターネットにアクセスし始め、そのたびにファイアウォールを通過するため、応答時間が消費されます。

ただし、前のテストでは、ページにリソースがない場合の結果が表示されます。 semrush.comのみ semrushchina.cn、*.semrushchina.cn は、トンネルに入るために深センの仮想マシンのアドレスに解決されます。

この方法でのみ、中国のファイアウォールを迅速に通過するためにソリューションを通じてすべての可能なトラフィックを最大限にプッシュすることによって、許容可能な速度と Web サイトの可用性インジケーター、およびソリューション テストの正直な結果を得ることができます。
私たちは、チームの製品側でコードを一切編集せずにこれを実行しました。

サブフィルター

この問題が表面化した直後に、解決策が生まれました。 私たちには必要だった PoC (概念実証) 当社のファイアウォール侵入ソリューションが実際にうまく機能することを証明します。 これを行うには、すべてのサイト トラフィックを可能な限りこのソリューションにラップする必要があります。 そして私たちは申請しました サブフィルター nginxで。

サブフィルター は、応答本文のある行を別の行に変更できる nginx の非常に単純なモジュールです。 そこで、すべてのオカレンスを変更しました semrush.com на semrushchina.cn すべての答えにおいて。

そして...バックエンドから圧縮されたコンテンツを受信したため、サブフィルターが必要な行を見つけられなかったため、機能しませんでした。 別のローカル サーバーを nginx に追加する必要がありました。これにより、応答が解凍されて次のローカル サーバーに渡されます。そのローカル サーバーはすでに文字列の置換、圧縮、チェーン内の次のプロキシ サーバーへの送信で忙しくしていました。

その結果、クライアントはどこで受け取りますか .semrush.com、 彼は受け取った .semrushchina.cn そして私たちの決定を従順に実行しました。

ただし、バックエンドは引き続きクライアントからの後続のリクエストで semrush.com を期待するため、単にドメインを一方向に変更するだけでは十分ではありません。 したがって、一方向の置換が行われるのと同じサーバー上で、単純な正規表現を使用してリクエストからサブドメインを取得し、 プロキシパス 変数あり $hostに出品されています $subdomain.semrush.com。 混乱するように思えるかもしれませんが、うまくいきます。 そしてそれはうまくいきます。 異なるロジックが必要な個々のドメインの場合は、独自のサーバー ブロックを作成し、別の構成を作成するだけです。 以下は、このスキームをわかりやすく説明するために短縮された nginx 構成です。

次の構成は、中国からのすべてのリクエストを処理します。 .semrushchina.cn:

    listen 80;

    server_name ~^(?<subdomain>[w-]+).semrushchina.cn$;

    sub_filter '.semrush.com' '.semrushchina.cn';
    sub_filter_last_modified on;
    sub_filter_once off;
    sub_filter_types *;

    gzip on;
    gzip_proxied any;
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;

    location / {
        proxy_pass http://127.0.0.1:8083;
        proxy_set_header Accept-Encoding "";
        proxy_set_header Host $subdomain.semrush.com;
        proxy_set_header X-Accept-Encoding $http_accept_encoding;
    }
}

この構成は次のものにプロキシします ローカルホスト ポート 83 に接続すると、次の構成がそこで待機しています。

    listen 127.0.0.1:8083;

    server_name *.semrush.com;

    location / {
        resolver 8.8.8.8 ipv6=off;
        gunzip on;
        proxy_pass https://$host;
        proxy_set_header Accept-Encoding gzip;
    }
}

繰り返しますが、これらはトリミングされた構成です。

そのように。 複雑に見えるかもしれませんが、言葉で説明するとこうなります。 実際、すべてが蒸しカブよりも簡単です:)

余談終わり

IPSEC トンネルの落下に関する通説が確認されなかったため、しばらくは満足していました。 しかしその後、トンネルが崩壊し始めました。 XNUMX日に数回、数分間。 少しですが、それは私たちには合いませんでした。 両方のトンネルが同じルーター上の Ali 側で終端されていたため、おそらくこれは地域的な問題であり、バックアップ リージョンを増やす必要があると判断しました。

彼らはそれを拾い上げた。 トンネルはさまざまなタイミングで障害を起こし始めましたが、nginx の上流レベルではフェイルオーバーが正常に機能しました。 しかし、その後、ほぼ同時にトンネルが崩壊し始めました 🙂 そして、502 と 504 が再び動き始めました。稼働時間は悪化し始めたので、私たちは次のオプションに取り組み始めました。 アリババ CEN (クラウドエンタープライズネットワーク)。

CEN

CEN - これは、Alibaba Cloud 内の異なるリージョンにある XNUMX つの VPC の接続です。つまり、クラウド内の任意のリージョンのプライベート ネットワークを相互に接続できます。 そして最も重要なことは、このチャンネルにはかなり厳格なルールがあるということです。 SLA。 速度、稼働時間ともに非常に安定しています。 しかし、それは決して単純ではありません。

• 中国国民または法人でない場合、入手することは非常に困難です。
• チャネル帯域幅のメガビットごとに料金を支払う必要があります。

つながる機会があること 中国本土 и 海外、XNUMX つの Ali リージョン間に CEN を作成しました。 cn-深セン и us-east-1 (us-east4 に最も近いポイント)。 アリで us-east-1 別の仮想マシンを起動して、もう XNUMX つ追加しました ホップ.

次のようになりました。

ブラウザのテスト結果は以下のとおりです。

ソリューション
稼働時間
中央値
75パーセンタイル
95パーセンタイル

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

パフォーマンスは IPSEC よりわずかに優れています。 ただし、IPSEC を介すると 100 Mbit/s の速度でダウンロードできる可能性があり、CEN を介した場合のみ 5 Mbit/s 以上の速度でダウンロードできる可能性があります。

ハイブリッドっぽいですね？ IPSEC の速度と CEN の安定性を組み合わせます。

これは、IPSEC トンネルに障害が発生した場合に、IPSEC と CEN の両方を通過するトラフィックを許可するために行ったことです。 稼働時間は大幅に向上しましたが、サイトの読み込み速度にはまだ改善の余地があります。 次に、すでに使用してテストしたすべての回路を描画し、この回路にもう少し GCP を追加してみることにしました。 キャップ.

キャップ

キャップ - です グローバルロードバランサ (または Google Cloud ロードバランサ)。 これには私たちにとって重要な利点があります。CDN のコンテキストでは次のような利点があります。 エニーキャストIPこれにより、クライアントに最も近いデータ センターにトラフィックをルーティングできるため、トラフィックはすぐに Google の高速ネットワークに入り、「通常の」インターネットを経由するトラフィックは少なくなります。

何も考えずに上げました HTTP/HTTPS LB GCP にサブフィルタを備えた仮想マシンをバックエンドとしてインストールしました。

いくつかのスキームがありました。

• 使用する Cloudflare中国ネットワークただし、今回は Origin をグローバルに指定する必要があります IP GLB.
• でクライアントを終了します cn-深セン、そこからトラフィックを直接プロキシします キャップ.
• 中国から直行して、 キャップ.
• でクライアントを終了します cn-深セン、そこからプロキシへ アジア東1 IPSEC 経由 ( 米国東部4 CEN経由）、そこからGLBに移動します（落ち着いて、以下に写真と説明があります）

これらすべてのオプションと、さらにいくつかのハイブリッド オプションをテストしました。

• クラウドフレア + GLB

このスキームは、稼働時間と DNS エラーのため、私たちには適していませんでした。 ただし、テストは CF 側でバグが修正される前に実行されたため、おそらく今は改善されていると思われます (ただし、これは HTTP タイムアウトを除外するものではありません)。

• アリ+GLB

また、このスキームは稼働時間の点でも私たちには適していませんでした。これは、許容可能な時間内に接続できなかったり、タイムアウトになったりして、GLB がアップストリームから落ちてしまうことがよくあったからです。これは、中国国内のサーバーの場合、GLB アドレスが外部に残り、したがってサーバーの背後にあるためです。中国のファイアウォール。 魔法は起こりませんでした。

• GLBのみ

前のオプションと似ていますが、中国国内のサーバーを使用しなかった点のみが異なります。トラフィックは直接 GLB に送られました (DNS レコードは変更されました)。 したがって、通常のインターネットプロバイダーのサービスを使用する一般の中国のクライアントは、アリクラウドよりもファイアウォールを通過する状況がはるかに悪いため、結果は満足のいくものではありませんでした。

• 深セン -> (CEN/IPSEC) -> プロキシ -> GLB

ここでは、すべてのソリューションの中で最良のものを使用することにしました。

• 安定性と CEN による保証された SLA
• IPSECによる高速
• Google の「高速」ネットワークとそのエニーキャスト。

スキームは次のようになります。ユーザー トラフィックは仮想マシン上で終端されます。 ch-深セン。 Nginx アップストリームはそこで構成されており、その一部は IPSEC トンネルの反対側にあるプライベート IP サーバーを指し、一部のアップストリームは CEN の反対側にあるサーバーのプライベート アドレスを指します。 リージョンに設定された IPSEC アジア東1 GCP 内（ソリューションが作成された時点では中国に最も近い地域でした。現在、GCP は香港にも存在します）。 CEN - 地域へ 米国東部1 アリクラウドで。

その後、両端からのトラフィックは次のように転送されました。 エニーキャスト IP GLBつまり、Google の最も近い拠点に到達し、そのネットワークを経由して地域に到達しました。 米国東部4 GCP では、代替仮想マシン (nginx のサブフィルター付き) がありました。

このハイブリッド ソリューションは、私たちの予想通り、それぞれのテクノロジーの利点を活かしたものでした。 一般に、トラフィックは高速 IPSEC を通過しますが、問題が発生した場合は、これらのサーバーを数分間すぐにアップストリームから追い出し、トンネルが安定するまで CEN 経由でのみトラフィックを送信します。

上記のリストの 4 番目のソリューションを実装することで、その時点で私たちが望んでいたものとビジネスが求めていたものを達成できました。

以前のソリューションと比較した新しいソリューションのブラウザ テスト結果:

ソリューション
稼働時間
中央値
75パーセンタイル
95パーセンタイル

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

CEN/IPsec + GLB
99.79
13s
16s
25s

CDN

私たちが実装したソリューションはすべて良好ですが、地域レベル、さらには都市レベルでトラフィックを加速できる CDN はありません。 理論的には、これにより、CDN プロバイダーの高速通信チャネルを使用して、エンド ユーザーのサイトが高速化されます。 そして私たちはいつもそれについて考えていました。 そして今、プロジェクトの次の反復、つまり中国での CDN プロバイダーの検索とテストの時期が来ています。

これについては次の最後のパートでお話します:)

出所： habr.com