Kako smo prebili veliki kitajski požarni zid (2. del)

Lep pozdrav!

Z vami je spet Nikita, sistemski inženir iz podjetja SEMrush. In s tem člankom nadaljujem zgodbo o tem, kako smo prišli do rešitve kitajski požarni zid za našo storitev semrush.com.

В prejšnji del Rekel sem:

• kakšne težave se pojavijo po sprejeti odločitvi »Naše storitve morajo delovati na Kitajskem«
• Kakšne težave ima kitajski internet?
• zakaj potrebujete licenco ICP?
• kako in zakaj smo se odločili preizkusiti naše testne naprave s Catchpointom
• kaj je bil rezultat naše prve rešitve, ki temelji na Cloudflare China Network
• Kako smo našli napako v Cloudflare DNS

Ta del je po mojem mnenju najbolj zanimiv, ker se osredotoča na specifične tehnične izvedbe uprizarjanja. In začeli bomo, bolje rečeno nadaljevali Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud je dokaj velik ponudnik oblakov, ki ima vse storitve, ki mu omogočajo, da se pošteno imenuje ponudnik oblakov. Dobro je, da imajo možnost registracije za tuje uporabnike in da je večina strani prevedena v angleščino (za Kitajsko je to luksuz). V tem oblaku lahko delate s številnimi regijami sveta, celinsko Kitajsko, pa tudi z oceansko Azijo (Hong Kong, Tajvan itd.).

IPSEC

Začeli smo z geografijo. Ker je bilo naše testno mesto v Google Cloudu, smo morali »povezati« Alibaba Cloud z GCP, zato smo odprli seznam lokacij, kjer je Google prisoten. Takrat v Hongkongu še niso imeli lastnega podatkovnega centra.
Izkazalo se je, da je najbližja regija azija-vzhod1 (Tajvan). Izkazalo se je, da je Ali Tajvanu najbližja regija celinske Kitajske cn-Shenzhen (Shenzhen).

Z terraform opisal in dvignil celotno infrastrukturo v GCP in Ali. 100 Mbit/s tunel med oblaki se je dvignil skoraj v trenutku. Na strani Shenzhena in Tajvana so bili postavljeni proxy virtualni stroji. V Shenzhenu se uporabniški promet prekine, posreduje prek tunela do Tajvana, od tam pa gre neposredno na zunanji IP naše storitve v nas-vzhod (Vzhodna obala ZDA). Ping med virtualnimi stroji prek tunela 24ms, kar niti ni tako slabo.

Hkrati smo v prostor postavili testno območje Alibaba Cloud DNS. Po prenosu cone na NS Ali se je čas ločljivosti zmanjšal s 470 ms na 50 ms. Pred tem je bila cona tudi na Cloudlfare.

Vzporedno s tunelom do azija-vzhod1 dvignili še en predor iz Shenzhena neposredno v us-vzhod4. Tam so ustvarili več proxy virtualnih strojev in začeli preizkušati obe rešitvi, pri čemer so testni promet usmerjali s piškotki ali DNS. Preskusna naprava je shematično opisana na naslednji sliki:

Izkazalo se je, da je zakasnitev za tunele naslednja:
Ali cn-shenzhen <—> GCP asia-east1 — 24ms
Ali cn-shenzhen <—> GCP us-east4 — 200 ms

Preizkusi brskalnika Catchpoint so poročali o odličnem napredku.

Primerjajte rezultate preskusov za dve rešitvi:

odločitev
Uptime
Mediana
75 percentil
95 percentil

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

To so podatki iz rešitve, ki uporablja tunel IPSEC prek azija-vzhod1. Prek us-east4 so bili rezultati slabši, napak pa je bilo več, zato rezultatov ne bom navajal.

Na podlagi rezultatov tega testa dveh predorov, od katerih se eden konča v Kitajski najbližji regiji, drugi pa na končni destinaciji, je postalo jasno, da je pomembno čim prej "izstopiti" izpod kitajskega požarnega zidu. mogoče, nato pa uporabite hitra omrežja (ponudniki CDN, ponudniki v oblaku itd.). Ni vam treba poskušati priti skozi požarni zid in z enim zamahom priti na cilj. To ni najhitrejši način.

Na splošno rezultati niso slabi, vendar ima semrush.com mediano 8.8s in 75 Percentile 9.4s (na istem testu).
In preden grem naprej, bi rad naredil kratko lirično digresijo.

Lirična digresija

Ko uporabnik vstopi na spletno stran www.semrushchina.cn, ki se rešuje prek "hitrih" kitajskih strežnikov DNS, gre zahteva HTTP prek naše hitre rešitve. Odgovor se vrne po isti poti, vendar je domena podana v vseh skriptih JS, straneh HTML in drugih elementih spletne strani semrush.com za dodatne vire, ki jih je treba naložiti, ko je stran upodobljena. To pomeni, da stranka razreši "glavni" A-zapis www.semrushchina.cn in gre v hitri tunel, hitro prejme odgovor - stran HTML, ki navaja:

• prenesite tak in tak js s sso.semrush.com,
• Pridobite datoteke CSS s cdn.semrush.com,
• in posnemite tudi nekaj slik iz dab.semrush.com
• in tako naprej.

Brskalnik začne iti na "zunanji" internet za te vire, vsakič, ko gre skozi požarni zid, ki poje odzivni čas.

Toda prejšnji test prikazuje rezultate, ko na strani ni virov semrush.comsamo semrushchina.cn, in *.semrushchina.cn se razreši na naslov virtualnega stroja v Shenzhenu, da bi nato vstopil v tunel.

Samo na ta način, s čim večjim prometom skozi vašo rešitev za hitro prečkanje kitajskega požarnega zidu, lahko pridobite sprejemljive hitrosti in kazalnike dostopnosti spletnega mesta ter poštene rezultate testov rešitev.
To smo storili brez enega samega urejanja kode na strani izdelka ekipe.

Podfilter

Rešitev se je rodila skoraj takoj po pojavu te težave. Potrebovali smo PoC (Dokaz koncepta), da naše rešitve za prodor skozi požarni zid res dobro delujejo. Če želite to narediti, morate ves promet spletnega mesta čim bolj zaviti v to rešitev. In smo se prijavili podfilter v nginxu.

Podfilter je dokaj preprost modul v nginxu, ki vam omogoča, da spremenite eno vrstico v telesu odgovora v drugo vrstico. Tako smo spremenili vse pojavitve semrush.com o semrushchina.cn v vseh odgovorih.

In ... ni delovalo, ker smo prejeli stisnjeno vsebino iz ozadja, zato podfilter ni našel zahtevane vrstice. V nginx sem moral dodati še en lokalni strežnik, ki je razpakral odgovor in ga posredoval naslednjemu lokalnemu strežniku, ki je bil že zaposlen z zamenjavo niza, njegovim stiskanjem in pošiljanjem na naslednji proxy strežnik v verigi.

Posledično, kje bi stranka prejela .semrush.com, prejel je .semrushchina.cn in ubogljivo sledil naši odločitvi.

Vendar pa ni dovolj, da enosmerno spremenite domeno, saj zaledja še vedno pričakujejo semrush.com pri nadaljnjih zahtevah odjemalca. V skladu s tem na istem strežniku, kjer se izvede enosmerna zamenjava, z uporabo preprostega regularnega izraza pridobimo poddomeno iz zahteve, nato pa naredimo proxy_pass s spremenljivo $ host, razstavljen v $poddomena.semrush.com. Morda se zdi zmedeno, vendar deluje. In dobro deluje. Za posamezne domene, ki zahtevajo drugačno logiko, preprosto ustvarite lastne strežniške bloke in naredite ločeno konfiguracijo. Spodaj so skrajšane konfiguracije nginx za jasnost in predstavitev te sheme.

Naslednja konfiguracija obdela vse zahteve od Kitajske do .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;
    }
}

Ta konfiguracija posreduje localhost na vrata 83 in tam čaka naslednja konfiguracija:

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

Ponavljam, to so obrezane konfiguracije.

Kot to. Morda je videti zapleteno, vendar je v besedah. Pravzaprav je vse preprostejše od parjene repe :)

Konec digresije

Nekaj ​​časa smo bili veseli, ker mit o padajočih predorih IPSEC ni bil potrjen. Potem pa so predori začeli padati. Večkrat na dan po nekaj minut. Malo, a to nam ni ustrezalo. Ker sta bila oba tunela zaključena na strani Ali na istem usmerjevalniku, smo se odločili, da je to morda regionalni problem in da moramo povečati rezervno regijo.

Pobrali so ga. Tuneli so začeli odpovedovati ob različnih časih, vendar je preklop v primeru napake dobro deloval na zgornji ravni v nginxu. Toda potem so tuneli približno ob istem času začeli padati 🙂 In spet sta se začela 502 in 504. Čas delovanja se je začel slabšati, zato smo začeli delati na možnosti z Alibaba CEN (Podjetniško omrežje v oblaku).

CEN

CEN - to je povezljivost dveh VPC-jev iz različnih regij znotraj Alibaba Clouda, to pomeni, da lahko med seboj povežete zasebna omrežja poljubnih regij znotraj oblaka. In kar je najpomembnejše: ta kanal ima dokaj strog SLA. Je zelo stabilen tako glede hitrosti kot delovanja. Vendar nikoli ni tako preprosto:

• ZELO težko ga je pridobiti, če niste kitajski državljan ali pravna oseba,
• Plačati morate za vsak megabit pasovne širine kanala.

Imeti možnost povezovanja Celinsko Kitajsko и Overseassmo ustvarili CEN med dvema regijama Ali: cn-Shenzhen и us-vzhod-1 (najbližja točka nam-vzhod4). V Aliju us-vzhod-1 dvignil še en virtualni stroj, tako da obstaja še en hop.

Izkazalo se je takole:

Rezultati testa brskalnika so spodaj:

odločitev
Uptime
Mediana
75 percentil
95 percentil

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Zmogljivost je nekoliko boljša od IPSEC. Toda prek IPSEC lahko potencialno prenašate s hitrostjo 100 Mbit/s, prek CEN pa le s hitrostjo 5 Mbit/s in več.

Sliši se kot hibrid, kajne? Združite hitrost IPSEC in stabilnost CEN.

To smo storili in omogočili promet prek IPSEC in CEN v primeru okvare tunela IPSEC. Čas delovanja je postal veliko višji, vendar hitrost nalaganja spletnega mesta še vedno pušča veliko želenega. Nato sem narisal vsa vezja, ki smo jih že uporabljali in preizkusili, in se odločil, da temu vezju poskusim dodati malo več GCP, in sicer pokrovček.

pokrovček

pokrovček - Je Global Load Balancer (ali Google Cloud Load Balancer). Za nas ima pomembno prednost: v kontekstu CDN ima anycast IP, ki vam omogoča, da promet usmerite v podatkovni center, ki je najbližji odjemalcu, tako da promet hitro pride v Googlovo hitro omrežje in manj skozi »običajni« internet.

Brez dvakratnega razmišljanja smo dvignili HTTP/HTTPS LB Naše virtualne stroje s podfiltrom smo namestili v GCP in kot zaledje.

Shem je bilo več:

• Za uporabo Kitajsko omrežje Cloudflare, toda tokrat mora Origin določiti globalno IP GLB.
• Prekinite stranke pri cn-Shenzhen, od tam pa proxy promet neposredno na pokrovček.
• Pojdite naravnost iz Kitajske v pokrovček.
• Prekinite stranke pri cn-Shenzhen, od tam proxy do azija-vzhod1 prek IPSEC (in us-vzhod4 prek CEN-a), od tam pojdite na GLB (mirno, spodaj bo slika in razlaga)

Preizkusili smo vse te možnosti in več hibridnih:

• Cloudflare + GLB

Ta shema nam ni ustrezala zaradi uptime in DNS napak. Toda preizkus je bil izveden, preden je bila napaka odpravljena na strani CF, morda je zdaj bolje (vendar to ne izključuje časovnih omejitev HTTP).

• Ali + GLB

Tudi ta shema nam ni ustrezala glede časa delovanja, saj je GLB pogosto izpadel iz upstreama zaradi nezmožnosti povezave v sprejemljivem času ali časovni omejitvi, saj za strežnik znotraj Kitajske naslov GLB ostane zunaj in torej za Kitajski požarni zid. Čarovnija se ni zgodila.

• Samo GLB

Možnost, podobna prejšnji, le da ni uporabljala strežnikov na samem Kitajskem: promet je šel neposredno na GLB (zapisi DNS so bili spremenjeni). Skladno s tem rezultati niso bili zadovoljivi, saj imajo običajni kitajski odjemalci, ki uporabljajo storitve običajnih internetnih ponudnikov, veliko slabši položaj pri prehodu požarnega zidu kot Ali Cloud.

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

Tu smo se odločili uporabiti najboljšo od vseh rešitev:

• stabilnost in zagotovljen SLA s strani CEN
• visoka hitrost iz IPSEC
• Googlovo "hitro" omrežje in njegov anycast.

Shema je videti nekako takole: uporabniški promet se zaključi na virtualnem stroju v ch-Shenzhen. Tam so konfigurirani navzgornji tokovi Nginx, od katerih nekateri kažejo na zasebne strežnike IP, ki se nahajajo na drugem koncu tunela IPSEC, nekateri navzgor pa na zasebne naslove strežnikov na drugi strani CEN. IPSEC konfiguriran za regijo azija-vzhod1 v GCP (v času, ko je bila rešitev ustvarjena, je bila Kitajski najbližja regija. GCP je zdaj prisoten tudi v Hong Kongu). CEN - v regijo us-vzhod1 v Aliju Oblaku.

Nato z obeh koncev usmerili promet v anycast IP GLB, to je do najbližje točke prisotnosti Googla, in šel prek njegovih omrežij v regijo us-vzhod4 v GCP, v katerem so bili nadomestni virtualni stroji (s podfiltrom v nginxu).

Ta hibridna rešitev je, kot smo pričakovali, izkoristila prednosti posamezne tehnologije. Na splošno gre promet prek hitrega IPSEC-a, a če se začnejo težave, te strežnike hitro in za nekaj minut izločimo iz zgornjega toka in pošiljamo promet samo prek CEN-a, dokler se tunel ne stabilizira.

Z uvedbo 4. rešitve iz zgornjega seznama smo dosegli tisto, kar smo želeli in kar je posel od nas v tistem trenutku zahteval.

Rezultati testa brskalnika za novo rešitev v primerjavi s prejšnjimi:

odločitev
Uptime
Mediana
75 percentil
95 percentil

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

V rešitvi, ki smo jo implementirali, je vse dobro, ni pa CDN, ki bi lahko pospešil promet na regionalni in celo mestni ravni. Teoretično naj bi to pohitrilo stran za končne uporabnike z uporabo hitrih komunikacijskih kanalov ponudnika CDN. In ves čas sva razmišljala o tem. In zdaj je prišel čas za naslednjo ponovitev projekta: iskanje in testiranje ponudnikov CDN na Kitajskem.

In o tem vam bom povedal v naslednjem, zadnjem delu :)

Vir: www.habr.com