Ako sme prelomili Veľký čínsky firewall (2. časť)

Ahoj!

Nikita je opäť s vami, systémový inžinier zo spoločnosti SEMrush. A týmto článkom pokračujem v príbehu o tom, ako sme prišli s riešením na obídenie Čínsky firewall pre našu službu semrush.com.

В predchádzajúca časť Povedal som:

• aké problémy vznikajú po prijatí rozhodnutia „Musíme zabezpečiť, aby naša služba fungovala v Číne“
• Aké problémy má čínsky internet?
• prečo potrebujete licenciu ICP?
• ako a prečo sme sa rozhodli otestovať naše testovacie zariadenia pomocou Catchpoint
• čo bolo výsledkom nášho prvého riešenia založeného na Cloudflare China Network
• Ako sme našli chybu v Cloudflare DNS

Táto časť je podľa mňa najzaujímavejšia, pretože sa zameriava na konkrétne technické realizácie inscenácií. A začneme, alebo skôr budeme pokračovať Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud je pomerne veľký cloudový poskytovateľ, ktorý má všetky služby, vďaka ktorým sa môže úprimne nazývať cloudovým poskytovateľom. Je dobré, že majú možnosť zaregistrovať sa pre zahraničných používateľov a že väčšina stránok je preložená do angličtiny (pre Čínu je to luxus). V tomto cloude môžete pracovať s mnohými regiónmi sveta, pevninskou Čínou, ako aj oceánskou Áziou (Hongkong, Taiwan atď.).

IPsec

Začali sme zemepisom. Keďže naša testovacia stránka bola umiestnená na Google Cloud, potrebovali sme „prepojiť“ Alibaba Cloud s GCP, a tak sme otvorili zoznam lokalít, v ktorých je Google prítomný. V tom momente ešte nemali v Hong Kongu vlastné dátové centrum.
Najbližší región sa ukázal byť východná Ázia1 (Taiwan). Ali sa ukázalo byť najbližším regiónom pevninskej Číny k Taiwanu cn-shenzhen (Shenzhen).

S terraform opísal a zvýšil celú infraštruktúru v GCP a Ali. Tunel medzi oblakmi s rýchlosťou 100 Mbit/s sa zdvihol takmer okamžite. Na strane Shenzhenu a Taiwanu vznikli virtuálne stroje proxy. V Shenzhene je užívateľská prevádzka ukončená, proxy cez tunel na Taiwan a odtiaľ ide priamo na externú IP našej služby v nás-východ (východné pobrežie USA). Ping medzi virtuálnymi strojmi cez tunel 24ms, čo nie je až také zlé.

Zároveň sme umiestnili testovaciu oblasť v Alibaba Cloud DNS. Po delegovaní zóny na NS Ali sa čas rozlíšenia znížil zo 470 ms na 50 ms. Predtým bola zóna aj na Cloudlfare.

Paralelne s tunelom k východná Ázia1 zdvihol ďalší tunel zo Šen-čenu priamo do us-východ4. Tam vytvorili ďalšie proxy virtuálne stroje a začali testovať obe riešenia, pričom testovaciu prevádzku smerovali pomocou cookies alebo DNS. Skúšobná stolica je schematicky opísaná na nasledujúcom obrázku:

Latencia pre tunely sa ukázala byť nasledovná:
Ali cn-shenzhen <—> GCP Ázia-východ1 – 24 ms
Ali cn-shenzhen <—> GCP us-east4 — 200 ms

Testy prehliadača Catchpoint hlásili vynikajúce zlepšenie.

Porovnajte výsledky testov pre dve riešenia:

rozhodnutie
Uptime
medián
75 percentil
95 percentil

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Ide o údaje z riešenia, ktoré využíva tunel IPSEC cez východná Ázia1. Cez us-east4 boli výsledky horšie a bolo tam viac chýb, takže výsledky neuvediem.

Na základe výsledkov tohto testu dvoch tunelov, z ktorých jeden je ukončený v najbližšom regióne k Číne a druhý v cieľovom mieste, sa ukázalo, že je dôležité „vynoriť sa“ spod čínskeho firewallu čo najrýchlejšie. a potom použite rýchle siete (poskytovatelia CDN , poskytovatelia cloudu atď.). Nie je potrebné snažiť sa dostať cez firewall a dostať sa do cieľa jedným ťahom. Toto nie je najrýchlejší spôsob.

Vo všeobecnosti výsledky nie sú zlé, ale semrush.com má medián 8.8 s a 75 percentil 9.4 s (v rovnakom teste).
A predtým, ako pôjdem ďalej, rád by som urobil krátku lyrickú odbočku.

Lyrická digresia

Keď používateľ vstúpi na stránku www.semrushchina.cn, ktorý rieši prostredníctvom „rýchlych“ čínskych serverov DNS, požiadavka HTTP prechádza cez naše rýchle riešenie. Odpoveď je vrátená po rovnakej ceste, ale doména je špecifikovaná vo všetkých skriptoch JS, HTML stránkach a iných prvkoch webovej stránky semrush.com pre ďalšie zdroje, ktoré sa musia načítať pri vykresľovaní stránky. To znamená, že klient vyrieši „hlavný“ záznam A www.semrushchina.cn a prejde do rýchleho tunela, rýchlo dostane odpoveď - stránku HTML, ktorá uvádza:

• stiahnite si taký a taký js z sso.semrush.com,
• Získajte CSS súbory z cdn.semrush.com,
• a tiež urobte nejaké obrázky z dab.semrush.com
• a tak ďalej.

Prehliadač začne pre tieto zdroje prechádzať na „externý“ internet, zakaždým, keď prechádza bránou firewall, ktorá skracuje čas odozvy.

Ale predchádzajúci test ukazuje výsledky, keď na stránke nie sú žiadne zdroje semrush.comiba semrushchina.cna *.semrushchina.cn rieši adresu virtuálneho počítača v Shenzhene, aby sa potom dostal do tunela.

Len tak, vytlačením všetkej možnej prevádzky na maximum cez vaše riešenie pre rýchle prejdenie čínskym firewallom, môžete získať prijateľné rýchlosti a indikátory dostupnosti webu, ako aj poctivé výsledky testov riešení.
Urobili sme to bez jedinej úpravy kódu na produktovej strane tímu.

Podfilter

Riešenie sa zrodilo takmer okamžite po tom, čo tento problém vyplával na povrch. Potrebovali sme PoC (Proof of Concept), že naše riešenia prieniku cez firewall naozaj fungujú dobre. Aby ste to dosiahli, musíte do tohto riešenia čo najviac zabaliť všetku návštevnosť stránok. A prihlásili sme sa podfilter v nginx.

Podfilter je pomerne jednoduchý modul v nginx, ktorý vám umožňuje zmeniť jeden riadok v tele odpovede na iný riadok. Takže sme zmenili všetky výskyty semrush.com na semrushchina.cn vo všetkých odpovediach.

A... nefungovalo to, pretože sme dostali komprimovaný obsah z backendov, takže podfilter nenašiel požadovaný riadok. Musel som pridať ďalší lokálny server do nginx, ktorý dekomprimoval odpoveď a odovzdal ju ďalšiemu lokálnemu serveru, ktorý už bol zaneprázdnený výmenou reťazca, jeho kompresiou a odoslaním na ďalší proxy server v reťazci.

V dôsledku toho, kde by klient dostal .semrush.com, dostal .semrushchina.cn a poslušne prešiel naším rozhodnutím.

Nestačí však jednoducho zmeniť doménu jedným spôsobom, pretože backendy stále očakávajú semrush.com v nasledujúcich požiadavkách od klienta. Podľa toho na tom istom serveri, kde sa vykonáva jednosmerná výmena, pomocou jednoduchého regulárneho výrazu získame subdoménu z požiadavky a potom proxy_pass s premennou $ hostiteľ, vystavený v $subdomain.semrush.com. Môže sa to zdať mätúce, ale funguje to. A funguje to dobre. Pre jednotlivé domény, ktoré vyžadujú odlišnú logiku, jednoducho vytvorte vlastné bloky servera a vytvorte samostatnú konfiguráciu. Nižšie sú skrátené konfigurácie nginx kvôli prehľadnosti a demonštrácii tejto schémy.

Nasledujúca konfigurácia spracováva všetky požiadavky z Číny 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;
    }
}

Táto konfigurácia sa používa proxy na localhost na port 83 a čaká tam nasledujúca konfigurácia:

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

Opakujem, toto sú orezané konfigurácie.

Ako to. Môže to vyzerať zložito, ale je to slovami. V skutočnosti je všetko jednoduchšie ako dusená repa :)

Koniec odbočky

Chvíľu sme sa tešili, pretože mýtus o padajúcich IPSEC tuneloch sa nepotvrdil. Potom však začali padať tunely. Niekoľkokrát denne na pár minút. Trochu, ale to nám nevyhovovalo. Keďže oba tunely boli ukončené na strane Ali na rovnakom smerovači, rozhodli sme sa, že možno ide o regionálny problém a musíme zvýšiť záložnú oblasť.

Vyzdvihli to. Tunely začali zlyhávať v rôznych časoch, ale prepnutie pri zlyhaní pre nás fungovalo dobre na upstream úrovni v nginx. Potom však tunely začali padať približne v rovnakom čase 🙂 A znova začali 502 a 504. Doba prevádzky sa začala zhoršovať, takže sme začali pracovať na možnosti s Alibaba CEN (Cloud Enterprise Network).

CEN

CEN - ide o prepojenie dvoch VPC z rôznych regiónov v rámci Alibaba Cloud, to znamená, že môžete navzájom prepojiť súkromné ​​siete ľubovoľných regiónov v rámci cloudu. A čo je najdôležitejšie: tento kanál má dosť prísny SLA. Je veľmi stabilný z hľadiska rýchlosti aj prevádzkyschopnosti. Ale nikdy to nie je také jednoduché:

• je VEĽMI ťažké získať, ak nie ste čínskymi občanmi alebo právnickou osobou,
• Musíte platiť za každý megabit šírky pásma kanála.

Mať možnosť sa spojiť Pevninskej Číne и zámoriasme vytvorili CEN medzi dvoma regiónmi Ali: cn-shenzhen и us-východ-1 (najbližší bod k nám-východ4). V Ali us-východ-1 zdvihol ďalší virtuálny stroj, aby bol ešte jeden poskok.

Dopadlo to takto:

Výsledky testu prehliadača sú nižšie:

rozhodnutie
Uptime
medián
75 percentil
95 percentil

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Výkon je o niečo lepší ako IPSEC. Ale cez IPSEC môžete potenciálne sťahovať rýchlosťou 100 Mbit/s a cez CEN len rýchlosťou 5 Mbit/s a viac.

Znie to ako hybrid, však? Skombinujte rýchlosť IPSEC a stabilitu CEN.

To je to, čo sme urobili, povolili prevádzku cez IPSEC aj CEN v prípade zlyhania tunela IPSEC. Prevádzková doba sa výrazne zvýšila, ale rýchlosť načítania stránok stále zostáva príliš vysoká. Potom som nakreslil všetky obvody, ktoré sme už použili a otestovali, a rozhodol som sa, že do tohto obvodu skúsim pridať trochu viac GCP, konkrétne viečko.

viečko

viečko - je Global Load Balancer (alebo Google Cloud Load Balancer). Má to pre nás dôležitú výhodu: v kontexte CDN to má anycast IP, ktorý vám umožňuje nasmerovať prevádzku do dátového centra najbližšie ku klientovi, aby sa návštevnosť rýchlo dostala do rýchlej siete Google a menej prechádzala cez „bežný“ internet.

Bez rozmýšľania sme zdvihli HTTP/HTTPS LB Naše virtuálne stroje sme nainštalovali s podfiltrom v GCP a ako backend.

Existovalo niekoľko schém:

• použitie Cloudflare China Network, ale tentoraz by mal Origin špecifikovať globálne IP GLB.
• Ukončiť klientov na cn-shenzhen, a odtiaľ proxy návštevnosť priamo na viečko.
• Choďte priamo z Číny do viečko.
• Ukončiť klientov na cn-shenzhen, odtiaľ proxy do východná Ázia1 cez IPSEC (v us-východ4 cez CEN), odtiaľ prejdite do GLB (kľudne bude obrázok a vysvetlenie nižšie)

Testovali sme všetky tieto možnosti a niekoľko ďalších hybridných:

• Cloudflare + GLB

Táto schéma nám nevyhovovala z dôvodu dostupnosti a chýb DNS. Ale test bol vykonaný pred opravou chyby na strane CF, možno je to teraz lepšie (to však nevylučuje časové limity HTTP).

• Ali + GLB

Táto schéma nám nevyhovovala ani z hľadiska dostupnosti, keďže GLB často vypadávala z upstreamu z dôvodu nemožnosti pripojenia v prijateľnom čase alebo časovom limite, pretože pre server v Číne zostáva adresa GLB mimo, a teda za čínsky firewall. Kúzlo sa nekonalo.

• Iba GLB

Možnosť podobná predchádzajúcej, len nepoužívala servery v samotnej Číne: prevádzka smerovala priamo do GLB (záznamy DNS boli zmenené). Výsledky teda neboli uspokojivé, keďže bežní čínski klienti využívajúci služby bežných poskytovateľov internetu majú oveľa horšiu situáciu s prechodom cez firewall ako Ali Cloud.

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

Tu sme sa rozhodli použiť to najlepšie zo všetkých riešení:

• stabilita a garantovaná SLA od CEN
• vysoká rýchlosť od IPSEC
• „Rýchla“ sieť Google a jej Anycast.

Schéma vyzerá asi takto: prevádzka používateľa je ukončená na virtuálnom počítači v ch-shenzhen. Sú tam nakonfigurované upstreamy Nginx, z ktorých niektoré smerujú na súkromné ​​IP servery umiestnené na druhom konci tunela IPSEC a niektoré upstreamy smerujú na súkromné ​​adresy serverov na druhej strane CEN. IPSEC nakonfigurovaný na región východná Ázia1 v GCP (v čase vytvorenia riešenia to bol najbližší región k Číne. GCP má teraz zastúpenie aj v Hongkongu). CEN - do regiónu us-východ1 v Ali Cloud.

Potom bola doprava z oboch koncov smerovaná na anycast IP GLB, teda do najbližšieho bodu prítomnosti Google, a prešiel cez jeho siete do regiónu us-východ4 v GCP, v ktorom boli náhradné virtuálne stroje (s podfiltrom v nginx).

Toto hybridné riešenie, ako sme očakávali, využilo výhody každej technológie. Vo všeobecnosti prevádzka prechádza rýchlym IPSEC, ale ak začnú problémy, rýchlo a na pár minút tieto servery vyhodíme z upstreamu a posielame prevádzku iba cez CEN, kým sa tunel nestabilizuje.

Implementáciou štvrtého riešenia z vyššie uvedeného zoznamu sme dosiahli to, čo sme chceli a čo od nás v danom čase vyžadoval obchod.

Výsledky testov prehliadača pre nové riešenie v porovnaní s predchádzajúcimi:

rozhodnutie
Uptime
medián
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 nami implementovanom riešení je všetko dobré, no chýba CDN, ktoré by mohlo zrýchliť dopravu na regionálnej a dokonca aj mestskej úrovni. Teoreticky by to malo zrýchliť stránku pre koncových používateľov využitím rýchlych komunikačných kanálov poskytovateľa CDN. A my sme na to celý čas mysleli. A teraz nastal čas na ďalšiu iteráciu projektu: vyhľadávanie a testovanie poskytovateľov CDN v Číne.

A o tom vám poviem v ďalšej, záverečnej časti :)

Zdroj: hab.com