Me çawa ji Firewallê Çînî ya Mezin şikand (Beş 2)

Hello!

Nikita dîsa bi we re ye, endezyarek pergalê ji pargîdaniyê SEMrush. Û bi vê gotarê re ez çîroka li ser ka çawa me çareseriyek çareser kir berdewam dikim Çînî Firewall ji bo xizmeta me semrush.com.

В beşa berê Min got:

• piştî ku biryar hat girtin çi pirsgirêk derdikevin "Em hewce ne ku karûbarê xwe li Chinaînê bixebitin"
• Çi pirsgirêkên Înterneta Çînî heye?
• çima ji te re lîsansek ICP hewce ye?
• çawa û çima me biryar da ku ceribandinên xwe bi Catchpoint re ceribandin
• encama çareseriya me ya yekem li ser bingeha Tora Cloudflare Chinaînê çi bû
• Me çawa di Cloudflare DNS de xeletiyek dît

Ev beş, bi dîtina min, ya herî balkêş e, ji ber ku ew li ser pêkanînên teknîkî yên taybetî yên sehneyê disekine. Û em ê bi dest pê bikin, an bêtir berdewam bikin Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud pêşkêşkerek ewr a pir mezin e, ku hemî karûbarên ku dihêle ku ew bi dilpakî xwe jê re pêşkêşkerek ewr bi nav bike. Baş e ku derfeta wan heye ku ji bo bikarhênerên biyanî qeyd bikin, û ku piraniya malperê bi Englishngilîzî tê wergerandin (ji bo Chinaînê ev luksek e). Di vê ewr de, hûn dikarin bi gelek herêmên cîhanê, axa Chinaînê, û hem jî Asyaya Okyanûsê (Hong Kong, Taywan, hwd.) re bixebitin.

IPsec

Me bi erdnîgariyê dest pê kir. Ji ber ku malpera me ya ceribandinê li ser Google Cloud-ê bû, hewce bû ku em Alibaba Cloud bi GCP-ê re "girêdin", ji ber vê yekê me navnîşek cîhên ku Google tê de heye vekir. Di wê gavê de wan hîna navenda daneya xwe ya li Hong Kongê nebû.
Herêma herî nêzîk derket holê asya-rojhilat1 (Taywan). Alî derkete holê ku herêma herî nêzîk a parzemîna Çînê ji Taywanê re ye cn-shenzhen (Shenzhen).

Bi alîkariya alîkariya terraform Tevahiya binesaziya li GCP û Alî diyar kir û bilind kir. Tunelek 100 Mbit/s di navbera ewran de hema di cih de hilkişiya. Li aliyê Shenzhen û Taywanê, makîneyên virtual proxying hatin rakirin. Li Shenzhen, seyrûsefera bikarhêner bi dawî dibe, bi tunelekek berbi Taywanê ve tê veguheztin, û ji wir ew rasterast diçe IP-ya derveyî ya karûbarê me li me-rojhilat (DYA ya Rojhilata Navîn). Ping di navbera makîneyên virtual bi rêya tunelê 24ms, ku ne ewqas xirab e.

Di heman demê de, me qada ceribandinê li hundur danîn Alibaba Cloud DNS. Piştî ku herêm ji NS Alî re hate şandin, dema çareseriyê ji 470 ms daket 50 ms. Beriya vê, navçe jî li ser Cloudlfare bû.

Paralel bi tunelê re asya-rojhilat1 Tunelek din ji Shenzhen rasterast rakir me-rojhilat4. Li wir wan bêtir makîneyên virtual proxy afirandin û dest bi ceribandina herdu çareseriyan kirin, rêvekirina seyrûsefera testê bi karanîna Cookies an DNS-ê. Pîvana testê bi rengek şematîkî di wêneya jêrîn de tête diyar kirin:

Derengiya tunelan wiha derket holê:
Ali cn-shenzhen <—> GCP asya-rojhilat1 - 24ms
Ali cn-shenzhen <—> GCP us-rojhilat4 - 200ms

Testên geroka Catchpoint pêşveçûnek hêja ragihandin.

Encamên testê ji bo du çareseriyê berhev bikin:

biryar
Uptime
Median
75 Ji sedî
95 Ji sedî

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Ev daneyên çareseriyek e ku tunelek IPSEC bikar tîne asya-rojhilat1. Di nav me-rojhilat4 de encam xirabtir bûn, û xeletî zêdetir bûn, ji ber vê yekê ez ê encaman nekim.

Li ser bingeha encamên vê ceribandina du tunelan, ku yek ji wan li herêma herî nêzîk a Chinaînê bi dawî dibe, û ya din jî li cîhê dawîn, eşkere bû ku girîng e ku bi lez û bez ji binê dîwarê dîwarê Chineseînî "derkevin". gengaz e, û dûv re torên bilez bikar bînin (pêşkêşkerên CDN, pêşkêşkerên ewr, hwd.). Ne hewce ye ku hûn hewl bidin ku ji dîwarê agir derbas bibin û bi yek gavê bigihîjin cihê xwe. Ev ne riya herî bilez e.

Bi gelemperî, encam ne xirab in, lêbelê, semrush.com navgînek 8.8s, û 75 Percentile 9.4s (li ser heman ceribandinê) heye.
Û berî ku ez biçim, ez dixwazim kurte vekêşanek lîrîk bikim.

Dirêjiya devkî

Piştî ku bikarhêner dikeve malperê www.semrushchina.cn, ku bi navgîniya pêşkêşkerên DNS yên Chineseînî "zû" çareser dibe, daxwaza HTTP di çareseriya meya bilez re derbas dibe. Bersiv bi heman rêyê ve tê vegerandin, lê domain di hemî nivîsarên JS, rûpelên HTML û hêmanên din ên rûpelê malperê de tête diyar kirin. semrush.com ji bo çavkaniyên din ên ku divê dema ku rûpel tê dakêşandin werin barkirin. Ango, xerîdar tomara A-ya "sereke" çareser dike www.semrushchina.cn û diçe nav tunela bilez, zû bersivek distîne - rûpelek HTML ku dibêje:

• ji sso.semrush.com js-ê wusa û wusa dakêşin,
• Pelên CSS-ê ji cdn.semrush.com bistînin,
• û ji dab.semrush.com jî çend wêneyan bikşînin
• û da ser.

Gerok dest pê dike ku ji bo van çavkaniyan biçe Înternetê "derveyî", her carê di nav dîwarek agir de derbas dibe ku dema bersivê dixwe.

Lê ceribandina berê dema ku çavkanî li ser rûpelê tune ne encaman nîşan dide semrush.com, tenê semrushchina.cn, û *.semrushchina.cn navnîşana makîneya virtual li Shenzhen çareser dike da ku paşê têkeve tunelê.

Tenê bi vî rengî, bi xistina hemî seyrûsefera gengaz a herî zêde di nav çareseriya xwe de ji bo zû derbaskirina dîwarê dîwarê Chineseînî, hûn dikarin leza pejirandî û nîşaneyên hebûna malperê, û her weha encamên rastîn ên ceribandinên çareseriyê bistînin.
Me ev yek bêyî guheztina kodek yekane li ser milê hilberê tîmê kir.

Subfilter

Çareserî hema yekser piştî ku ev pirsgirêk derket holê çêbû. Me hewce kir Poc (Delîla Têgînê) ku çareseriyên me yên pêketina firewall bi rastî baş dixebitin. Ji bo vê yekê, hûn hewce ne ku bi qasî ku gengaz be hemî seyrûsefera malperê di vê çareseriyê de bipêçin. Û me serlêdan kir subfilter li nginx.

Subfilter Di nginx de modulek pir hêsan e ku dihêle hûn rêzek di laşê bersivê de biguhezînin rêzek din. Ji ber vê yekê me hemû bûyer guhertin semrush.com li ser semrushchina.cn di hemî bersivan de.

Û... ew nexebitî ji ber ku me naveroka pêçandî ji paşperdeyan wergirt, ji ber vê yekê subfilter rêza pêwîst nedît. Diviya bû ku ez serverek herêmî ya din li nginx zêde bikim, ku bersivê dakêşand û ew ji servera herêmî ya din re derbas kir, ya ku jixwe mijûl bû bi cîhkirina rêzê, pêçandina wê, û şandina wê ji bo servera proxy ya din a di zincîrê de.

Wekî encamek, dê xerîdar li ku derê bistîne .semrush.com, wî wergirt .semrushchina.cn û bi guhdana biryara me meşiya.

Lêbelê, ne bes e ku meriv tenê bi yek awayê domainê biguhezîne, ji ber ku paşverû hîn jî di daxwazên paşîn ên xerîdar de li hêviya semrush.com in. Li gorî vê yekê, li ser heman serverê ku guheztina yek-alî tê kirin, bi karanîna birêkûpêkek birêkûpêk a hêsan em ji daxwazê ​​subdomain digirin, û dûv re em dikin. proxy_pass bi guherbar $host, tê pêşandan $subdomain.semrush.com. Dibe ku ew tevlihev xuya dike, lê ew dixebite. Û ew baş dixebite. Ji bo domên kesane yên ku mantiqa cûda hewce dikin, bi tenê blokên servera xwe biafirînin û veavakirinek cihêreng bikin. Li jêr ji bo zelalbûn û xwenîşandana vê nexşeyê mîhengên nginx têne kurt kirin.

Veavakirina jêrîn hemî daxwazên ji Chinaînê ji bo pêvajoyê dike .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;
    }
}

Ev mîheng bi proksî localhost li porta 83, û veavakirina jêrîn li wir li bendê ye:

    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;
    }
}

Ez dubare dikim, ev mîhengên jêkirî ne.

Wisa. Dibe ku tevlihev xuya bike, lê di peyvan de ye. Di rastiyê de, her tişt ji zincîreyên hilkirî hêsantir e :)

Dawiya dûrketinê

Demekê em kêfxweş bûn ji ber ku efsaneya li ser ketina tunelên IPSEC nehat pejirandin. Lê paşê tunelan dest pê kir. Rojê çend caran ji bo çend deqeyan. Hinekî, lê ev yek li me nedihat. Ji ber ku her du tunel li aliyê Alî li ser heman routerê bi dawî bûn, me biryar da ku belkî ev pirsgirêkek herêmî ye û pêdivî ye ku em herêma paşverû bilind bikin.

Wan ew hildan. Tunelan di demên cûda de dest bi têkçûnê kirin, lê têkçûn ji bo me di asta jorîn de di nginx de baş xebitî. Lê dûv re tunelan di heman demê de dest pê kir daketin 🙂 Û 502 û 504 dîsa dest pê kir. Demjimêr dest pê kir xirab bû, ji ber vê yekê me dest bi xebatê kir li ser vebijarkê bi Alibaba CEN (Cloud Enterprise Network).

CEN

CEN - ev pêwendiya du VPC-ên ji herêmên cûda yên di hundurê Alibaba Cloud de ye, ango hûn dikarin torên taybet ên her deverên di nav ewr de bi hevûdu ve girêdin. Û ya herî girîng: ev kanal xwedan rêgezek hişk e SLA. Ew hem di lez û hem jî di dema xebatê de pir bi îstîqrar e. Lê qet ne ewqas hêsan e:

• Pir dijwar e ku hûn hemwelatiyên Chineseînî an kesek qanûnî bin ku hûn nebin, bidestxistina wê pir dijwar e,
• Pêdivî ye ku hûn ji bo her megabit kapasîteya kanalê bidin.

Derfeta girêdanê heye Mainland Çîn и deryayî, me di navbera du herêmên Alî de CEN ava kir: cn-shenzhen и us-rojhilat-1 (Nêzîktirîn xala me-rojhilat4). Li Ali us-rojhilat-1 makîneyek din a virtual rakir da ku yekek din hebe hilperkîn.

Wisa derket holê:

Encamên testa gerokê li jêr in:

biryar
Uptime
Median
75 Ji sedî
95 Ji sedî

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Performansa ji IPSEC hinekî çêtir e. Lê bi navgîniya IPSEC-ê hûn dikarin bi leza 100 Mbit/s, û bi riya CEN-ê tenê bi leza 5 Mbit/s û zêdetir dakêşînin.

Dişibe hybrid, rast? Leza IPSEC û aramiya CEN tevlihev bikin.

Ya ku me kir ev e, di bûyera têkçûna tunela IPSEC-ê de rê da seyrûsefera hem bi IPSEC û hem jî bi CEN. Uptime pir zêde bûye, lê leza barkirina malperê hîn jî pir xwestek dihêle. Dûv re min hemî dorhêlên ku me berê bikar anibû û ceriband xêz kir, û biryar da ku ez hewl bidim ku hinekî din GCP li vê dorpêçê zêde bikim, ango devik.

devik

devik Ye Balansa Barkirina Gerdûnî (an Google Cloud Load Balancer). Ew ji bo me xwedan avantajek girîng e: Di çarçoweya CDN de ew heye anycast IP, ku dihêle hûn seyrûseferê berbi navenda daneyê ya herî nêzê xerîdar ve bişînin, da ku seyrûsefer zû bikeve nav tora bilez a Google-ê û kêmtir bi Înterneta "bi rêkûpêk" re derbas bibe.

Bêyî ku em du caran bifikirin, me bilind kir HTTP / HTTPS LB Me makîneyên xwe yên virtual bi subfilter di GCP-ê de û wekî paşverû saz kir.

Çend plan hebûn:

• Bikar bînin Cloudflare Tora Çînê, lê vê carê Origin divê gerdûnî diyar bike IP GLB.
• Xerîdarên dawî li cn-shenzhen, û ji wir rasterast trafîkê bi proxy devik.
• Ji Çînê rasterast biçin devik.
• Xerîdarên dawî li cn-shenzhen, ji wir proxy to asya-rojhilat1 bi rêya IPSEC (li me-rojhilat4 bi rêya CEN), ji wir biçin GLB (bi aramî, dê li jêr wêneyek û ravekek hebe)

Me van hemî vebijarkan û çend vebijarkên din ceriband:

• Cloudflare + GLB

Ev nexşe ji ber xeletiyên dem û DNS-ê li me neket. Lê ceribandin berî ku xeletî li aliyê CF-ê were rast kirin hate kirin, belkî ew niha çêtir be (lêbelê, ev demek HTTP-ê ji holê ranake).

• Ali + GLB

Di heman demê de ev nexşe di warê dema xebatê de jî ne li gorî me ye, ji ber ku GLB pir caran ji ber nebûna girêdanê di demek pejirandî de an jî wextê derbas dibe, ji ber ku ji bo serverek li hundurê Chinaînê, navnîşana GLB li derve dimîne, û ji ber vê yekê li paş Firewallê çînî. Sêrbaz çênebû.

• GLB tenê

Vebijêrkek mîna ya berê, tenê ew li Chinaînê bixwe server bikar neaniye: seyrûsefer rasterast çû GLB (qeydên DNS hatin guheztin). Li gorî vê yekê, encam ne têrker bûn, ji ber ku xerîdarên çînî yên asayî yên ku karûbarên pêşkêşkerên Internetnternetê yên asayî bikar tînin bi derbaskirina dîwarê agir ji Ali Cloud re rewşek pir xirabtir e.

• Shenzhen -> (CEN/IPSEC) -> Proxy -> GLB

Li vir me biryar da ku ji hemî çareseriyên çêtirîn bikar bînin:

• îstîqrar û garantî SLA ji CEN
• leza bilind ji IPSEC
• Tora "zû" ya Google û her kasta wê.

Pîlana tiştek bi vî rengî xuya dike: seyrûsefera bikarhêner li ser makîneyek virtual tê qediya ch-shenzhen. Nginx upstreams li wir têne mîheng kirin, hin ji wan destnîşan dikin serverên IP-ya taybet ên ku li dawiya tunela IPSEC-ê ne, û hin jor jî navnîşanên taybet ên serverên li aliyê din ê CEN-ê destnîşan dikin. IPSEC li herêmê hate mîheng kirin asya-rojhilat1 li GCP (dema ku çareserî ava bû, herêma herî nêzîk ji Çînê re bû. GCP niha li Hong Kongê jî heye). CEN - li herêmê me-rojhilat1 li Ali Cloud.

Dûre ji her du aliyan ve hatûçûn hate rêkirin anycast IP GLB, ango heta nuqteya herî nêzîk a hebûna Google, û bi torên xwe derbasî herêmê bû me-rojhilat4 di GCP-ê de, ku tê de makîneyên virtual li şûna (bi subfilter di nginx de) hebûn.

Vê çareseriya hybrid, wekî ku me hêvî dikir, sûd ji feydeyên her teknolojiyê girt. Bi gelemperî, seyrûsefer bi IPSEC-ê zû derbas dibe, lê heke pirsgirêk dest pê bikin, em bi lez û çend hûrdeman van serveran ji jorê derdixin û trafîkê tenê bi CEN-ê re dişînin heya ku tunel aram bibe.

Bi bicihanîna çareseriya 4-emîn a ji navnîşa li jor, me tiştê ku me dixwest û tiştê ku karsazî di wê demê de ji me dixwest pêk anî.

Encamên testa gerokê ji bo çareseriya nû li gorî yên berê:

biryar
Uptime
Median
75 Ji sedî
95 Ji sedî

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

Di çareseriya ku me sepandiye de her tişt baş e, lê CDN tune ku bikaribe trafîkê di asta herêmî û tewra bajarî de bilez bike. Di teorîyê de, ev pêdivî ye ku bi karanîna kanalên pêwendiya bilez ên pêşkêşkarê CDN-ê malperê ji bo bikarhênerên dawîn zûtir bike. Û em her dem li ser wê difikirin. Û naha, dem ji bo dubarekirina din a projeyê hatiye: lêgerîn û ceribandina pêşkêşkerên CDN li Chinaînê.

Û ez ê di beşa paşîn, ya paşîn de li ser vê yekê ji we re bibêjim :)

Source: www.habr.com