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

تحية!

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

في الجزء السابق قلت:

• ما هي المشاكل التي تظهر بعد اتخاذ قرار "نحن بحاجة إلى جعل خدمتنا تعمل في الصين"
• ما هي المشاكل التي تواجه الإنترنت الصينية
• لماذا أحتاج إلى ترخيص برنامج المقارنات الدولية
• كيف ولماذا قررنا اختبار مقاعد الاختبار الخاصة بنا باستخدام نقطة الالتقاء
• ما هو نتيجة الحل الأول لدينا على أساس شبكة Cloudflare الصين
• كيف وجدنا خلل في DNS Cloudflare

هذا الجزء هو الأكثر إثارة للاهتمام ، في رأيي ، لأنه يركز على تطبيقات تقنية محددة للإعداد. وسوف نبدأ ، أو بالأحرى نواصل ، مع علي بابا كلاود .

بابا سحابة

Alibaba Cloud هو مزود سحابة كبير إلى حد ما ، يحتوي على جميع الخدمات التي تتيح له أن يطلق على نفسه بصراحة مزود سحابة. من الجيد أن تتاح لهم الفرصة للتسجيل لدى المستخدمين الأجانب ، وأن معظم الموقع قد تمت ترجمته إلى الإنجليزية (بالنسبة للصين ، إنها ترف). في هذه السحابة ، يمكنك العمل مع العديد من مناطق العالم ، الصين القارية ، وكذلك المحيط آسيا (هونج كونج ، تايوان ، إلخ).

IPSEC

بدأت مع الجغرافيا. نظرًا لأن موقع الاختبار الخاص بنا يقع على Google Cloud ، فقد اضطررنا إلى "ربط" Alibaba Cloud بـ GCP ، لذا فتحنا قائمة بالمواقع التي توجد فيها Google. في تلك اللحظة ، لم يكن لديهم بعد مركز بيانات خاص بهم في هونغ كونغ.
كانت أقرب منطقة هي آسيا الشرقية (تايوان). كان علي شنزن (شنتشن) أقرب منطقة من البر الرئيسي للصين إلى تايوان.

باستخدام terraform ، وصفوا وأثار البنية التحتية بالكامل في GCP و Ali. ارتفع نفق 100 ميغابت في الثانية بين الغيوم على الفور تقريبا. على جانب شنتشن وتايوان رفعوا الأجهزة الظاهرية بالوكالة. في Shenzhen ، يتم إنهاء حركة مرور المستخدم ، وتوجيهها عبر نفق إلى تايوان ، ومن هناك تذهب مباشرةً إلى عنوان IP الخارجي لخدمتنا في شرق الولايات المتحدة (الساحل الشرقي للولايات المتحدة الأمريكية). بينغ بين الظاهري على النفق 24ms ، وهي ليست سيئة للغاية.

في الوقت نفسه ، وضعنا منطقة اختبار في Alibaba Cloud DNS . بعد تفويض المنطقة إلى NS Ali ، انخفض وقت الحل من 470 مللي ثانية إلى 50 مللي ثانية . قبل ذلك ، كانت المنطقة أيضًا على Cloudlfare.

بالتوازي مع النفق إلى شرق آسيا 1 ، تم رفع نفق آخر من شنتشن مباشرة إلى شرق الولايات المتحدة . هناك قاموا بإنشاء المزيد من الأجهزة الظاهرية بالوكالة وبدأوا في قياس كلا الحلين ، وتوجيه اختبار الحركة باستخدام ملفات تعريف الارتباط أو DNS. يتم وصف طاولة الاختبار بشكل تخطيطي في الشكل التالي:

الكمون للأنفاق على النحو التالي:
علي cn-shenzhen <--> برنامج شركاء Google المعتمدون في شرق آسيا - 24 مللي ثانية
علي cn-shenzhen <--> GCP us-east4 - 200ms

أبلغت اختبارات متصفح Catchpoint عن تحسينات ممتازة في الأداء.

قارن نتائج الاختبار للحلولين:

هذه هي بيانات الحل باستخدام نفق IPSEC عبر asia-east1 . من خلال us-east4 ، كانت النتائج أسوأ ، وكان هناك المزيد من الأخطاء ، لذلك لن أعطي النتائج.

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

بشكل عام ، فإن النتائج ليست سيئة ، ولكن semrush.com لديه وسيطة من 8.8s و 75 في المئة من 9.4s (في نفس الاختبار).
وقبل الانتقال ، أود أن أصنع استطرادا.

انحدار غنائي

بعد زيارة المستخدم للموقع www.semrushchina.cn ، والذي يحل من خلال خوادم DNS الصينية "السريعة" ، يمر طلب HTTP من خلال حلنا السريع. يتم إرجاع الإجابة بنفس الطريقة ، ولكن في جميع البرامج النصية JS وصفحات HTML والعناصر الأخرى لصفحة الويب ، تتم الإشارة إلى المجال semrush.com للحصول على موارد إضافية يجب تحميلها عند تقديم الصفحة. أي أن العميل يحل "الرئيسي" سجل www.semrushchina.c n ويدخل في النفق السريع ، يتلقى بسرعة استجابة - صفحة HTML التي تنص على:

• قم بتنزيل مثل هذه الملفات المشابهة من sso.semrush.com ،
• خذ ملفات CSS من cdn.semrush.com ،
• والتقاط المزيد من الصور من dab.semrush.com
• و هكذا.

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

ولكن في الاختبار السابق ، يتم تقديم النتائج عند عدم وجود موارد semrush.com على الصفحة ، ويتم حل semrushchina.cn و * .semrushchina.cn فقط على عنوان الجهاز الظاهري في Shenzhen للوصول إلى النفق لاحقًا.

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

Subfilter

وُلِد الحل فورًا بعد ظهور هذه المشكلة. كنا في حاجة إلى PoC (إثبات الفكرة) لكي تعمل حلول جدار الحماية لدينا بشكل جيد. للقيام بذلك ، يجب عليك زيادة كل حركة المرور إلى الموقع في هذا الحل. وقمنا بتطبيق subfilter في nginx.

يعد التصفية الفرعية وحدة نمطية بسيطة إلى حد ما في nginx تسمح لك بتغيير سطر واحد في نص الاستجابة إلى سطر آخر. لذلك قمنا بتغيير كل تكرارات semrush.com إلى semrushchina.cn في جميع الإجابات.

و ... لم ينجح هذا ، لأننا تلقينا محتوى مضغوطًا من الأسطح الخلفية ، وبالتالي لم يتمكن العامل الفرعي من العثور على السطر الضروري. اضطررت إلى إضافة خادم محلي آخر إلى nginx ، مما وسع الاستجابة ونقله إلى الخادم المحلي التالي ، الذي كان يعمل بالفعل في استبدال الخط والضغط والتسليم إلى الوكيل التالي في السلسلة.

نتيجة لذلك ، حيث سيتلقى العميل <subdomain> .semrush.com ، سيتلقى <subdomain> .semrushchina.cn ويخضع لقرارنا بطاعة.

ومع ذلك ، لا يكفي فقط تغيير المجال في اتجاه واحد ، لأن الخلفية لا تزال تتوقع semrush.com في الطلبات اللاحقة من العميل. وفقًا لذلك ، على نفس الخادم حيث يتم إجراء الاستبدال في اتجاه واحد ، باستخدام تعبير عادي بسيط ، نحصل على المجال الفرعي من الطلب ، ثم نفّذ proxy_pass مع تعيين متغير 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. ولكن بعد ذلك بدأت الأنفاق في الانخفاض. عدة مرات في اليوم لعدة دقائق. قليلا ، لكنه لم يناسبنا. نظرًا لأنه تم إنهاء كلا النفقين على جانب علي على نفس جهاز التوجيه ، فقد قررنا أن هذه مشكلة إقليمية وقد نحتاج إلى رفع منطقة النسخ الاحتياطي.

التقطت. بدأت الأنفاق في الهبوط في أوقات مختلفة ، ولكن كان لدينا فشل ضبطها على مستوى المنبع في nginx. ولكن بعد ذلك بدأت الأنفاق في السقوط في نفس الوقت تقريبًا :) ومرة ​​أخرى ، بدأ 502 و 504. في الجهوزية بالتدهور ، لذلك بدأنا في حل الخيار مع Alibaba CEN (شبكة Enterprise Cloud).

CEN

CEN هو اتصال بين VPCs من مناطق مختلفة داخل Alibaba Cloud ، أي أنه يمكنك توصيل الشبكات الخاصة من أي منطقة داخل السحابة ببعضها البعض. والأهم من ذلك: هذه القناة لديها جيش تحرير السودان صارمة إلى حد ما. انها مستقرة جدا سواء في السرعة ووقت التشغيل. لكنها ليست بهذه البساطة:

• من الصعب جدًا الحصول عليها إذا لم تكن مواطناً صينياً أو كيانات قانونية ،
• تحتاج إلى دفع ثمن كل ميغابت من عرض النطاق الترددي.

بعد أن أتيحت لنا الفرصة لربط البر الرئيسي للصين والخارج ، أنشأنا CEN بين منطقتين علي: cn-shenzhen و us-east-1 (أقرب نقطة لنا شرق -4). في علي بنا - الشرق - 1 ، رفعوا آلة افتراضية أخرى ليكون لها قفزة أخرى.

اتضح مثل هذا:

نتائج اختبار المتصفح أدناه:

الأداء أفضل قليلاً من IPSEC. ولكن من خلال IPSEC ، يُمكنك التنزيل بسرعة 100 ميجابت في الثانية ، وعبر CEN فقط بسرعة 5 ميجابت في الثانية وأكثر تكلفة.

الهجين يطرح ، أليس كذلك؟ الجمع بين سرعة IPSEC والاستقرار CEN.

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

GLB

GLB هو Global Load Balancer (أو Google Cloud Load Balancer). لها ميزة مهمة بالنسبة لنا: في سياق CDN ، يوجد لديها أي بث IP ، والذي يسمح لك بتوجيه حركة المرور إلى مركز البيانات الأقرب إلى العميل ، وذلك بفضل وصول حركة المرور إلى شبكة Google السريعة بشكل أسرع وأقل عبر الإنترنت "العادي".

دون التفكير مرتين ، قمنا برفع HTTP / HTTPS LB إلى GCP ووضع أجهزتنا الافتراضية مع الواجهة الخلفية للمرشح الفرعي.

كان هناك عدة مخططات:

• استخدم Cloudflare China Network ، لكن هذه المرة تحدد Origin GLB IP العالمي.
• إنهاء العملاء في cn- شنتشن ، ومن هناك حركة المرور بالوكالة على الفور إلى GLB .
• انتقل مباشرة من الصين إلى GLB .
• إنهاء العملاء في cn-shenzhen ، من هناك الوكيل إلى asia-east1 عبر IPSEC (في us-east4 عبر CEN) ، ومن هناك انتقل إلى GLB (بهدوء ، ستكون هناك صورة وشرح أدناه)

لقد اختبرنا جميع هذه الخيارات وبعض الخيارات المختلطة الأخرى:

• Cloudflare + GLB

هذا المخطط لا يناسبنا لأخطاء الجهوزية و DNS. ولكن تم إجراء الاختبار قبل إصلاح الخلل في جزء من التليف الكيسي ، وربما يكون أفضل الآن (ومع ذلك ، فإن هذا لا يستبعد مهلات HTTP).

• علي + GLB

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

• GLB فقط

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

• شنتشن -> (CEN / IPSEC) -> الوكيل -> GLB

هنا قررنا استخدام أفضل الحلول:

• الاستقرار وضمان جيش تحرير السودان من CEN
• سرعة عالية من IPSEC
• شبكة Google "السريعة" و anycast.

يبدو المخطط مثل هذا: يتم إنهاء حركة مرور المستخدم على جهاز افتراضي في ch-shenzhen . يتم تكوين إعدادات upstream Nginx هناك ، والتي يشير بعضها إلى خوادم IP الخاصة الموجودة على الطرف الآخر من نفق IPSEC ، وبعض الاتصالات المنبع إلى عناوين الخوادم الخاصة على الجانب الآخر من CEN. تم تكوين IPSEC إلى منطقة شرق آسيا 1 في برنامج شركاء Google المعتمدون (كانت أقرب منطقة إلى الصين في الوقت الذي تم فيه إنشاء الحل. والآن يوجد برنامج شركاء Google المعتمدون أيضًا في هونج كونج). CEN - إلى المنطقة الشرقية لنا في علي كلاود.

علاوة على ذلك ، تم توجيه حركة المرور من كلا الطرفين إلى anycast IP GLB ، أي إلى أقرب نقطة تواجد لـ Google ، وانتقلت عبر شبكاتها إلى منطقة الشرق - الولايات المتحدة في GCP ، حيث كانت هناك أجهزة افتراضية بديلة (مع عامل تصفية فرعي في nginx).

هذا الحل الهجين ، كما توقعنا ، سمح لنا بالاستفادة من كل تقنية. بشكل عام ، تمر حركة المرور عبر IPSEC السريع ، ولكن إذا بدأت المشاكل ، فسنقوم بسرعة لعدة دقائق بإخراج هذه الخوادم من المنبع وإرسال حركة المرور عبر CEN فقط حتى يستقر النفق.

بعد أن طبقنا الحل الرابع من القائمة أعلاه ، حققنا ما أردنا وما طلبته منا الشركة في ذلك الوقت.

نتائج اختبار المتصفح للحل الجديد مقارنة بالحلول السابقة:

CDN

كل شيء جيد في الحل الذي قمنا بتطبيقه ، ولكن لا يوجد CDN يمكنه تسريع حركة المرور على مستوى المناطق وحتى المدن. من الناحية النظرية ، ينبغي أن يسرع هذا الموقع للمستخدمين النهائيين من خلال استخدام قنوات اتصال سريعة لمزود CDN. وفكرنا في الأمر طوال الوقت. والآن ، حان الوقت للتكرار التالي للمشروع: البحث عن موفري CDN واختبارهم في الصين.

وسوف أخبركم بهذا في الجزء الأخير ، :)

جميع الأجزاء

الجزء 1
الجزء 3