چگونه از فایروال بزرگ چینی شکستیم (قسمت 2)

سلام!

نیکیتا دوباره با شما است، یک مهندس سیستم از این شرکت SEMrush. و با این مقاله من داستان را در مورد اینکه چگونه به یک راه حل دست یافتیم ادامه می دهم فایروال چینی برای خدمات ما semrush.com.

В قسمت قبلی گفتم:

• چه مشکلاتی پس از تصمیم گیری ایجاد می شود "ما باید خدمات خود را در چین انجام دهیم"
• اینترنت چینی چه مشکلاتی دارد؟
• چرا به مجوز ICP نیاز دارید؟
• چگونه و چرا تصمیم گرفتیم بسترهای آزمایشی خود را با Catchpoint آزمایش کنیم
• نتیجه اولین راه حل ما بر اساس شبکه Cloudflare چین چه بود
• چگونه یک باگ در Cloudflare DNS پیدا کردیم

این بخش به نظر من جالب‌ترین بخش است، زیرا بر روی پیاده‌سازی‌های فنی خاص صحنه‌سازی تمرکز دارد. و با شروع یا بهتر بگوییم ادامه خواهیم داد Alibaba ابر.

Alibaba ابر

Alibaba ابر یک ارائه‌دهنده ابر نسبتاً بزرگ است که تمام خدماتی را دارد که به آن اجازه می‌دهد صادقانه خود را ارائه‌دهنده ابر بنامد. خوب است که آنها فرصت ثبت نام برای کاربران خارجی را دارند و بیشتر سایت به انگلیسی ترجمه شده است (برای چین این یک لوکس است). در این ابر می توانید با بسیاری از مناطق جهان، سرزمین اصلی چین و همچنین آسیای اقیانوسی (هنگ کنگ، تایوان و غیره) کار کنید.

IPsec

ما با جغرافیا شروع کردیم. از آنجایی که سایت آزمایشی ما در Google Cloud قرار داشت، باید Alibaba Cloud را با GCP «پیوند» کنیم، بنابراین فهرستی از مکان‌هایی را که Google در آنها حضور دارد باز کردیم. در آن لحظه آنها هنوز مرکز داده خود را در هنگ کنگ نداشتند.
نزدیکترین منطقه معلوم شد آسیا- شرق 1 (تایوان). معلوم شد که علی نزدیکترین منطقه سرزمین اصلی چین به تایوان است cn-shenzhen (شنژن).

با terraform کل زیرساخت را در GCP و علی توصیف و مطرح کرد. یک تونل 100 مگابیت بر ثانیه بین ابرها تقریباً بلافاصله بالا رفت. در سمت شنژن و تایوان، ماشین‌های مجازی پروکسی مطرح شدند. در شنژن، ترافیک کاربر خاتمه می یابد، از طریق یک تونل به تایوان پروکسی می شود، و از آنجا مستقیماً به IP خارجی سرویس ما در ما-شرق (ساحل شرقی ایالات متحده آمریکا). پینگ بین ماشین های مجازی از طریق تونل 24ms، که آنقدرها هم بد نیست.

در همان زمان، ما یک منطقه آزمایشی را در آن قرار دادیم Alibaba Cloud DNS. پس از واگذاری منطقه به NS Ali، زمان تفکیک از 470 میلی ثانیه به کاهش یافت MS 50. قبل از این، منطقه همچنین در Cloudlfare بود.

به موازات تونل به آسیا- شرق 1 تونل دیگری را از شنژن به طور مستقیم به بالا برد us-east4. در آنجا ماشین‌های مجازی پراکسی بیشتری ایجاد کردند و شروع به آزمایش هر دو راه‌حل، مسیریابی ترافیک آزمایشی با استفاده از کوکی‌ها یا DNS کردند. میز تست به صورت شماتیک در شکل زیر توضیح داده شده است:

تأخیر برای تونل ها به شرح زیر است:
Ali cn-shenzhen <—> GCP asia-east1 — 24ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

تست‌های مرورگر Catchpoint بهبود بسیار خوبی را گزارش کردند.

مقایسه نتایج آزمایش برای دو راه حل:

تصمیم
آپ تایم
متوسط
75 درصد
95 درصد

CloudFlare را
86.6
18s
30s
60s

IPsec
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 به آدرس ماشین مجازی در شنژن حل می شود تا سپس وارد تونل شود.

تنها از این طریق، با حداکثر رساندن ترافیک ممکن از طریق راه حل خود برای عبور سریع از فایروال چینی، می توانید سرعت قابل قبول و شاخص های در دسترس بودن وب سایت و همچنین نتایج صادقانه تست های راه حل را بدست آورید.
ما این کار را بدون یک ویرایش کد در سمت محصول تیم انجام دادیم.

زیر فیلتر

راه حل تقریبا بلافاصله پس از ظهور این مشکل متولد شد. نیاز داشتیم پوک (اثبات مفهوم) که راه حل های نفوذ فایروال ما واقعاً خوب کار می کنند. برای انجام این کار، باید تمام ترافیک سایت را تا حد امکان در این راه حل بپیچید. و ما درخواست دادیم زیر فیلتر در nginx

زیر فیلتر یک ماژول نسبتا ساده در nginx است که به شما امکان می دهد یک خط در بدنه پاسخ را به خط دیگر تغییر دهید. بنابراین ما همه موارد را تغییر دادیم semrush.com بر semrushchina.cn در همه پاسخ ها

و... کار نکرد زیرا محتوای فشرده شده را از backend دریافت کردیم، بنابراین زیرفیلتر خط مورد نیاز را پیدا نکرد. مجبور شدم سرور محلی دیگری را به nginx اضافه کنم که پاسخ را از حالت فشرده خارج کرد و به سرور محلی بعدی که قبلاً مشغول جایگزینی رشته، فشرده سازی آن و ارسال آن به سرور پراکسی بعدی در زنجیره بود، ارسال کرد.

در نتیجه، مشتری از کجا دریافت خواهد کرد .semrush.com، او دریافت کرد .semrushchina.cn و مطیعانه از تصمیم ما گذشت.

با این حال، تنها تغییر دامنه یک طرفه کافی نیست، زیرا باطن ها همچنان در درخواست های بعدی مشتری از semrush.com انتظار دارند. بر این اساس، در همان سروری که جایگزینی یک طرفه انجام می شود، با استفاده از یک عبارت منظم ساده، ساب دامنه را از درخواست دریافت می کنیم و سپس انجام می دهیم. پروکسی_گذر با متغیر میزبان $، به نمایش گذاشته شده در $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;
    }
}

این پیکربندی پروکسی به localhost را به پورت 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 تایید نشد. اما پس از آن تونل ها شروع به سقوط کردند. چند بار در روز به مدت چند دقیقه. کمی، اما این به ما نمی خورد. از آنجایی که هر دو تونل در سمت علی در یک روتر خاتمه یافتند، ما به این نتیجه رسیدیم که شاید این یک مشکل منطقه ای است و باید منطقه پشتیبان را افزایش دهیم.

آن را برداشتند. تونل ها در زمان های مختلف شروع به شکست کردند، اما failover برای ما در سطح بالادست در nginx خوب کار کرد. اما پس از آن تونل ها تقریباً در همان زمان شروع به سقوط کردند 🙂 و 502 و 504 دوباره شروع به کار کردند. Uptime شروع به خراب شدن کرد، بنابراین ما شروع به کار روی گزینه با علی بابا CEN (شبکه سازمانی ابری).

CEN

CEN - این اتصال دو VPC از مناطق مختلف در Alibaba Cloud است، یعنی می توانید شبکه های خصوصی هر منطقه را در فضای ابری به یکدیگر متصل کنید. و از همه مهمتر: این کانال نسبتاً سختگیرانه است SLA. هم از نظر سرعت و هم از نظر آپتایم بسیار پایدار است. اما هرگز به این سادگی نیست:

• اگر شهروند چینی یا یک شخص حقوقی نباشید، به دست آوردن آن بسیار دشوار است،
• برای هر مگابیت پهنای باند کانال باید هزینه پرداخت کنید.

داشتن فرصت ارتباط سرزمین اصلی چین и خارج از کشور، ما یک CEN بین دو منطقه علی ایجاد کردیم: cn-shenzhen и us-east-1 (نزدیک ترین نقطه به us-east4). در علی us-east-1 ماشین مجازی دیگری را مطرح کرد تا یک ماشین دیگر وجود داشته باشد هاپ.

اینطور معلوم شد:

نتایج تست مرورگر به شرح زیر است:

تصمیم
آپ تایم
متوسط
75 درصد
95 درصد

CloudFlare را
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

عملکرد کمی بهتر از IPSEC است. اما از طریق IPSEC می توانید با سرعت 100 مگابیت بر ثانیه و از طریق CEN فقط با سرعت 5 مگابیت بر ثانیه و بیشتر دانلود کنید.

شبیه ترکیبی به نظر می رسد، درست است؟ سرعت IPSEC و ثبات CEN را با هم ترکیب کنید.

این همان کاری است که ما انجام دادیم، و در صورت خرابی تونل IPSEC، امکان تردد از طریق IPSEC و CEN را فراهم کردیم. Uptime بسیار بالاتر شده است، اما سرعت بارگذاری سایت هنوز چیزهای زیادی برای دلخواه باقی می گذارد. سپس تمام مدارهایی را که قبلاً استفاده و آزمایش کرده بودیم ترسیم کردم و تصمیم گرفتم تا کمی GCP بیشتر به این مدار اضافه کنم. کلاه لبه دار.

کلاه لبه دار

کلاه لبه دار - آیا متعادل کننده بار جهانی (یا Google Cloud Load Balancer). این یک مزیت مهم برای ما دارد: در زمینه CDN که دارد آی پی anycast، که به شما امکان می دهد ترافیک را به مرکز داده نزدیک به مشتری هدایت کنید، به طوری که ترافیک به سرعت وارد شبکه سریع Google شود و کمتر از طریق اینترنت "معمولی" عبور کند.

بدون دوبار فکر کردن، بزرگ کردیم HTTP/HTTPS LB ما ماشین‌های مجازی خود را با فیلتر فرعی در GCP و به عنوان یک Backend نصب کردیم.

چندین طرح وجود داشت:

• استفاده کنید شبکه Cloudflare چین، اما این بار Origin باید global را مشخص کند IP GLB.
• خاتمه مشتریان در cn-shenzhen، و از آنجا ترافیک را مستقیماً به پروکسی کنید کلاه لبه دار.
• مستقیم از چین به کلاه لبه دار.
• خاتمه مشتریان در cn-shenzhen، از آنجا پروکسی به آسیا- شرق 1 از طریق IPSEC (در us-east4 از طریق CEN)، از آنجا به GLB بروید (با آرامش، یک تصویر و توضیح در زیر وجود دارد)

ما همه این گزینه ها و چندین گزینه هیبریدی دیگر را آزمایش کردیم:

• Cloudflare + GLB

این طرح به دلیل آپتایم و خطاهای DNS مناسب ما نیست. اما آزمایش قبل از رفع اشکال در سمت CF انجام شد، شاید اکنون بهتر باشد (با این حال، این زمان‌های HTTP را حذف نمی‌کند).

• علی + جی ال بی

این طرح همچنین از نظر زمان آپتایم مناسب ما نیست، زیرا GLB اغلب به دلیل عدم امکان اتصال در زمان قابل قبول یا مهلت زمانی از بالادست خارج می شود، زیرا برای یک سرور در داخل چین، آدرس GLB در خارج باقی می ماند و بنابراین در پشت فایروال چینی جادو اتفاق نیفتاد

• فقط GLB

گزینه ای مشابه گزینه قبلی، فقط از سرورهای خود در چین استفاده نمی کرد: ترافیک مستقیماً به GLB رفت (سوابق DNS تغییر کردند). بر این اساس، نتایج رضایت بخش نبود، زیرا مشتریان عادی چینی که از خدمات ارائه دهندگان اینترنت معمولی استفاده می کنند، وضعیت بسیار بدتری با عبور از فایروال نسبت به Ali Cloud دارند.

• شنژن -> (CEN/IPSEC) -> پروکسی -> GLB

در اینجا تصمیم گرفتیم از بهترین راه حل ها استفاده کنیم:

• ثبات و SLA تضمین شده از CEN
• سرعت بالا از IPSEC
• شبکه «سریع» Google و anycast آن.

این طرح چیزی شبیه به این به نظر می رسد: ترافیک کاربر در یک ماشین مجازی خاتمه می یابد ch-shenzhen. بالادست‌های Nginx در آنجا پیکربندی شده‌اند، برخی از آنها به سرورهای IP خصوصی واقع در انتهای دیگر تونل IPSEC و برخی از بالادست‌ها به آدرس‌های خصوصی سرورها در طرف دیگر CEN اشاره می‌کنند. IPSEC برای منطقه پیکربندی شده است آسیا- شرق 1 در GCP (در زمان ایجاد راه حل نزدیکترین منطقه به چین بود. GCP اکنون در هنگ کنگ نیز حضور دارد). CEN - به منطقه us-east1 در ابر علی

سپس ترافیک از دو طرف هدایت شد anycast IP GLB، یعنی به نزدیکترین نقطه حضور گوگل و از طریق شبکه های خود به منطقه رفت us-east4 در GCP، که در آن ماشین های مجازی جایگزین (با زیر فیلتر در nginx) وجود داشت.

این راه حل ترکیبی، همانطور که انتظار داشتیم، از مزایای هر فناوری بهره برد. به طور کلی، ترافیک از طریق IPSEC سریع انجام می شود، اما در صورت شروع مشکلات، ما به سرعت و برای چند دقیقه این سرورها را از بالادست خارج می کنیم و تا زمانی که تونل تثبیت شود، ترافیک را فقط از طریق CEN ارسال می کنیم.

با اجرای راه حل چهارم از لیست بالا، به آنچه می خواستیم و آنچه کسب و کار در آن مقطع زمانی از ما می خواست دست یافتیم.

نتایج تست مرورگر برای راه حل جدید در مقایسه با راه حل های قبلی:

تصمیم
آپ تایم
متوسط
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 در چین.

و در قسمت بعدی و پایانی در این مورد به شما خواهم گفت :)

منبع: www.habr.com