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

みなさん、こんにちは！

ニキータから連絡がありました - 会社のシステムエンジニア SEMrush。今日は、中国での semrush.com サービスの安定性を確保するという課題に私たちがどのように取り組んだか、そしてその実装中にどのような問題に遭遇したかについてお話します (データ センターの位置が米国の東海岸にあることを考慮して)。

これは大きな話になり、いくつかの記事に分かれます。中国の完全に機能しないサービスから、アメリカ人向けのアメリカ版レベルのサービスのパフォーマンス指標に至るまで、すべてが私たちにどのように起こったかを説明します。面白くて役に立つことを約束します。じゃ、行こう。

中国のインターネットの問題点

ネットワーク管理の詳細に最も詳しくない人でも、このことについて聞いたことがあるでしょう。 中国のグレートファイアウォール。うわー、素敵ですね?しかし、それが何であり、実際にどのように機能するかは、かなり複雑な問題です。これについて説明した記事はインターネット上でたくさん見つかりますが、技術的な観点から見ると、このファイアウォールの構造についてはどこにも説明されていません。しかし、それは驚くべきことではありません。 1 年間の作業の結果に基づいて、それがどのように機能するかを正確に言うことはできないことをすぐに認めますが、私のコメントと実際的な結論についてはお話します。そして、このファイアウォールに関する噂から始めます。

このファイアウォールについては多くの噂があります。その中で最も興味深いものを 1 つのリストに集めてみましょう。

• Google、Facebook、Twitter、その他同様のサービスは中国ではブロックされており、機能しません。
• 中国国外および中国国内に向かうトラフィックはすべて、機械学習を使用して解析および制限され (不審なトラフィックの場合)、国境を通過するトラフィック (トラフィック) が大幅に遅くなります。
• 中国の諜報機関は、ファイアウォールを通過する暗号化されたトラフィックをハッキングするでしょう。
• VPN トンネル、IPSEC トンネルは不安定でクラッシュし、常にブロックされます。
• 暗号化が単純であればあるほど、トラフィックの認証/暗号化に使用されるパスフレーズも単純になり、中国のファイアウォールを通過する速度が速くなります。

これらの噂についてわかったことは次のとおりです。

• Google、Facebook、Twitter、およびその他の同様のサービスは確かにブロックされています (KO) が、たとえば、多くの技術的な Google ドメインは禁止されておらず、機能します (同じ gstatic.com)。ここから結論は、ブロックされていると思われる Google やその他のリソースを無謀にすべて削除すべきではないということです。
• 国境を通過する交通は実際に時間に重大な遅れをもたらします。 2 つの結果を見てください。 1 つのサイト、1 ページ、簡単な GET curlああ。最初の測定は中国そのもの (美しい都市深セン) からのものでした。 30 つ目は香港の外側から測定されました (香港には主権があり、世界との間にファイアウォールはありません)。都市間の直線距離は約40～XNUMXkmです。

nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  381k    0  381k    0     0  71824      0 --:--:--  0:00:05 --:--:-- 82832
time_namelookup:  0.004500
time_connect:  0.169342
time_appconnect:  0.723189
time_pretransfer:  0.723499
time_redirect:  0.000000
time_starttransfer:  1.532912
----------
time_total:  5.443407
----------
size_download:  390968 Bytes
speed_download:  71824.000B/s

nikita@china-hongkong:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  319k    0  319k    0     0  2555k      0 --:--:-- --:--:-- --:--:-- 2573k
time_namelookup:  0.029366
time_connect:  0.030742
time_appconnect:  0.047310
time_pretransfer:  0.047388
time_redirect:  0.000000
time_starttransfer:  0.120793
----------
time_total:  0.124871
----------
size_download:  326755 Bytes
speed_download:  2616740.000B/s

に注意を払う 時間_接続。そして一般に、その結​​果がわかります。ファイアウォールにより 4 秒が余分に追加され、これは途方もなく長いです。

• VPN および IPSEC トンネルは頻繁に失敗します。これについては後ほど詳しく説明します。ユーザーが使用する VPN サーバーは、時間の経過とともに (通常は使用開始から 1 日以内に) ブロックされます。
• 中国在住者からは、通信の暗号化が単純であればあるほど、違法性がないことが分かりやすいため、国境を通過する速度が速くなるという意見が寄せられている。そして同様に、「クリーンな」トラフィックはより多くの帯域幅と通過速度を受け取りますが、何も理解できない「ダーティ」トラフィックは逆により遅い通過を受け取ります。たとえば、curl を使用して、 ifconfig.co HTTPS および HTTP プロトコル経由。

curl -o /dev/null -w@curl_time "https://ifconfig.co/"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    13  100    13    0     0      2      0  0:00:06  0:00:05  0:00:01     3
time_namelookup:  0.004305
time_connect:  0.397465
time_appconnect:  5.149305
time_pretransfer:  5.149393
time_redirect:  0.000000
time_starttransfer:  5.568847
----------
time_total:  5.568893
----------
size_download:  13 Bytes
speed_download:  2.000B/s

curl -o /dev/null -w@curl_time "http://ifconfig.co/"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    13  100    13    0     0     28      0 --:--:-- --:--:-- --:--:--    28
time_namelookup:  0.004282
time_connect:  0.212457
time_appconnect:  0.000000
time_pretransfer:  0.212484
time_redirect:  0.000000
time_starttransfer:  0.450565
----------
time_total:  0.450620
----------
size_download:  13 Bytes
speed_download:  28.000B/s

合計ダウンロード時間は 5 バイトで、13 秒の差です。さらに、このようなテストを数回行うと、HTTP での GET は毎回ほぼ同じ時間で完了するのに対し、HTTPS ではサイトが 3、5、10、さらには 17 秒で応答する場合があることがわかります。 SSL エラーが発生する場合があります。

Unknown SSL protocol error in connection to ifconfig.co:443.

それで、私たちが持っているものは次のとおりです。

• 中国のファイアウォールによって生じる問題は上で説明しました。
• 外部リソースおよびトンネル内への ping が定期的に失われます。
• 2 点間の待ち時間は常に変化しており、多くの場合、単に予測不可能です。異なる都市/地域を接続する場合、地域の地理的な位置に基づいて遅延が少なくなることが期待されますが、まったく逆の状況が発生します。
• インターネットと通信チャネルは速いか遅いかのどちらかです。時間帯や曜日によって多少の影響はありますが、常にそうとは限りません。
• 中国から外部への DNS リクエストが、許可されたタイムアウトを超えることがあります。

浮かび上がってくる絵はまさに「素晴らしい」です。

すでに述べたように、データセンターは米国東部にあり、SEMrush 全体は、DC とクラウドにある相互接続された数十の製品、バックエンド、フロントエンド、データベース、およびこれらすべてで構成されています。私たちシステム管理者のチームは、ほとんど労力をかけずにすぐに中国での作業を開始するという任務を与えられました。

私たちは重要な質問に答えなければなりませんでした。少ない費用でやりくりし、中国のインターネットとファイアウォールに関連するすべての問題をネットワーク/クラウド/サーバー レベルで解決することは可能でしょうか?

私たちは受け取ることから始めました ICP-ライセンス.

ICPライセンス

中国 (中国本土) 内でサービスをホストし、テストを実施できるようにするには、まずドメインの ICP ライセンスを取得する必要があります。

サイトのユーザー トラフィックが中国本土内で終了しており、ドメインに ICP ライセンスがない場合、トラフィックは ISP/ホスティング側でブロックされます。興味深いことに、ICP ライセンスには Cloudflare であれ Alibaba Cloud であれ、特定のプロバイダーが含まれています。したがって、Cloudflare の ICP ライセンスを取得し、それを使用して Web サイトをホストしている場合は、Alibaba Cloud に「シームレスに」移行することはできません。このライセンスに別のホスティングを追加する必要があります。

このドメインの ICP ライセンスを取得したことで、具体的な技術的なアイデアとソリューションを考案し、実装することができました。

テストソリューション

ただし、ステージング オプションを直接作成し、ノブを回し、サイトのパフォーマンスと速度を最適化する前に、どのアクションがサイトのパフォーマンスを向上させるか、あるいは逆に悪化させるかを確認するために、テスト用のツールを選択する必要があります。

私たちのテスト ツールは、次の 2 つの主な要件を満たす必要がありました。

• 中国からテストを実行できるはずです。
• ブラウザテストが必要です。

それで私たちは見つけました キャッチポイント！彼らは世界中の試験場所を網羅しています。中国では、このツールを通じて 100500 の省からテストを実行することもできます。それぞれにいくつかの異なるプロバイダーと実行できる機能があります。 バックボーン-テスト (データセンターの仮想マシンのようなもの) および ラストマイル- テスト (可能な限りユーザーの条件に近いもの、別名ワークステーション)。後者のタイプの検査はより高価です。

年間契約を締結し（それ未満は不可）、私たちは楽器の研究を始めました。率直に言って、私たちはその機能に嬉しい驚きを感じました。以下を実行できます。

• DNSテスト、
• Web テスト (ブラウザ テスト、単純な GET/POST、モバイル クライアント エミュレーションなど)、
• トランザクションのチェック (ログインなど)、
• APIテスト、
• Ping、traceroute、NTP など

すべてをリストすることはできません。そして最も重要なことは、各テストは、多数のヘッダーやその他のパラメーターを追加することで非常にうまくカスタマイズできることです。出力は、テストを完全に説明する膨大な量の情報です。私たちにとって最も興味深いこと (ブラウザ テスト) について話すと、結果には次のものが含まれます。

• 接続、待機、ロード、SSL、DNS 時間、
• TTFB、TTLB、ドキュメント完了、レンダリング時間、DOM ロード、
• 応答 (最初のバイトまでの時間に近いもの)、Web ページの応答 (最後のバイトまでの時間に近いもの)、
• 任意のパーセンタイル、平均時間、中央値時間
• など

したがって、これらすべての指標は、変化を確認し、状況が改善したかどうかを理解するのに最適です。私たちが主に見ていたのは、 レスポンス、Webページのレスポンス、中央値、75および95パーセンタイル.

非常に最初から存在していた重要な質問: キャッチポイントを信頼できますか??このツールは、中国のさまざまな都市からの実際のサイトの読み込み速度を反映しているのでしょうか、それとも実際のユーザー エクスペリエンスとは何の関係もない、単なる真空テストのようなものなのでしょうか?
ロシアにいると中国のサイトがどのように機能するかを確実に知ることはほぼ不可能であるため、これは大きな問題です。仮想マシンを介して Socks プロキシを実行すると、最終結果としてサイトは数分以内にロードされますが、これはテストにはまったく受け入れられません。そのため、手動テストの唯一のオプションは、タイマーを使用してコンソールからカールと単純な GET を実行することです。 。このテストはネットワーク ソリューションの速度をよく反映しているため、これは役に立ちます。ブラウザ テストもあれば、非常に優れています。

その後、私たち自身も中国に行って確信しました。 Catchpoint は実際のパフォーマンス指標を非常に正確に反映しているため、信頼できます。

Cloudflare中国ネットワーク

メインドメイン semrush.com に Cloudflare を使用することに成功したため、すぐにその機能を試してみることにしました。 中国ネットワーク。このオプションは、エンタープライズ サイトに対してのみ、別のリクエストと追加料金で有効になります。また、Cloudflare をプロバイダーとしてリストする適切な ICP ライセンスを持つサイトでのみ利用できます。これを有効にすると、Cloudflare の「中国 CDN」がサイトで利用可能になります。中国地域からのトラフィックは最寄りの PoP (Points of Presence) CF に到達し、そのネットワークまたはプロバイダー/パートナーのネットワークを介して発信元に配信されます。 。

このテストベンチの図を以下に示します。

これは私たちにとって素晴らしい選択肢です。 2 番目のドメインも CF 用であることが判明しました。これにより、社内で使用されるソリューションの数が増えることはなく、インフラストラクチャも事実上複雑になりません。

ブラウザーのテストを実行したところ、次のようなことが起こりました。

赤いひし形はテストの不合格です。以下のファイルは DNS エラー (タイムアウト解決) です。一番上の失敗はタイムアウトです。

稼働時間: 86.6
中央値: 18秒
75 パーセンタイル: 29.3 秒
95 パーセンタイル: 60 秒

中央値、負荷を除去した後 reCAPTCHAの (Google サービスは中国でブロックされている) は 28 秒から 18 秒に減少しました。しかし、semrush.com (米国) の同じテストで、同じページ (静的 + 動的) のユーザー (米国) の 10% が 95 秒未満だったことを考えると、これらは依然としてひどい結果です。

各テストに入って確認することができます ウォーターフォール およびその他のより詳細なパラメータ。私たちはエラーの理由を調査し始めました。タイムアウトについては、すべてが多かれ少なかれ明らかです。中国のインターネットは「出入り」しており、そのため、海外からのリソースの接続と読み込みの速度は不安定で不均一です。その後、DNS エラーに非常に驚きました。私たちはそれを発見しました ポップ Cloudflareは実際には中国にあり、サイトアドレスは1つのエニーキャストIPに解決されますが、DNSサーバーはアメリカのものであるため、DNSリクエストは国境を越えることを余儀なくされ、失敗することがあります。

CF にこの質問を明確にしたところ、次のことが判明しました。 中国には独自のDNSサーバーを持っていません、それがいつになるかはまだ不明です。

したがって、Cloudflare DNS のみをテストすることを決定し、サイトの Cloudflare 動作メカニズムを「DNSのみ」これは、Cloudflareがそれ自体を介してトラフィックをプロキシしない場合のモードです。つまり、DDoS保護、CDN、その他の機能は提供されず、通常のDNSサーバーのモードで動作します。

このスタンドを次の図に概略的に示します。この数字は、Cloudflare の DNS サーバーがファイアウォールの背後にあるという新たな知識を考慮に入れています。

Catchpoint では、(ブラウザー テストではなく) 単純な GET テストを実行しましたが、多くの失敗が示されました。これらは同じ DNS エラーが原因でした。

これらのエラーのデバッグを開始しました dig 最初のリクエストではアドレスが正しく決定され、繰り返しのリクエストでは毎回受信することがわかりました。 サーブフェイル и 見つかりません。なぜ突然このようなことが起こったのでしょうか?

root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)

Cloudflare NSサーバーに直接クエリを実行する場合には、このようなエラーは発生しません。

root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases: 

semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases: 

semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192

これは、問題が「ローカル」DNS サーバーまたはプロバイダーのサーバー側にあることを意味します。
さらなる調査により、 サーブフェイル 私たちは決意を固めます AAAA-記録。

Cloudflareからリクエストすると判明した AAAA-ドメインに存在しないレコード、Cloudflareが応答 А- エラーであり、RFC に準拠していないエントリ。なぜローカル リゾルバー (xxxx）私はそれが気に入らなかったと彼は答えました サーブフェイル。この動作は、以下のログではっきりと確認できます。

root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @x.x.x.x

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @x.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;semrushchina.cn.               IN      AAAA

;; Query time: 334 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Tue Aug 14 23:38:50 CST 2018
;; MSG SIZE  rcvd: 44

root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @dana.ns.cloudflare.com.

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;semrushchina.cn.               IN      AAAA

;; ANSWER SECTION:
semrushchina.cn.        300     IN      A       220.170.186.192

;; Query time: 185 msec
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; WHEN: Tue Aug 14 23:43:03 CST 2018
;; MSG SIZE  rcvd: 60

私たちはCloudflareにバグレポートを提出し、しばらくしてから修正してくれました。興味深いことが判明しました。現時点では中国ではまだ IPv6 がサポートされていないため、Cloudflare は要求に応じて中国で IPv6 アドレスを発行できませんでした。 AAAA-記録。最終的には、Cloudflare が中国に代わって対応し始めるという形ですべてが解決されました。 データなし そんなご要望に。

したがって、キャッチポイント テストでの DNS エラーは急激に減少しましたが、完全には減少しませんでした。タイムアウトはまだ発生しています:

そして私たちは別の解決策を探し始めました。

次のパートでは、中国のクラウドをどのようにテストしたかについて説明します。 アリババクラウド、Nginx のちょっとした「魔法」の助けを借りて、どのようにして PoC (概念実証) ソリューションを迅速に作成できたのか、どのようにしてマルチクラウド ソリューションを作成したのか、その 1 つは最終的にサービスの作業速度の向上に大きく貢献しました中国から。

乞うご期待！

次のパート

Часть2

出所： habr.com