ProHoster > Blog > administratë > Si e depërtuam Firewallin e Madh të Kinës (Pjesa 2)

Si e depërtuam Firewallin e Madh të Kinës (Pjesa 2)

Привет!

Nikita është përsëri me ju, një inxhinier sistemi nga kompania SEMrush. Dhe me këtë artikull unë vazhdoj tregimin se si dolëm me një zgjidhje Firewall kinez për shërbimin tonë semrush.com.

В pjesa e mëparshme Thashe:

  • çfarë problemesh lindin pas marrjes së vendimit "Ne duhet ta bëjmë shërbimin tonë të funksionojë në Kinë"
  • Çfarë problemesh ka interneti kinez?
  • pse ju duhet një licencë ICP?
  • si dhe pse vendosëm të testonim shtretërit tanë të provës me Catchpoint
  • cili ishte rezultati i zgjidhjes sonë të parë bazuar në Cloudflare China Network
  • Si gjetëm një gabim në Cloudflare DNS

Kjo pjesë është më interesante, për mendimin tim, sepse fokusohet në zbatime specifike teknike të vënies në skenë. Dhe ne do të fillojmë, ose më mirë do të vazhdojmë, me Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud është një ofrues mjaft i madh cloud, i cili ka të gjitha shërbimet që i lejojnë të quajë sinqerisht veten një ofrues cloud. Është mirë që ata kanë mundësinë të regjistrohen për përdoruesit e huaj dhe që pjesa më e madhe e faqes është e përkthyer në anglisht (për Kinën ky është një luks). Në këtë re, ju mund të punoni me shumë rajone të botës, Kinën kontinentale, si dhe Azinë Oqeanike (Hong Kong, Tajvan, etj.).

IPSEC

Filluam me gjeografinë. Meqenëse faqja jonë e testimit ndodhej në Google Cloud, na duhej të "lidhnim" Alibaba Cloud me GCP, kështu që hapëm një listë të vendndodhjeve në të cilat Google është i pranishëm. Në atë moment ata nuk kishin ende qendrën e tyre të të dhënave në Hong Kong.
Rajoni më i afërt doli të ishte azia-lindje1 (Tajvan). Ali doli të ishte rajoni më i afërt i Kinës kontinentale me Tajvanin cn-shenzhen (Shenzhen).

Me terraform përshkroi dhe ngriti të gjithë infrastrukturën në GCP dhe Ali. Një tunel 100 Mbit/s midis reve u ngrit pothuajse menjëherë. Në anën e Shenzhenit dhe Tajvanit, u ngritën makinat virtuale proxying. Në Shenzhen, trafiku i përdoruesve përfundon, kalon përmes një tuneli në Tajvan dhe prej andej shkon drejtpërdrejt në IP-në e jashtme të shërbimit tonë në ne-lindje (Bregu Lindor i SHBA). Ping midis makinave virtuale nëpërmjet tunelit 24ms, e cila nuk është aq e keqe.

Në të njëjtën kohë, ne vendosëm një zonë testimi Alibaba Cloud DNS. Pas delegimit të zonës te NS Ali, koha e zgjidhjes u ul nga 470 ms në 50 ms. Para kësaj, zona ishte gjithashtu në Cloudlfare.

Paralelisht me tunelin për të azia-lindje1 ngriti një tunel tjetër nga Shenzhen direkt në ne-lindje4. Atje ata krijuan më shumë makina virtuale proxy dhe filluan të testojnë të dyja zgjidhjet, duke kursyer trafikun e testimit duke përdorur Cookies ose DNS. Stoli i provës është përshkruar në mënyrë skematike në figurën e mëposhtme:

Vonesa për tunelet doli të ishte si më poshtë:
Ali cn-shenzhen <—> GCP azia-lindje1 — 24 ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

Testet e shfletuesit Catchpoint raportuan përmirësim të shkëlqyer.

Krahasoni rezultatet e testit për dy zgjidhje:

vendim
Uptime
mesatare
75 Përqindja
95 Përqindja

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Këto janë të dhëna nga një zgjidhje që përdor një tunel IPSEC nëpërmjet azia-lindje1. Përmes ne-lindje4 rezultatet ishin më të këqija dhe kishte më shumë gabime, kështu që nuk do t'i jap rezultatet.

Bazuar në rezultatet e këtij testi të dy tuneleve, njëri prej të cilëve përfundon në rajonin më të afërt me Kinën dhe tjetri në destinacionin përfundimtar, u bë e qartë se është e rëndësishme të "dalesh" nga poshtë murit të zjarrit kinez sa më shpejt që është e mundur, dhe më pas përdorni rrjete të shpejta (ofruesit CDN, ofruesit e reve kompjuterike, etj.). Nuk ka nevojë të përpiqeni të kaloni nëpër murin e zjarrit dhe të arrini në destinacionin tuaj me një goditje. Kjo nuk është mënyra më e shpejtë.

Në përgjithësi, rezultatet nuk janë të këqija, megjithatë, semrush.com ka një mesatare prej 8.8 s dhe 75 përqindje 9.4 (në të njëjtin test).
Dhe para se të vazhdoj më tej, do të doja të bëja një digresion të shkurtër lirik.

Digresion lirik

Pasi përdoruesi të hyjë në faqe www.semrushchina.cn, e cila zgjidhet përmes serverëve "të shpejtë" kinezë DNS, kërkesa HTTP kalon përmes zgjidhjes sonë të shpejtë. Përgjigja kthehet në të njëjtën rrugë, por domeni specifikohet në të gjitha skriptet JS, faqet HTML dhe elementët e tjerë të faqes së internetit semrush.com për burime shtesë që duhet të ngarkohen kur faqja jepet. Kjo do të thotë, klienti zgjidh rekordin "kryesor" A www.semrushchina.cn dhe shkon në tunelin e shpejtë, merr shpejt një përgjigje - një faqe HTML që thotë:

  • shkarkoni këtë dhe atë js nga sso.semrush.com,
  • Merrni skedarët CSS nga cdn.semrush.com,
  • dhe gjithashtu bëni disa fotografi nga dab.semrush.com
  • dhe kështu me radhë.

Shfletuesi fillon të shkojë në internetin "të jashtëm" për këto burime, çdo herë duke kaluar nëpër një mur zjarri që ha kohën e përgjigjes.

Por testi i mëparshëm tregon rezultatet kur nuk ka burime në faqe semrush.comvetëm semrushchina.cn, dhe *.semrushchina.cn zgjidh në adresën e makinës virtuale në Shenzhen për të hyrë më pas në tunel.

Vetëm në këtë mënyrë, duke e çuar në maksimum të gjithë trafikun e mundshëm përmes zgjidhjes suaj për kalimin e shpejtë të murit të zjarrit kinez, mund të merrni shpejtësi të pranueshme dhe tregues të disponueshmërisë së faqes në internet, si dhe rezultate të sinqerta të testeve të zgjidhjeve.
Ne e bëmë këtë pa një modifikim të vetëm të kodit në anën e produktit të ekipit.

Nënfiltri

Zgjidhja lindi pothuajse menjëherë pasi u shfaq ky problem. Ne kishim nevojë POC (Proof of Concept) që zgjidhjet tona të depërtimit të murit të zjarrit funksionojnë vërtet mirë. Për ta bërë këtë, duhet të mbështillni të gjithë trafikun e faqes në këtë zgjidhje sa më shumë që të jetë e mundur. Dhe ne aplikuam nënfiltri në nginx.

Nënfiltri është një modul mjaft i thjeshtë në nginx që ju lejon të ndryshoni një linjë në trupin e përgjigjes në një linjë tjetër. Kështu që ne i ndryshuam të gjitha dukuritë semrush.com mbi semrushchina.cn në të gjitha përgjigjet.

Dhe... nuk funksionoi sepse morëm përmbajtje të ngjeshur nga prapavija, kështu që nënfiltri nuk gjeti linjën e kërkuar. Më duhej të shtoja një server tjetër lokal në nginx, i cili dekompresoi përgjigjen dhe ia kaloi serverit tjetër lokal, i cili tashmë ishte i zënë duke zëvendësuar vargun, duke e ngjeshur dhe duke e dërguar te serveri tjetër proxy në zinxhir.

Si rezultat, ku do të merrte klienti .semrush.com, mori ai .semrushchina.cn dhe me bindje ndoqi vendimin tonë.

Megjithatë, nuk mjafton thjesht të ndryshosh domenin në një mënyrë, sepse backend-et ende presin semrush.com në kërkesat e mëvonshme nga klienti. Prandaj, në të njëjtin server ku bëhet zëvendësimi i njëanshëm, duke përdorur një shprehje të thjeshtë të rregullt marrim nëndomain nga kërkesa dhe më pas bëjmë proxy_pass me ndryshore $ host, ekspozuar në $subdomain.semrush.com. Mund të duket konfuze, por funksionon. Dhe funksionon mirë. Për domenet individuale që kërkojnë logjikë të ndryshme, thjesht krijoni blloqet tuaja të serverit dhe bëni një konfigurim të veçantë. Më poshtë janë konfigurimet e shkurtuara të nginx për qartësi dhe demonstrim të kësaj skeme.

Konfigurimi i mëposhtëm përpunon të gjitha kërkesat nga Kina në .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;
    }
}

Ky konfigurim i referohet localhost në portin 83, dhe konfigurimi i mëposhtëm është duke pritur atje:

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

E përsëris, këto janë konfigurime të prera.

Ashtu si kjo. Mund të duket e ndërlikuar, por është me fjalë. Në fakt, gjithçka është më e thjeshtë se rrepat e zier me avull :)

Fundi i digresionit

Për një kohë ishim të lumtur sepse miti për rënien e tuneleve IPSEC nuk u konfirmua. Por më pas tunelet filluan të binin. Disa herë në ditë për disa minuta. Pak, por kjo nuk na shkonte. Meqenëse të dy tunelet u mbyllën në anën Ali në të njëjtin ruter, vendosëm që ndoshta ky ishte një problem rajonal dhe ne duhej të ngrinim rajonin rezervë.

Ata e morën atë. Tunelet filluan të dështojnë në periudha të ndryshme, por dështimi funksionoi mirë për ne në nivelin e rrjedhës së sipërme në nginx. Por më pas tunelet filluan të binin pothuajse në të njëjtën kohë 🙂 Dhe 502 dhe 504 filluan përsëri. Koha e funksionimit filloi të përkeqësohej, kështu që filluam të punonim në opsionin me Alibaba CEN (Cloud Enterprise Network).

CE

CE - kjo është lidhja e dy VPC-ve nga rajone të ndryshme brenda Alibaba Cloud, domethënë, ju mund të lidhni rrjetet private të çdo rajoni brenda cloud me njëri-tjetrin. Dhe më e rëndësishmja: ky kanal ka një mjaft të rreptë SLA. Është shumë i qëndrueshëm si në shpejtësi ashtu edhe në kohë pune. Por nuk është kurrë kaq e thjeshtë:

  • është shumë e vështirë për t'u marrë nëse nuk jeni shtetas kinezë ose person juridik,
  • Ju duhet të paguani për çdo megabit të kapacitetit të kanalit.

Duke pasur mundësinë për t'u lidhur Kina kontinentale и Overseas, ne krijuam një CEN midis dy rajoneve Ali: cn-shenzhen и ne-lindje-1 (pika më e afërt me ne-lindje4). Në Ali ne-lindje-1 ngriti një makinë tjetër virtuale në mënyrë që të ketë një më shumë hop.

Doli kështu:

Rezultatet e testit të shfletuesit janë më poshtë:

vendim
Uptime
mesatare
75 Përqindja
95 Përqindja

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CE
99.75
16s
21s
27s

Performanca është pak më e mirë se IPSEC. Por përmes IPSEC mund të shkarkoni potencialisht me një shpejtësi prej 100 Mbit/s, dhe përmes CEN vetëm me një shpejtësi prej 5 Mbit/s dhe më shumë.

Tingëllon si një hibrid, apo jo? Kombinoni shpejtësinë IPSEC dhe stabilitetin CEN.

Kjo është ajo që ne bëmë, duke lejuar trafikun përmes IPSEC dhe CEN në rast të dështimit të tunelit IPSEC. Koha e funksionimit është bërë shumë më e lartë, por shpejtësia e ngarkimit të faqes lë ende shumë për të dëshiruar. Pastaj vizatova të gjitha qarqet që kishim përdorur dhe testuar tashmë, dhe vendosa të përpiqem të shtoj pak më shumë GCP në këtë qark, domethënë GLB.

GLB

GLB - A Balancues i ngarkesës globale (ose Google Cloud Load Balancer). Ajo ka një avantazh të rëndësishëm për ne: në kontekstin e një CDN-je ka anycast IP, i cili ju lejon të drejtoni trafikun në qendrën e të dhënave më afër klientit, në mënyrë që trafiku të futet shpejt në rrjetin e shpejtë të Google dhe më pak të kalojë përmes internetit "të rregullt".

Pa u menduar dy herë, u ngritëm HTTP/HTTPS LB Ne instaluam makinat tona virtuale me nënfiltër në GCP dhe si një backend.

Kishte disa skema:

  • për t'u përdorur Rrjeti i Kinës Cloudflare, por këtë herë Origjina duhet të specifikojë globale IP GLB.
  • Përfundoni klientët në cn-shenzhen, dhe nga atje proxy trafikun direkt në GLB.
  • Shkoni direkt nga Kina në GLB.
  • Përfundoni klientët në cn-shenzhen, prej andej prokure te azia-lindje1 nëpërmjet IPSEC (në ne-lindje4 nëpërmjet CEN), nga atje shkoni në GLB (me qetësi, do të ketë një foto dhe shpjegim më poshtë)

Ne testuam të gjitha këto opsione dhe disa të tjera hibride:

  • Cloudflare + GLB

Kjo skemë nuk na përshtatet për shkak të gabimeve në kohën e duhur dhe DNS. Por testi u krye përpara se defekti të rregullohej në anën CF, ndoshta është më mirë tani (megjithatë, kjo nuk përjashton afatet e HTTP).

  • Ali + GLB

Kjo skemë gjithashtu nuk na përshtatet për sa i përket kohës së funksionimit, pasi GLB shpesh binte nga rrjedha e sipërme për shkak të pamundësisë së lidhjes në një kohë të pranueshme ose afat kohor, sepse për një server brenda Kinës, adresa GLB mbetet jashtë, dhe për këtë arsye prapa Firewall kinez. Magjia nuk ndodhi.

  • Vetëm GLB

Një opsion i ngjashëm me atë të mëparshëm, vetëm ai nuk përdorte serverë në vetë Kinën: trafiku shkoi drejtpërdrejt në GLB (të dhënat DNS u ndryshuan). Prandaj, rezultatet nuk ishin të kënaqshme, pasi klientët e zakonshëm kinezë që përdorin shërbimet e ofruesve të zakonshëm të internetit kanë një situatë shumë më të keqe me kalimin e murit të zjarrit sesa Ali Cloud.

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

Këtu vendosëm të përdorim zgjidhjet më të mira nga të gjitha:

  • stabilitet dhe SLA e garantuar nga CEN
  • shpejtësi të lartë nga IPSEC
  • Rrjeti "i shpejtë" i Google dhe anycast i tij.

Skema duket diçka si kjo: trafiku i përdoruesit përfundon në një makinë virtuale në ch-shenzhen. Nginx upstreams janë konfiguruar atje, disa prej të cilave drejtojnë serverët IP privatë të vendosur në skajin tjetër të tunelit IPSEC dhe disa në rrjedhat e sipërme tregojnë adresat private të serverëve në anën tjetër të CEN. IPSEC është konfiguruar në rajon azia-lindje1 në GCP (ishte rajoni më i afërt me Kinën në kohën kur u krijua zgjidhja. GCP tani ka një prani edhe në Hong Kong). CEN - në rajon ne-lindje1 në Ali Cloud.

Më pas trafiku nga të dy skajet drejtohej në anycast IP GLB, domethënë në pikën më të afërt të pranisë së Google, dhe kaloi përmes rrjeteve të tij në rajon ne-lindje4 në GCP, në të cilën kishte makina virtuale zëvendësuese (me nënfiltër në nginx).

Kjo zgjidhje hibride, siç e prisnim, përfitoi nga përfitimet e secilës teknologji. Në përgjithësi, trafiku kalon përmes IPSEC të shpejtë, por nëse fillojnë problemet, ne shpejt dhe për disa minuta i nxjerrim këta serverë nga rrjedha e sipërme dhe dërgojmë trafikun vetëm përmes CEN derisa tuneli të stabilizohet.

Duke zbatuar zgjidhjen e katërt nga lista e mësipërme, ne arritëm atë që donim dhe atë që biznesi kërkonte nga ne në atë moment.

Rezultatet e testit të shfletuesit për zgjidhjen e re në krahasim me ato të mëparshme:

vendim
Uptime
mesatare
75 Përqindja
95 Përqindja

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CE
99.75
16s
21s
27s

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

CDN

Gjithçka është e mirë në zgjidhjen që kemi zbatuar, por nuk ka CDN që mund të përshpejtojë trafikun në nivel rajonal dhe madje edhe të qytetit. Në teori, kjo duhet të shpejtojë faqen për përdoruesit fundorë duke përdorur kanalet e komunikimit të shpejtë të ofruesit CDN. Dhe ne menduam për të gjatë gjithë kohës. Dhe tani, ka ardhur koha për përsëritjen tjetër të projektit: kërkimi dhe testimi i ofruesve të CDN në Kinë.

Dhe unë do t'ju tregoj për këtë në pjesën tjetër, përfundimtare :)

Burimi: www.habr.com

Shto një koment