څنګه موږ د لوی چینایي فایروال له لارې مات شو (2 ​​برخه)

سلام!

نیکیتا بیا ستاسو سره دی، د شرکت څخه د سیسټم انجنیر SEMrush. او د دې مقالې سره زه پدې اړه کیسې ته دوام ورکوم چې څنګه موږ د کاري حل حل سره راغلو د چینايي فایروال زموږ د خدمت لپاره semrush.com.

В پخوانۍ برخه ما وویل:

• د پریکړې وروسته کومې ستونزې رامینځته کیږي "موږ اړتیا لرو په چین کې زموږ خدمت کار وکړو"
• د چین انټرنیټ کومې ستونزې لري؟
• تاسو ولې د ICP جواز ته اړتیا لرئ؟
• څنګه او ولې موږ پریکړه وکړه چې خپل ټیسټ بیډونه د کیچ پواینټ سره وازموئ
• د Cloudflare چین شبکې پراساس زموږ د لومړي حل پایله څه وه
• څنګه موږ په Cloudflare DNS کې بګ وموندل

دا برخه زما په نظر ترټولو زړه پورې ده، ځکه چې دا د سټینګ ځانګړي تخنیکي پلي کولو تمرکز کوي. او موږ به پیل وکړو، یا به دوام ورکړو علی بابا کلاز.

علی بابا کلاز

علی بابا کلاز یو کافي لوی کلاوډ چمتو کونکی دی ، کوم چې ټول خدمات لري چې دا اجازه ورکوي په صادقانه توګه ځان ته د بادل چمتو کونکی ووایی. دا ښه ده چې دوی د بهرنیو کاروونکو لپاره راجستر کولو فرصت لري، او دا چې ډیری سایټ په انګلیسي کې ژباړل شوی (د چین لپاره دا یو آرایشي دی). پدې بادل کې ، تاسو کولی شئ د نړۍ ډیری سیمو سره کار وکړئ ، د چین اصلي ټاټوبي ، او همدارنګه د سمندري آسیا (هانګ کانګ ، تایوان او نور).

IPIss

موږ د جغرافیې سره پیل وکړ. څرنګه چې زموږ د ازموینې سایټ په ګوګل کلاوډ کې موقعیت درلود، موږ اړتیا درلوده چې علی بابا کلاوډ د GCP سره "لینک" کړو، نو موږ د هغو ځایونو لیست پرانست چې ګوګل شتون لري. په هغه وخت کې دوی لا تر اوسه په هانګ کانګ کې د دوی د معلوماتو مرکز نه درلود.
تر ټولو نژدی سیمه وګرځیده آسیا ختیځ 1 (تایوان). علي تايوان ته د چين د اصلي ټاټوبي تر ټولو نږدې سيمه وه cn-شینزین (شینزو).

د مرستې په مرسته خاوره په GCP او علي کې ټوله زیربنا بیان او پورته کړه. د ورېځو تر منځ د 100 Mbit/s تونل نږدې سمدستي پورته شو. د شینزین او تایوان په خوا کې، د پراکسي کولو مجازی ماشینونه پورته شوي. په شینزین کې، د کاروونکي ترافیک پای ته رسیږي، د تونل له لارې تایوان ته پراکسي کیږي، او له هغه ځایه دا مستقیم زموږ د خدماتو بهرني IP ته ځي. د امریکا ختیځ (د امریکا ختیځ ساحل). د تونل له لارې د مجازی ماشینونو ترمنځ پینګ 24ms، کوم چې دومره بد ندی.

په ورته وخت کې، موږ د ازموینې ساحه کې ځای پرځای کړه علی بابا کلاوډ DNS. NS علي ته د زون د سپارلو وروسته، د حل وخت له 470 ms څخه راټیټ شو 50 MS. له دې وړاندې دغه زون هم په کلاوډلفیر کې وو.

د تونل سره موازي آسیا ختیځ 1 له شینزین څخه په مستقیم ډول یو بل تونل پورته کړ us-east4. هلته دوی ډیر پراکسي مجازی ماشینونه رامینځته کړل او د دواړو حلونو ازموینه یې پیل کړه ، د کوکیز یا DNS په کارولو سره د ټیسټ ترافیک روټینګ. د ازموینې بنچ په لاندې شکل کې په سکیماټیک ډول تشریح شوی:

د تونلونو لپاره ځنډ په لاندې ډول وګرځید:
علي cn-شینزین <—> GCP آسیا-ختیځ 1 - 24ms
علي cn-شینزین <—> GCP us-east4 — 200ms

د کیچ پواینټ براوزر ازموینې د عالي پرمختګ راپور ورکړی.

د دوه حلونو لپاره د ازموینې پایلې پرتله کړئ:

پریکړه
Uptime
میډیا
75 سلنه
95 سلنه

Cloudflare
86.6
18
30
60

IPsec
99.79
18
21
30

دا د حل څخه ډاټا ده چې د IPSEC تونل له لارې کاروي آسیا ختیځ 1. د ختیځ 4 له لارې پایلې ډیرې خرابې وې، او ډیرې غلطۍ وې، نو زه به پایلې نه ورکوم.

د دوو تونلونو د دې ازموینې د پایلو پراساس، چې یو یې چین ته نږدې سیمه کې پای ته رسیدلی، او بل یې په وروستي منزل کې، دا څرګنده شوه چې دا مهمه ده چې ژر تر ژره د چینایي اور وژنې لاندې څخه "راښکاره شي". امکان لري، او بیا ګړندي شبکې وکاروئ (CDN چمتو کونکي ، کلاوډ چمتو کونکي ، او داسې نور). اړتیا نشته چې د اور وژنې له لارې د ترلاسه کولو هڅه وکړئ او خپل منزل ته په یوه ناڅاپي توګه ورسیږئ. دا ترټولو چټکه لاره نه ده.

په عموم کې، پایلې خرابې نه دي، په هرصورت، semrush.com د 8.8s منځنۍ کچه لري، او 75 فیصده 9.4s (په ورته ازموینه کې).
او مخکې له دې چې پرمخ لاړ شم، غواړم یو لنډ شعري تحلیل وکړم.

ژبني کشش

وروسته له دې چې کاروونکي سایټ ته ننوځي 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 په شینزین کې د مجازی ماشین پته حل کوي ترڅو بیا تونل ته ننوځي.

یوازې په دې توګه، د چینایي فایروال په چټکۍ سره تیرولو لپاره ستاسو د حل له لارې د ټولو ممکنه ټرافیک په زورولو سره، تاسو کولی شئ د منلو وړ سرعت او د ویب پاڼې شتون شاخصونه، او همدارنګه د حل ازموینې صادقانه پایلې ترلاسه کړئ.
موږ دا د ټیم محصول اړخ کې د یو واحد کوډ ترمیم پرته ترسره کړل.

فرعي فلټر

د حل لاره نږدې سمدستي وروسته له دې چې دا ستونزه راپورته شوه پیدا شوه. موږ اړتیا درلوده PoC (د مفهوم ثبوت) چې زموږ د فایروال ننوتلو حلونه واقعیا ښه کار کوي. د دې کولو لپاره، تاسو اړتیا لرئ چې د سایټ ټول ټرافيک په دې حل کې د امکان تر حده وتړئ. او موږ درخواست وکړ فرعي فلټر په nginx کې.

فرعي فلټر په نګینکس کې خورا ساده ماډل دی چې تاسو ته اجازه درکوي د غبرګون بدن کې یوه کرښه بلې کرښې ته بدله کړئ. نو موږ ټول پیښې بدلې کړې semrush.com په semrushchina.cn په ټولو ځوابونو کې.

او ... دا کار ونکړ ځکه چې موږ له شالیدونو څخه کمپریس شوي مینځپانګې ترلاسه کړې ، نو فرعي فلټر اړین کرښه ونه موندله. ما باید په نګینکس کې بل ځایی سرور اضافه کړی وای، کوم چې ځواب یې کم کړ او راتلونکي محلي سرور ته یې انتقال کړ، کوم چې دمخه د تار ځای په ځای کولو، د هغې کمپریس کولو، او په سلسله کې راتلونکي پراکسي سرور ته لیږلو بوخت و.

د پایلې په توګه، پیرودونکي چیرته ترلاسه کوي .semrush.com، هغه ترلاسه کړ .semrushchina.cn او په اطاعت سره زموږ د پریکړې څخه تیر شو.

په هرصورت، دا بسیا نه ده چې په ساده ډول د ډومین یوه لاره بدله کړئ، ځکه چې پس منظر لاهم د پیرودونکي څخه په راتلونکو غوښتنو کې semrush.com تمه لري. په دې اساس، په ورته سرور کې چیرې چې یو طرفه بدیل ترسره کیږي، د ساده منظم بیان په کارولو سره موږ د غوښتنې څخه فرعي ډومین ترلاسه کوو، او بیا یې کوو پراکسي_ پاس د متغیر سره $ کوربه، په کې نندارې ته وړاندې شو $subdomain.semrush.com. دا ممکن ګډوډ ښکاري، مګر دا کار کوي. او دا ښه کار کوي. د انفرادي ډومینونو لپاره چې مختلف منطق ته اړتیا لري، په ساده ډول خپل د سرور بلاکونه جوړ کړئ او یو جلا ترتیب جوړ کړئ. لاندې د دې سکیم د روښانه کولو او ښودلو لپاره د نګینکس تشکیلات لنډ دي.

لاندې ترتیب د چین څخه ټولې غوښتنې پروسس کوي .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 تونلونو د رالویدو په اړه افسانه تایید شوې نه وه. خو بیا د تونلونو په غورځېدو پیل وکړ. په ورځ کې څو ځله د څو دقیقو لپاره. یو څه، مګر دا زموږ سره مناسب نه و. له هغه وخته چې دواړه تونلونه په ورته روټر کې د علي لوري ته وتړل شول، موږ پریکړه وکړه چې شاید دا یوه سیمه ایزه ستونزه وه او موږ اړتیا لرو چې د بیک اپ سیمه پورته کړو.

دوی یې پورته کړل. تونلونه په مختلف وختونو کې ناکامیدل پیل کړل ، مګر ناکامي زموږ لپاره په نګینکس کې د پورته کچې کچې کې ښه کار وکړ. مګر بیا په ورته وخت کې تونلونه راټیټیدل پیل کړل 🙂 او 502 او 504 بیا پیل شول. اپټایم خرابیدل پیل کړل ، نو موږ په اختیار باندې کار پیل کړ. علی بابا CEN (Cloud Enterprise Network).

CEN

CEN - دا د علی بابا کلاوډ کې د مختلف سیمو څخه د دوه VPCs ارتباط دی ، دا دی ، تاسو کولی شئ په بادل کې دننه د هرې سیمې خصوصي شبکې له یو بل سره وصل کړئ. او تر ټولو مهم: دا چینل خورا سخت دی SLA. دا دواړه په سرعت او وخت کې خورا باثباته دي. مګر دا هیڅکله دومره ساده ندي:

• دا ترلاسه کول خورا ستونزمن دي که تاسو چینایي اتباع یا قانوني نه یاست،
• تاسو اړتیا لرئ د هر میګابایټ چینل بینډ ویت لپاره تادیه وکړئ.

د نښلولو فرصت لري مینډل چین и په بهر کېموږ د دوو علي سیمو ترمنځ CEN جوړ کړ: cn-شینزین и us-east-1 (موږ ته نږدې نقطه - ختیځ4). په علي us-east-1 یو بل مجازی ماشین پورته کړ ترڅو یو بل وي Hop.

دا په دې ډول ښکاره شوه:

د براوزر ازموینې پایلې لاندې دي:

پریکړه
Uptime
میډیا
75 سلنه
95 سلنه

Cloudflare
86.6
18
30
60

IPsec
99.79
18
21
30

CEN
99.75
16
21
27

فعالیت د IPSEC په پرتله یو څه ښه دی. مګر د IPSEC له لارې تاسو کولی شئ په بالقوه توګه د 100 Mbit/s په سرعت سره ډاونلوډ کړئ، او د CEN له لارې یوازې د 5 Mbit/s او نور په سرعت کې.

د هایبرډ په څیر غږ کوي، سمه ده؟ د IPSEC سرعت او د CEN ثبات یوځای کړئ.

دا هغه څه دي چې موږ یې وکړل، د IPSEC تونل د ناکامۍ په صورت کې د IPSEC او CEN دواړو له لارې ترافیک ته اجازه ورکړه. اپټایم خورا لوړ شوی ، مګر د سایټ بار کولو سرعت لاهم د مطلوب کیدو لپاره ډیر څه پریږدي. بیا ما ټول هغه سرکټونه رسم کړل چې موږ دمخه کارولي او ازمول شوي و ، او پریکړه یې وکړه چې پدې سرکټ کې یو څه نور GCP اضافه کولو هڅه وکړم ، یعنی خولۍ.

خولۍ

خولۍ دی د نړیوال بار بیلانسر (یا د ګوګل کلاوډ بار بیلانسر). دا زموږ لپاره یوه مهمه ګټه لري: د CDN په شرایطو کې دا لري anycast IP، کوم چې تاسو ته اجازه درکوي ټرافيک د پیرودونکي ته نږدې ډیټا مرکز ته واستوئ ، ترڅو ترافیک په چټکۍ سره د ګوګل ګړندي شبکې ته ننوځي او لږ د "منظم" انټرنیټ له لارې تیریږي.

پرته له دې چې دوه ځله فکر وکړو، موږ پورته کړ HTTP/HTTPS LB موږ خپل مجازی ماشینونه په GCP کې د فرعي فلټر سره او د شالید په توګه نصب کړل.

ډیری سکیمونه شتون درلود:

• استعمال د Cloudflare چین شبکه، مګر دا ځل اصلي باید نړیوال مشخص کړي IP GLB.
• مراجعین په کې ختم کړئ cn-شینزین، او له هغه ځایه ترافیک مستقیم پراکسي کړئ خولۍ.
• له چین څخه مستقیم ته لاړ شئ خولۍ.
• مراجعین په کې ختم کړئ cn-شینزین، له هغه ځایه پراکسي ته آسیا ختیځ 1 د IPSEC له لارې (په us-east4 د CEN له لارې)، له هغه ځایه GLB ته لاړ شئ (په آرامۍ سره، لاندې به یو انځور او تشریح وي)

موږ دا ټول اختیارونه او څو نور هایبرډ ازمویل:

• Cloudflare + GLB

دا سکیم زموږ د وخت او DNS غلطیتونو له امله مناسب نه و. مګر ازموینه مخکې له دې ترسره شوې وه چې بګ په CF اړخ کې تنظیم شوی و ، شاید دا اوس غوره وي (په هرصورت ، دا د HTTP مهال ویش نه خارجوي).

• علي + GLB

دا سکیم موږ ته د اپټایم په شرایطو کې هم مناسب نه و ، ځکه چې GLB ډیری وختونه د منلو وړ وخت یا وخت پای کې د وصل کیدو ناشونې له امله له اپ سټریم څخه راوتلی ، ځکه چې په چین کې دننه د سرور لپاره ، د GLB پته بهر پاتې کیږي ، او له همدې امله تر شا. چینایي اور وژونکي. جادو ونه شو.

• یوازې GLB

یو اختیار د تیر په څیر، یوازې دا پخپله په چین کې سرورونه نه کاروي: ټرافيک مستقیم GLB ته لاړ (د DNS ریکارډونه بدل شوي). په دې اساس، پایلې د قناعت وړ نه وې، ځکه چې عادي چینایي پیرودونکي د عادي انټرنیټ چمتو کونکو خدماتو څخه کار اخلي د علي کلاوډ په پرتله د فایر وال په تیریدو سره خورا بد حالت لري.

• شینزین -> (CEN/IPSEC) -> پراکسي -> GLB

دلته موږ پریکړه وکړه چې د ټولو غوره حلونو څخه کار واخلو:

• ثبات او د CEN څخه تضمین شوی SLA
• د IPSEC څخه لوړ سرعت
• د ګوګل "چټک" شبکه او د هغې هر ډول.

سکیم یو څه داسې ښکاري: د کاروونکي ترافیک په مجازی ماشین کې پای ته رسیدلی ch-شینزین. د نګینکس اپ سټریمونه هلته تنظیم شوي ، چې ځینې یې د شخصي IP سرورونو ته اشاره کوي چې د IPSEC تونل په بل پای کې موقعیت لري ، او ځینې اپ سټریمونه د CEN بل اړخ کې د سرورونو شخصي پته په ګوته کوي. IPSEC سیمې ته ترتیب شوی آسیا ختیځ 1 په GCP کې (د حل په وخت کې چین ته ترټولو نږدې سیمه وه. GCP اوس په هانګ کانګ کې هم شتون لري). CEN - سیمې ته us-east1 په علي بادل کې.

بیا د دواړو خواو څخه ترافیک ته لارښوونه وشوه anycast IP GLB، دا دی، د ګوګل د شتون نږدې ټکي ته، او د خپلو شبکو له لارې سیمې ته لاړ us-east4 په GCP کې، په کوم کې چې د بدیل مجازی ماشینونه شتون درلود (په نګینکس کې د فرعي فلټر سره).

دا هایبرډ حل، لکه څنګه چې موږ تمه درلوده، د هرې ټیکنالوژۍ ګټو څخه ګټه پورته کړه. په عموم کې، ټرافیک په چټکۍ سره د IPSEC له لارې تیریږي، مګر که ستونزې پیل شي، موږ په چټکۍ سره او د څو دقیقو لپاره دا سرورونه د پورته جریان څخه لرې کوو او ټرافيک یوازې د CEN له لارې لیږو تر هغه چې تونل ثبات نه وي.

د پورته لیست څخه د څلورم حل په پلي کولو سره، موږ هغه څه ترلاسه کړل چې موږ یې غوښتل او هغه څه چې سوداګرۍ زموږ څخه په دې وخت کې ورته اړتیا درلوده.

د پخوانیو په پرتله د نوي حل لپاره د براوزر ازموینې پایلې:

پریکړه
Uptime
میډیا
75 سلنه
95 سلنه

Cloudflare
86.6
18
30
60

IPsec
99.79
18
21
30

CEN
99.75
16
21
27

CEN/IPsec + GLB
99.79
13
16
25

CDN

هرڅه په هغه حل کې چې موږ یې پلي کړي ښه دي، مګر هیڅ CDN شتون نلري چې کولی شي په سیمه ایز او حتی د ښار په کچه ترافیک ګړندی کړي. په تیوري کې، دا باید د CDN چمتو کونکي ګړندي مخابراتي چینلونو په کارولو سره د پای کاروونکو لپاره سایټ ګړندی کړي. او موږ هر وخت د هغې په اړه فکر کاوه. او اوس، د پروژې د راتلونکي تکرار لپاره وخت راغلی: په چین کې د CDN چمتو کونکو لټون او ازموینه.

او زه به تاسو ته پدې اړه په راتلونکي ، وروستۍ برخه کې ووایم :)

سرچینه: www.habr.com