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

مرحبا!

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

В الجزء السابق انا قلت:

• ما هي المشاكل التي تنشأ بعد اتخاذ القرار "نحن بحاجة إلى جعل خدمتنا تعمل في الصين"
• ما هي المشاكل التي يعاني منها الإنترنت الصيني؟
• لماذا تحتاج إلى ترخيص ICP؟
• كيف ولماذا قررنا اختبار أجهزة الاختبار الخاصة بنا باستخدام Catchpoint
• ماذا كانت نتيجة الحل الأول الذي قدمناه استنادًا إلى شبكة Cloudflare China Network؟
• كيف وجدنا خطأ في Cloudflare DNS

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

بابا الغيمة

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

IPsec

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

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

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

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

وتبين أن الكمون للأنفاق هو كما يلي:
علي cn-sh Shenzhen <—> GCP asia-east1 - 24 مللي ثانية
علي CN- شنتشن <—> GCP us-east4 - 200 مللي ثانية

أظهرت اختبارات متصفح Catchpoint تحسنًا ممتازًا.

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

حل
الجهوزية
متوسط
75 بالمائة
95 بالمائة

كلودفلاري
86.6
18s
30s
60s

أمن بروتوكول الإنترنت
99.79
18s
21s
30s

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

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

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

استطرادا غنائي

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

• قم بتنزيل كذا وكذا js من sso.semrush.com،
• احصل على ملفات CSS من cdn.semrush.com،
• وكذلك التقاط بعض الصور من dab.semrush.com
• وهلم جرا.

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

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

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

عامل التصفية الفرعي

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

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

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

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

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

س.

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

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

وجود الفرصة للاتصال الصين и ما وراء البحار، أنشأنا CEN بين منطقتين علي: cn-شنتشن и لنا شرق-1 (أقرب نقطة لنا-East4). في علي لنا شرق-1 رفعت جهازًا افتراضيًا آخر بحيث يكون هناك جهاز آخر قفز.

اتضح مثل هذا:

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

حل
الجهوزية
متوسط
75 بالمائة
95 بالمائة

كلودفلاري
86.6
18s
30s
60s

أمن بروتوكول الإنترنت
99.79
18s
21s
30s

س.
99.75
16s
21s
27s

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

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

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

GLB

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

دون التفكير مرتين، قمنا بتربيتنا HTTP/HTTPS رطل لقد قمنا بتثبيت أجهزتنا الافتراضية مع مرشح فرعي في Google Cloud Platform وكواجهة خلفية.

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

• استخدم شبكة كلاودفلير الصينية، ولكن هذه المرة يجب أن يحدد Origin.global IP GLB.
• إنهاء العملاء في cn-شنتشنومن هناك وكيل حركة المرور مباشرة إلى GLB.
• انتقل مباشرة من الصين إلى GLB.
• إنهاء العملاء في cn-شنتشن، من هناك وكيل ل آسيا والشرق 1 عبر IPSEC (في لنا-الشرق4 عبر CEN)، ومن هناك انتقل إلى GLB (بهدوء، ستكون هناك صورة وشرح أدناه)

لقد اختبرنا كل هذه الخيارات والعديد من الخيارات الهجينة:

• كلاود فلير + جي إل بي

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

• علي + جلب

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

• جي إل بي فقط

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

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

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

• الاستقرار وSLA مضمونة من CEN
• سرعة عالية من IPSEC
• شبكة Google "السريعة" وبثها المتوفر.

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

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

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

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

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

حل
الجهوزية
متوسط
75 بالمائة
95 بالمائة

كلودفلاري
86.6
18s
30s
60s

أمن بروتوكول الإنترنت
99.79
18s
21s
30s

س.
99.75
16s
21s
27s

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

CDN

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

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

المصدر: www.habr.com