🥇كيف اخترقنا جدار الحماية العظيم للصين (الجزء الثاني)

مرحبا بالجميع!

نيكيتا على اتصال - مهندس نظام من الشركة SEMrush. سأخبركم اليوم كيف واجهنا مهمة ضمان استقرار خدمة semrush.com الخاصة بنا في الصين، وما هي المشاكل التي واجهناها أثناء تنفيذها (بالنظر إلى موقع مركز البيانات الخاص بنا على الساحل الشرقي للولايات المتحدة).

وستكون هذه قصة كبيرة، مقسمة إلى عدة مقالات. سأخبرك كيف حدث كل ذلك بالنسبة لنا: من خدمة غير عاملة تمامًا من الصين، إلى مؤشرات أداء الخدمة على مستوى نسختها الأمريكية للأمريكيين. أعدك أنها ستكون مثيرة للاهتمام ومفيدة. لذلك، دعونا نذهب.

مشاكل الانترنت الصيني

حتى أن أبعد شخص عن تفاصيل إدارة الشبكة قد سمع عنه جدار الحماية العظيم في الصين. واو، يبدو رائعًا، أليس كذلك؟ ولكن ما هو وكيف يعمل في الواقع هو سؤال معقد إلى حد ما. يمكنك العثور على العديد من المقالات المخصصة لهذا على الإنترنت، ولكن من وجهة نظر فنية، لم يتم وصف هيكل جدار الحماية هذا في أي مكان. ومع ذلك، ليس من المستغرب. سأعترف على الفور أنه بناءً على نتائج عام من العمل، لن أتمكن من تحديد كيفية عمله بالضبط، لكن يمكنني إخباركم بتعليقاتي واستنتاجاتي العملية. وسنبدأ بالإشاعات حول جدار الحماية هذا.

هناك العديد من الشائعات حول جدار الحماية هذا. دعونا نجمع أهمها وأكثرها إثارة للاهتمام في قائمة واحدة:

جوجل وفيسبوك وتويتر وغيرها من الخدمات المشابهة محظورة ولا تعمل في الصين.
يتم تحليل أي حركة مرور متجهة خارج الصين إلى الصين ومحدودة باستخدام التعلم الآلي (في حالة حركة المرور المشبوهة)، مما يؤدي إلى إبطاء (حركة المرور) بشكل كبير عبر الحدود.
ستقوم وكالات الاستخبارات الصينية باختراق أي حركة مرور مشفرة تمر عبر جدار الحماية الخاص بها.
أنفاق VPN وأنفاق IPSEC غير مستقرة وتتعطل ويتم حظرها باستمرار.
كلما كان التشفير أبسط، كلما كانت عبارة المرور المستخدمة لمصادقة/تشفير حركة المرور أبسط، وكلما كانت أسرع عبر جدار الحماية الصيني.

إليك ما اكتشفناه حول هذه الشائعات:

يتم بالفعل حظر Google وFacebook وTwitter وغيرها من الخدمات المشابهة (KO الخاص بك)، لكن العديد من نطاقات Google التقنية، على سبيل المثال، ليست محظورة وتعمل (نفس gstatic.com). الاستنتاج التالي هو: لا ينبغي عليك قطع جميع موارد Google والموارد الأخرى التي يبدو أنها محظورة بشكل متهور.
إن أي حركة مرور تمر عبر الحدود تضيف بالفعل تأخيرًا خطيرًا إلى وقتها. انظر إلى النتيجتين. موقع واحد، صفحة واحدة، GET بسيط حليقة'أوم. القياس الأول كان من الصين نفسها (مدينة شنتشن الجميلة). والثانية تم قياسها من الخارج من هونج كونج (لها السيادة، ولا يوجد بينها وبين العالم جدار حماية). المسافة بين المدن في خط مستقيم حوالي 30-40 كم.

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 التي يستخدمها المستخدمون بمرور الوقت (عادةً خلال يوم واحد بعد بدء الاستخدام).
هناك رأي ورد من الأشخاص الذين يعيشون في الصين مفاده أنه كلما كان تشفير حركة المرور أبسط، كلما مرت عبر الحدود بشكل أسرع، لأنه من السهل أن نفهم أنه لا يوجد شيء غير قانوني في هذا الأمر. وبنفس الطريقة، تتلقى حركة المرور "النظيفة" المزيد من النطاق الترددي وسرعة المرور، في حين أن حركة المرور "القذرة"، التي لا يمكن فهم أي شيء فيها، تتلقى، على العكس من ذلك، مرورًا أبطأ. على سبيل المثال سأستخدم حليقة ل 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 بايت. علاوة على ذلك، عند إجراء مثل هذا الاختبار عدة مرات، يمكنك ملاحظة أن GET على HTTP يكتمل بشكل عام في نفس الوقت في كل مرة، بينما على HTTPS يستجيب الموقع أحيانًا خلال 3 و5 و10 وحتى 17 ثانية. في بعض الأحيان تحدث أخطاء SSL:

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

إذن ما لدينا:

تم وصف المشاكل التي أنشأها جدار الحماية الصيني أعلاه.
تختفي أصوات الاتصال بالموارد الخارجية والأنفاق الداخلية بشكل دوري.
يتغير زمن الوصول بين نقطتين باستمرار، وغالبًا ما يكون ببساطة لا يمكن التنبؤ به. عند ربط مدن/مناطق مختلفة، تتوقع أنه بناءً على الموقع الجغرافي للمناطق، سيكون التأخير أقل، لكنك تحصل على الوضع المعاكس تمامًا.
الإنترنت وقنوات الاتصال إما سريعة أو بطيئة. هناك اعتماد طفيف على الوقت من اليوم واليوم من الأسبوع، ولكن ليس دائما.
تتجاوز طلبات DNS إلى العالم الخارجي من الصين في بعض الأحيان المهلة المسموح بها.

والصورة التي تظهر هي ببساطة "ممتازة".

يقع مركز البيانات، كما قلت سابقًا، في شرق الولايات المتحدة، ويتكون SEMrush بأكمله من العشرات من المنتجات المترابطة والواجهات الخلفية والواجهات الأمامية وقواعد البيانات، وكل هذا في العاصمة والسحابات. لقد تم تكليفنا، كفريق من مسؤولي النظام، بمهمة البدء بسرعة في العمل في الصين بأقل جهد.

كان علينا الإجابة على سؤال مهم: هل من الممكن تدبر الأمر بتكلفة قليلة وحل جميع المشكلات المرتبطة بالإنترنت الصيني وجدار الحماية على مستوى الشبكة/السحابة/الخادم؟

لقد بدأنا بالاستقبال برنامج المقارنات الدولية-التراخيص.

ترخيص برنامج المقارنات الدولية

لتتمكن من استضافة الخدمة الخاصة بك داخل الصين (البر الرئيسي للصين) وإجراء الاختبارات، يجب عليك أولاً الحصول على ترخيص ICP للنطاق.

إذا تم إنهاء حركة مرور المستخدم على موقعك داخل البر الرئيسي للصين، وإذا لم يكن المجال الخاص بك يحتوي على ترخيص ICP، فسيتم حظر حركة المرور الخاصة بك من جانب مزود خدمة الإنترنت/الاستضافة. ومن المثير للاهتمام أن ترخيص ICP يتضمن مزودًا محددًا، سواء كان Cloudflare أو Alibaba Cloud. لذلك، إذا حصلت على ترخيص ICP لـ Cloudflare واستضفت موقع الويب الخاص بك معهم، فلن تتمكن من الانتقال "بسلاسة" إلى Alibaba Cloud. ستحتاج إلى إضافة استضافة أخرى إلى هذا الترخيص.

وبعد حصولنا على ترخيص ICP للمجال، تمكنا من التوصل إلى أفكار وحلول تقنية محددة وتنفيذها.

حلول الاختبار

ولكن قبل إنشاء خيارات التدريج مباشرة، وإدارة المقابض، وتحسين أداء الموقع وسرعته، تحتاج إلى اختيار أداة لاختباره لمعرفة أي من إجراءاتنا تتحسن أو على العكس من ذلك، تؤدي إلى تفاقم أداء الموقع.

يجب أن تلبي أداة الاختبار الخاصة بنا متطلبين رئيسيين:

ينبغي أن تكون قادرة على إجراء الاختبارات من الصين،
يجب أن يكون لديه اختبارات المتصفح.

لذلك وجدنا نقطة الالتقاط! لديهم تغطية ممتازة لمواقع الاختبار حول العالم. وفي الصين، يمكن أيضًا إجراء الاختبارات من 100500 مقاطعة من خلال هذه الأداة. لكل منها عدة مقدمي خدمات مختلفين + القدرة على القيام بذلك العمود الفقري-الاختبارات (شيء مثل الجهاز الظاهري في مركز البيانات) و الميل الأخير-الاختبارات (أقرب ما يمكن إلى ظروف المستخدم، والمعروفة أيضًا باسم محطة العمل). النوع الأخير من الاختبارات أكثر تكلفة.

بعد إبرام عقد سنوي (أقل من ذلك غير ممكن)، بدأنا في دراسة الأداة. بصراحة، لقد فوجئنا بسرور بوظائفه. يمكنك تشغيل:

اختبارات DNS،
اختبارات الويب (اختبارات المتصفح، GET/POST البسيطة، محاكاة عميل الهاتف المحمول، وما إلى ذلك)،
الشيكات المعاملات (على سبيل المثال، تسجيل الدخول)،
اختبارات واجهة برمجة التطبيقات،
بينغ، تتبع المسار، NTP، الخ.

لا يمكنك سرد كل شيء. والأهم من ذلك، أنه يمكن تخصيص كل اختبار بشكل جيد عن طريق إضافة مجموعة من الرؤوس والمعلمات الأخرى. الإخراج عبارة عن كمية هائلة من المعلومات التي تصف الاختبار الخاص بك بشكل كامل. إذا تحدثنا عن الأشياء الأكثر إثارة للاهتمام بالنسبة لنا (اختبارات المتصفح)، فإن النتيجة تشمل:

الاتصال، الانتظار، التحميل، SSL، وقت DNS،
TTFB، TTLB، اكتمال المستند، وقت العرض، تحميل DOM،
الاستجابة (شيء قريب من الوقت حتى البايت الأول)، استجابة صفحة الويب (شيء قريب من الوقت حتى آخر بايت)،
أي نسبة مئوية، متوسط، متوسط الوقت
إلخ

وبناءً على ذلك، تعد كل هذه المقاييس رائعة لرؤية التغييرات وفهم ما إذا كانت الأمور قد تحسنت أم لا. نظرنا بشكل رئيسي إلى الاستجابة، استجابة صفحة الويب، المتوسط، 75 و95 بالمائة.

سؤال مهم كان يدور في الأجواء منذ البداية: هل يمكنك الوثوق بـ Catchpoint؟؟ هل تعكس هذه الأداة سرعة تحميل الموقع الحقيقية في الصين من مدن مختلفة، أم أنها مجرد نوع من الاختبار في الفراغ ولا علاقة له بتجربة المستخدم الحقيقية؟
هذه مشكلة كبيرة، لأنه في روسيا يكاد يكون من المستحيل معرفة كيفية عمل موقع من الصين بشكل موثوق. من خلال إجراء وكيل الجوارب من خلال جهاز افتراضي، تكون النتيجة النهائية هي تحميل الموقع في غضون بضع دقائق، وهو أمر غير مقبول للاختبارات، وبالتالي فإن الخيار الوحيد للاختبار اليدوي هو التجعيد والحصول البسيط من وحدة التحكم باستخدام مؤقت. . وهذا يساعد لأن هذا الاختبار يعكس بشكل جيد سرعة حل الشبكة، وإذا كانت هناك أيضًا اختبارات للمتصفح، فهذا جيد جدًا.

في وقت لاحق ذهبنا بأنفسنا إلى الصين واقتنعنا بذلك يمكنك الوثوق بـ Catchpoint؛ فهو يعكس بدقة مؤشرات الأداء الحقيقية.

شبكة كلاودفلير الصينية

نظرًا لأننا نجحنا في استخدام Cloudflare للنطاق الرئيسي semrush.com، فقد قررنا تجربة الميزة التي تسمى شبكة الصين. يتم تمكين هذا الخيار فقط لمواقع المؤسسات بناءً على طلب منفصل ومقابل رسوم إضافية. كما أنه متاح فقط للمواقع التي لديها ترخيص ICP مناسب يدرج Cloudflare كموفر. بعد تمكينه، يصبح "CDN الصيني" من Cloudflare متاحًا للموقع - تصل حركة المرور من المناطق الصينية إلى أقرب PoP (نقاط التواجد) CF، ثم يتم تسليمها إلى الأصل عبر شبكاتها أو شبكات مقدمي الخدمة/الشركاء .

ويرد أدناه الرسم التخطيطي لمقعد الاختبار هذا.

هذا خيار عظيم بالنسبة لنا. وتبين أن المجال الثاني سيكون أيضًا خاصًا بـ CF، وهو ما لا يزيد من عدد الحلول المستخدمة في الشركة، كما أنه لا يؤدي عمليًا إلى تعقيد البنية التحتية.

أجرينا اختبارات المتصفح وهذا ما حدث:

الماس الأحمر فشل في الاختبار. الملفات الموجودة أدناه هي أخطاء DNS (مهلة الحل). حالات الفشل في الأعلى هي المهلات.

وقت التشغيل: 86.6
المتوسط: 18 ثانية
75 بالمئة: 29.3 ثانية
95 بالمئة: 60 ثانية

المتوسط، بعد إزالة التحميل الأخبار الإقتصادية العامة (خدمة جوجل المحظورة في الصين) انخفضت من 28 إلى 18 ثانية. لكن هذه لا تزال نتائج رهيبة، مع الأخذ في الاعتبار أن الاختبار نفسه لموقع semrush.com (من الولايات المتحدة) أعطى أقل من 10 ثوانٍ لـ 95% من المستخدمين (من الولايات المتحدة) على نفس الصفحة (ثابت + ديناميكي).

يمكنك الذهاب إلى كل اختبار وإلقاء نظرة شلال وغيرها من المعلمات الأكثر تفصيلا. بدأنا في التحقيق في أسباب الأخطاء، وإذا كان كل شيء واضحًا إلى حد ما بالنسبة للمهلات: الإنترنت في الصين "يتحرك داخل وخارج"، ولهذا السبب فإن سرعة الاتصال وتحميل الموارد من الخارج غير مستقرة وغير متساوية، ثم فاجأتنا أخطاء DNS بشكل كبير. وجدنا ذلك الملوثات العضوية الثابتة تقع Cloudflare بالفعل في الصين، ويتحول عنوان الموقع إلى IP Anycast واحد، لكن خوادم DNS أمريكية، ولهذا السبب تُجبر طلبات DNS على المرور عبر الحدود، لذلك تفشل في بعض الأحيان.

بعد توضيح هذا السؤال مع CF، اتضح ذلك ليس لديهم خوادم DNS الخاصة بهم في الصين، ومتى سيكون غير معروف.

ولذلك قررنا اختبار Cloudflare DNS فقط وقمنا بتغيير آلية تشغيل Cloudflare لموقعنا إلى "DNS فقط" هذا هو الوضع الذي لا يقوم فيه Cloudflare بتوكيل حركة المرور من خلال نفسه، مما يعني أنه لا يوفر حماية DDoS وCDN وميزات أخرى، ويعمل في وضع خادم DNS عادي.

يظهر هذا الموقف بشكل تخطيطي في الشكل التالي. يأخذ هذا الرقم في الاعتبار المعرفة الناشئة بأن خوادم DNS الخاصة بـ Cloudflare تقع خلف جدار الحماية.

في Catchpoint أجرينا اختبارات GET بسيطة (وليست اختبارات المتصفح)، والتي أظهرت الكثير من حالات الفشل. لقد كانت ناجمة عن نفس أخطاء DNS.

لقد بدأنا في تصحيح هذه الأخطاء باستخدام حفر ووجدت أنه عند الطلب الأول يتم تحديد العنوان بشكل صحيح، وعند الطلب المتكرر نستقبله في كل مرة فشل الخدمة и غير معثور عليه. لماذا يحدث هذا فجأة؟

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 في اختبارات Catchpoint بشكل حاد، ولكن ليس بشكل كامل. المهلات لا تزال هنا:

وبدأنا بالبحث عن حل آخر.

سأخبرك في الجزء التالي كيف اختبرنا السحابة الصينية بابا الغيمة، كيف تمكنا، بمساعدة القليل من "السحر" من Nginx، من إنشاء حلول PoC (إثبات المفهوم) بسرعة، وكيف أنشأنا حلول Multi-Cloud، والتي ساعد أحدها في النهاية بشكل كبير في تسريع عمل الخدمة من الصين.

ترّقب!