Ұлы Қытай брандмауэрін қалай бұздық (2-бөлім)

Сәлем!

Никита тағы да сізбен, компанияның инженер-жүйелік инженері SEMrush. Осы мақаламен мен мәселені шешудің жолын қалай тапқанымыз туралы әңгімені жалғастырамын Қытайлық брандмауэр semrush.com қызметіміз үшін.

В алдыңғы бөлім Мен айттым:

• «Біз Қытайда қызмет көрсетуіміз керек» шешім қабылданғаннан кейін қандай мәселелер туындайды
• Қытай интернетінде қандай проблемалар бар?
• Сізге ICP лицензиясы не үшін қажет?
• қалай және неге біз сынақ алаңдарын Catchpoint көмегімен сынауды шештік
• Cloudflare China Network негізіндегі бірінші шешіміміздің нәтижесі қандай болды
• Cloudflare DNS жүйесінде қатені қалай таптық

Бұл бөлім, менің ойымша, ең қызықты, өйткені ол қойылымның нақты техникалық іске асыруларына бағытталған. Ал біз бастаймыз, дәлірек айтсақ, жалғастырамыз Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud өзін бұлттық провайдер деп атауға мүмкіндік беретін барлық қызметтері бар өте үлкен бұлттық провайдер болып табылады. Олардың шетелдік пайдаланушылар үшін тіркелу мүмкіндігі бар және сайттың көп бөлігі ағылшын тіліне аударылғаны жақсы (Қытай үшін бұл сән-салтанат). Бұл бұлтта сіз әлемнің көптеген аймақтарымен, материктік Қытаймен, сондай-ақ мұхиттық Азиямен (Гонконг, Тайвань және т.б.) жұмыс істей аласыз.

IPSEC

Біз географиядан бастадық. Біздің сынақ сайтымыз Google Cloud-та орналасқандықтан, бізге Alibaba Cloud-ты GCP-мен «байланыстыру» керек болды, сондықтан біз Google бар орындардың тізімін аштық. Ол кезде олардың Гонконгта әлі жеке деректер орталығы болған жоқ.
Ең жақын аймақ болып шықты Азия-Шығыс1 (Тайвань). Әли материктік Қытайдың Тайваньға ең жақын аймағы болып шықты cn-shenzhen (Шэньчжэнь).

Көмегімен терраформ GCP және Алидегі барлық инфрақұрылымды сипаттады және көтерді. Бұлттар арасындағы 100 Мбит/с туннель бірден көтерілді. Шэньчжэнь мен Тайвань жағында прокси виртуалды машиналар көтерілді. Шэньчжэньде пайдаланушы трафигі тоқтатылады, туннель арқылы Тайваньға проксиге жіберіледі және сол жерден ол тікелей біздің қызметіміздің сыртқы IP мекенжайына өтеді. біз-шығыс (АҚШ-тың шығыс жағалауы). Туннель арқылы виртуалды машиналар арасындағы пинг 24ms, бұл соншалықты жаман емес.

Сонымен бірге біз сынақ алаңын орналастырдық Alibaba Cloud DNS. Аймақты NS Алиге бергеннен кейін ажыратымдылық уақыты 470 мс-ден қысқарды 50 мс. Бұған дейін аймақ Cloudlfare-де де болды.

-ға туннельге параллель Азия-Шығыс1 Шэньчжэньден тура басқа туннельді көтерді АҚШ-шығыс4. Онда олар көбірек прокси виртуалды машиналарын жасап, Cookie файлдары немесе DNS арқылы сынақ трафигін бағыттай отырып, екі шешімді де сынай бастады. Сынақ үстелі келесі суретте схемалық түрде сипатталған:

Туннельдердің кешігуі келесідей болды:
Али cn-shenzhen <—> GCP asia-east1 — 24ms
Али cn-shenzhen <—> GCP us-east4 — 200ms

Catchpoint шолғыш сынақтары тамаша жақсартулар туралы хабарлады.

Екі шешім үшін сынақ нәтижелерін салыстырыңыз:

шешім
Жұмыс уақыты
Медиана
75 пайыздық
95 пайыздық

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Бұл IPSEC туннелі арқылы пайдаланатын шешімнің деректері Азия-Шығыс1. us-est4 арқылы нәтижелер нашар болды және қателер көп болды, сондықтан мен нәтижелерді бермеймін.

Біреуі Қытайға ең жақын аймақта, ал екіншісі соңғы нүктеде аяқталатын екі туннельді сынау нәтижелеріне сүйене отырып, қытайлық брандмауэрдің астынан тез арада «шығу» маңызды екені белгілі болды. мүмкін, содан кейін жылдам желілерді пайдаланыңыз (CDN провайдерлері, бұлттық провайдерлер және т.б.). Брандмауэр арқылы өтуге тырысудың қажеті жоқ және межелі жерге бір соққымен жетуге болады. Бұл ең жылдам әдіс емес.

Жалпы алғанда, нәтижелер жаман емес, дегенмен semrush.com сайтында медиана 8.8 және 75 пайыздық 9.4 секунд (сол сынақта) бар.
Әрі қарай қозғалмас бұрын мен қысқаша лирикалық шегініс жасағым келеді.

Лирикалық шегіну

Пайдаланушы сайтқа кіргеннен кейін www.semrushchina.cn, ол «жылдам» қытай DNS серверлері арқылы шешіледі, HTTP сұрауы біздің жылдам шешіміміз арқылы өтеді. Жауап бір жол бойымен қайтарылады, бірақ домен барлық JS сценарийлерінде, HTML беттерінде және веб-беттің басқа элементтерінде көрсетілген. semrush.com бет көрсетілген кезде жүктелуі тиіс қосымша ресурстар үшін. Яғни, клиент «негізгі» А-жазбасын шешеді www.semrushchina.cn және жылдам туннельге кіреді, тез жауап алады - HTML беті, онда мыналар айтылады:

• sso.semrush.com сайтынан осындай және осындай js жүктеп алыңыз,
• CSS файлдарын cdn.semrush.com сайтынан алыңыз,
• сонымен қатар dab.semrush.com сайтынан бірнеше суретке түсіріңіз
• тағыда басқа.

Браузер осы ресурстар үшін «сыртқы» Интернетке шыға бастайды, әр жолы жауап беру уақытын азайтатын брандмауэр арқылы өтеді.

Бірақ алдыңғы сынақ бетте ресурстар болмаған кезде нәтижелерді көрсетеді semrush.com, тек semrushchina.cn, және *.semrushchina.cn туннельге кіру үшін Шэньчжэньдегі виртуалды машинаның мекенжайын шешеді.

Тек осылай ғана, қытайлық брандмауэрді жылдам өту үшін шешіміңіз арқылы барлық мүмкін трафикті барынша итермелеу арқылы қолайлы жылдамдықтар мен веб-сайттың қолжетімділік көрсеткіштерін, сондай-ақ шешім сынақтарының шынайы нәтижелерін ала аласыз.
Біз мұны команданың өнім жағында бір кодты өңдеусіз жасадық.

Ішкі сүзгі

Шешім бұл мәселе туындағаннан кейін бірден пайда болды. Бізге керек еді PoC (Тұжырымдаманың дәлелі) біздің желіаралық қалқанға ену шешімдері шынымен жақсы жұмыс істейді. Мұны істеу үшін сізге сайттың барлық трафигін мүмкіндігінше осы шешімге орау керек. Ал біз өтініш бердік ішкі сүзгі nginx ішінде.

Ішкі сүзгі жауап корпусындағы бір жолды басқа жолға өзгертуге мүмкіндік беретін 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 қайтадан басталды. Жұмыс уақыты нашарлай бастады, сондықтан біз опциямен жұмыс істей бастадық. Alibaba CEN (Cloud Enterprise Network).

CEN

CEN - бұл Alibaba Cloud ішінде әртүрлі аймақтардағы екі VPC қосылымы, яғни бұлт ішіндегі кез келген аймақтардың жеке желілерін бір-бірімен қосуға болады. Ең бастысы: бұл арнада өте қатаң SLA. Ол жылдамдықта да, жұмыс уақытында да өте тұрақты. Бірақ бұл ешқашан қарапайым емес:

• егер сіз Қытай азаматы немесе заңды тұлға болмасаңыз, оны алу өте қиын,
• Арна өткізу қабілетінің әрбір мегабитіне ақы төлеу керек.

Қосылу мүмкіндігі бар Қытай Халық Республикасы и Overseas, біз екі Али аймағы арасында CEN құрдық: cn-shenzhen и АҚШ-шығыс-1 (бізге ең жақын нүкте-шығыс4). Әлиде АҚШ-шығыс-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 арқылы трафикке рұқсат беріп, осылай істедік. Жұмыс уақыты әлдеқайда жоғарылады, бірақ сайтты жүктеу жылдамдығы әлі де көп нәрсені қажет етеді. Содан кейін мен бұрыннан қолданылған және сыналған барлық схемаларды сыздым және осы схемаға GCP-ті аздап қосуға тырыстым, атап айтқанда Қақпақ.

Қақпақ

Қақпақ Мүмкін Жаһандық Load Balancer (немесе Google Cloud Load Balancer). Оның біз үшін маңызды артықшылығы бар: CDN контекстінде ол бар кез келген тарату IP, бұл трафикті клиентке ең жақын деректер орталығына бағыттауға мүмкіндік береді, осылайша трафик Google жылдам желісіне тез түседі және «тұрақты» Интернет арқылы аз өтеді.

Екі рет ойланбастан, көтердік HTTP/HTTPS LB Біз виртуалды машиналарымызды GCP жүйесінде ішкі сүзгісі бар және сервер ретінде орнаттық.

Бірнеше схемалар болды:

• Пайдаланыңыз Cloudflare Қытай желісі, бірақ бұл жолы Origin жаһандық мәнін көрсетуі керек IP GLB.
• Клиенттерді тоқтатыңыз cn-shenzhen, және сол жерден трафикті тікелей прокси Қақпақ.
• Қытайдан тікелей барыңыз Қақпақ.
• Клиенттерді тоқтатыңыз cn-shenzhen, сол жерден прокси Азия-Шығыс1 IPSEC арқылы (in АҚШ-шығыс4 CEN арқылы), сол жерден GLB-ге өтіңіз (жай, төменде сурет пен түсініктеме болады)

Біз осы опциялардың барлығын және тағы бірнеше гибридті нұсқаларды сынап көрдік:

• Cloudflare + GLB

Бұл схема жұмыс уақыты мен DNS қателеріне байланысты бізге сәйкес келмеді. Бірақ сынақ CF жағында қате түзетілгенге дейін жүргізілді, мүмкін қазір жақсырақ (бірақ бұл HTTP күту уақытын жоққа шығармайды).

• Али + GLB

Бұл схема жұмыс уақыты тұрғысынан да бізге сәйкес келмеді, өйткені GLB қолайлы уақытта немесе күту уақытында қосылу мүмкін еместігіне байланысты жиі жоғары ағыннан шығып қалады, өйткені Қытайдағы сервер үшін GLB мекенжайы сыртта қалады, сондықтан оның артында қалады. Қытайлық брандмауэр. Сиқыр болмады.

• Тек GLB

Алдыңғы нұсқаға ұқсас опция, тек Қытайдың өзінде серверлерді пайдаланбады: трафик тікелей GLB-ге өтті (DNS жазбалары өзгертілді). Тиісінше, нәтижелер қанағаттанарлық емес, өйткені қарапайым интернет-провайдерлердің қызметтерін пайдаланатын қарапайым қытайлық клиенттердің Ali Cloud-қа қарағанда брандмауэрді өту жағдайы әлдеқайда нашар.

• Шэньчжэнь -> (CEN/IPSEC) -> Прокси -> GLB

Мұнда біз барлық шешімдердің ең жақсысын пайдалануды шештік:

• тұрақтылық және CEN кепілді SLA
• IPSEC-тен жоғары жылдамдық
• Google-дың «жылдам» желісі және оның кез келген трансляциясы.

Схема келесідей көрінеді: пайдаланушы трафигі виртуалды машинада тоқтатылады ч-шэньчжэнь. Nginx жоғары ағындары сонда конфигурацияланған, олардың кейбіреулері IPSEC туннелінің екінші жағында орналасқан жеке IP серверлеріне нұсқайды, ал кейбір жоғары ағындар CEN екінші жағындағы серверлердің жеке мекенжайларына нұсқайды. IPSEC аймаққа теңшелген Азия-Шығыс1 GCP-де (шешім жасалған кезде Қытайға ең жақын аймақ болды. GCP қазір Гонконгта да бар). CEN - аймаққа АҚШ-шығыс1 Али бұлтта.

Одан кейін екі шетінен көлік қозғалысы бағытталды anycast IP GLB, яғни Google-дың ең жақын нүктесіне дейін және оның желілері арқылы аймаққа барды АҚШ-шығыс4 GCP-де, онда ауыстырылатын виртуалды машиналар (nginx-тегі ішкі сүзгісі бар).

Бұл гибридті шешім, біз күткендей, әрбір технологияның артықшылықтарын пайдаланды. Жалпы, трафик жылдам IPSEC арқылы өтеді, бірақ проблемалар туындаса, біз жылдам және бірнеше минут ішінде бұл серверлерді жоғары ағыннан шығарамыз және туннель тұрақтанғанша трафикті тек CEN арқылы жібереміз.

Жоғарыдағы тізімдегі 4-ші шешімді енгізу арқылы біз өзіміз қалаған нәрсеге және сол уақытта бизнес бізден талап еткен нәрсеге қол жеткіздік.

Алдыңғылармен салыстырғанда жаңа шешімге арналған шолғыш сынақтарының нәтижелері:

шешім
Жұмыс уақыты
Медиана
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