Hogyan törtük át a nagy kínai tűzfalat (2. rész)

Hi!

Nikita ismét veled van, a cég rendszermérnöke SEMrush. Ezzel a cikkel folytatom a történetet arról, hogyan találtuk ki a megkerülő megoldást Kínai tűzfal a semrush.com szolgáltatásunkhoz.

В előző rész Mondtam:

• milyen problémák merülnek fel a döntés meghozatala után „Működtetni kell szolgáltatásunkat Kínában”
• Milyen problémákkal küzd a kínai internet?
• miért kell ICP licenc?
• hogyan és miért döntöttünk úgy, hogy teszteljük tesztágyainkat a Catchpoint segítségével
• mi volt az első Cloudflare China Network alapú megoldásunk eredménye
• Hogyan találtunk hibát a Cloudflare DNS-ben?

Ez a rész szerintem a legérdekesebb, mert a színpadra állítás konkrét technikai megvalósításaira koncentrál. És ezzel kezdjük, vagy inkább folytatjuk Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud egy meglehetősen nagy felhőszolgáltató, amely rendelkezik minden olyan szolgáltatással, amely lehetővé teszi, hogy őszintén felhőszolgáltatónak nevezhesse magát. Még jó, hogy lehetőségük van regisztrálni a külföldi felhasználók számára, és az oldal nagy részét lefordítják angolra (Kína számára ez luxus). Ebben a felhőben a világ számos régiójával, Kínával, valamint óceániai Ázsiával (Hongkong, Tajvan stb.) dolgozhat.

IPSEC

Földrajzzal kezdtük. Mivel tesztoldalunk a Google Cloudon található, össze kellett kapcsolnunk az Alibaba Cloudot a GCP-vel, ezért megnyitottuk azon helyek listáját, ahol a Google jelen van. Abban a pillanatban még nem volt saját adatközpontjuk Hongkongban.
A legközelebbi régiónak bizonyult Ázsia-Kelet1 (Tajvan). Kiderült, hogy Ali a szárazföldi Kína Tajvanhoz legközelebb eső régiója cn-shenzhen (Senzen).

-Val terra forma leírta és felépítette a teljes infrastruktúrát a GCP-ben és az Ali-ban. Egy 100 Mbit/s sebességű alagút a felhők között szinte azonnal felment. Sencsen és Tajvan oldalán proxyzó virtuális gépeket emeltek ki. Sencsenben a felhasználói forgalmat leállítják, egy alagúton keresztül proxyzik Tajvan felé, és onnan közvetlenül a szolgáltatásunk külső IP-jére megy. us-kelet (USA keleti partja). Ping a virtuális gépek között alagúton keresztül 24ms, ami nem is olyan rossz.

Ezzel egy időben tesztterületet helyeztünk el Alibaba Cloud DNS. A zóna NS Ali-ra való delegálása után a feloldási idő 470 ms-ról órára csökkent 50 ms. Ezt megelőzően a zóna is a Cloudlfare-en volt.

Az alagúttal párhuzamosan Ázsia-Kelet1 egy másik alagutat emelt Shenzhenből közvetlenül us-kelet4. Ott több proxy virtuális gépet hoztak létre, és elkezdték tesztelni mindkét megoldást, és Cookie-k vagy DNS segítségével irányították a tesztforgalmat. A próbapad sematikus leírása a következő ábrán látható:

Az alagutak késleltetése a következőképpen alakult:
Ali cn-shenzhen <—> GCP Asia-East1 – 24ms
Ali cn-shenzhen <—> GCP us-east4 – 200 ms

A Catchpoint böngészőtesztjei kiváló javulást mutattak.

Hasonlítsa össze két megoldás vizsgálati eredményeit:

döntés
Uptime
Középső
75 Percentilis
95 Percentilis

CloudFlare
86.6
Ötvenes évek
Ötvenes évek
Ötvenes évek

IPsec
99.79
Ötvenes évek
Ötvenes évek
Ötvenes évek

Ezek egy IPSEC alagutat használó megoldásból származnak Ázsia-Kelet1. A us-east4-en keresztül az eredmények rosszabbak voltak, és több volt a hiba, ezért nem adom meg az eredményeket.

A két alagút tesztelésének eredménye alapján, amelyek közül az egyik a Kínához legközelebbi régióban, a másik pedig a végállomáson végződik, világossá vált, hogy fontos, hogy minél hamarabb „kiszabaduljunk” a kínai tűzfal alól. lehetséges, majd használjon gyors hálózatokat (CDN-szolgáltatók, felhőszolgáltatók stb.). Nem kell megpróbálni átjutni a tűzfalon, és egy csapásra eljutni a célhoz. Ez nem a leggyorsabb módszer.

Általánosságban elmondható, hogy az eredmények nem rosszak, azonban a semrush.com mediánja 8.8 s, és 75 Percentile 9.4 s (ugyanazon a teszten).
És mielőtt továbblépnék, szeretnék egy rövid lírai kitérőt tenni.

Lírai kitérő

Miután a felhasználó belép az oldalra www.semrushchina.cn, amely „gyors” kínai DNS-kiszolgálókon keresztül oldódik meg, a HTTP kérés a mi gyors megoldásunkon megy keresztül. A válasz ugyanazon az útvonalon érkezik vissza, de a domain minden JS-szkriptben, HTML-oldalon és a weboldal egyéb elemeiben meg van adva semrush.com további erőforrásokért, amelyeket az oldal renderelésekor be kell tölteni. Vagyis a kliens feloldja a „fő” A-rekordot www.semrushchina.cn és bemegy a gyors alagútba, gyorsan kap egy választ – egy HTML-oldalt, amely kimondja:

• tölts le ilyen és ehhez hasonló js-eket az sso.semrush.com webhelyről,
• Szerezze be a CSS fájlokat a cdn.semrush.com webhelyről,
• és készíts néhány képet a dab.semrush.com webhelyről
• és így tovább.

A böngésző elkezdi a „külső” Internetet keresni ezekért az erőforrásokért, minden alkalommal áthaladva egy tűzfalon, amely felemészti a válaszidőt.

De az előző teszt akkor mutatja az eredményeket, ha nincsenek források az oldalon semrush.comcsak semrushchina.cn, és a *.semrushchina.cn feloldja a sencseni virtuális gép címét, hogy aztán bejusson az alagútba.

Csak így, ha az összes lehetséges forgalmat a lehető legnagyobbra tolja át a kínai tűzfal gyors átjutását célzó megoldásán, akkor elfogadható sebességet és webhelyelérhetőségi mutatókat, valamint a megoldástesztek becsületes eredményeit érheti el.
Ezt egyetlen kódmódosítás nélkül tettük meg a csapat termékoldalán.

Alszűrő

A probléma megjelenése után szinte azonnal megszületett a megoldás. Szükségünk volt PoC (Proof of Concept), hogy tűzfal-penetrációs megoldásaink valóban jól működnek. Ehhez a webhely teljes forgalmát a lehető legnagyobb mértékben ebbe a megoldásba kell csomagolnia. És jelentkeztünk alszűrő nginxben.

Alszűrő egy meglehetősen egyszerű modul az nginxben, amely lehetővé teszi, hogy a választörzs egyik sorát egy másik sorra cserélje. Tehát minden előfordulást megváltoztattunk semrush.com on semrushchina.cn minden válaszban.

És... nem működött, mert tömörített tartalmat kaptunk a háttérrendszerektől, így az alszűrő nem találta a szükséges sort. Hozzá kellett adnom egy másik helyi szervert az nginx-hez, ami kitömörítette a választ és továbbította a következő helyi szervernek, amely már a string cseréjével, tömörítésével és a lánc következő proxyszerverére való elküldésével volt elfoglalva.

Ennek eredményeként az ügyfél hol kapna .semrush.com, megkapta .semrushchina.cn és engedelmesen végigment a döntésünkön.

Nem elég azonban egyszerűen egy irányba megváltoztatni a tartományt, mert a backendek továbbra is a semrush.com-ot várják a klienstől érkező további kérésekben. Ennek megfelelően ugyanazon a szerveren, ahol az egyirányú csere történik, egy egyszerű reguláris kifejezéssel megkapjuk a kérésből az aldomaint, majd proxy_pass változóval $ gazdagép, kiállítva ben $aldomain.semrush.com. Lehet, hogy zavarónak tűnik, de működik. És jól működik. Az eltérő logikát igénylő egyedi tartományokhoz egyszerűen hozza létre saját szerverblokkjait, és készítsen külön konfigurációt. Az alábbiakban rövidített nginx-konfigurációk találhatók az egyértelműség és a séma bemutatása érdekében.

A következő konfiguráció feldolgozza az összes kérést Kínából .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;
    }
}

Ez a konfiguráció a következőhöz proxyzik localhost a 83-as portra, és ott a következő konfiguráció vár:

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

Ismétlem, ezek kivágott konfigurációk.

Mint az. Lehet, hogy bonyolultnak tűnik, de szavakkal ez van. Valójában minden egyszerűbb, mint a párolt fehérrépa :)

A kitérő vége

Egy ideig boldogok voltunk, mert az IPSEC alagutak lezuhanásáról szóló mítosz nem igazolódott be. De aztán zuhanni kezdtek az alagutak. Naponta többször néhány percig. Kicsit, de ez nekünk nem jött be. Mivel mindkét alagút ugyanazon az útválasztón az Ali oldalon végződött, úgy döntöttünk, hogy ez talán regionális probléma, és meg kell emelnünk a tartalék régiót.

Felvették. Az alagutak különböző időpontokban kezdtek meghibásodni, de a feladatátvétel jól működött az nginx felső szintjén. De aztán az alagutak nagyjából egy időben kezdtek esni Alibaba CEN (Cloud Enterprise Network).

CEN

CEN - ez az Alibaba Cloudon belül két különböző régióból származó VPC csatlakoztathatósága, vagyis a felhőn belül bármely régió privát hálózatát összekapcsolhatja egymással. És ami a legfontosabb: ez a csatorna meglehetősen szigorú SLA. Nagyon stabil mind sebességben, mind üzemidőben. De ez soha nem ilyen egyszerű:

• NAGYON nehéz megszerezni, ha nem kínai állampolgár vagy jogi személy,
• Minden egyes megabit csatorna sávszélességért fizetnie kell.

Kapcsolódási lehetőség szárazföldi Kína и tengerentúli, létrehoztunk egy CEN-t két Ali régió között: cn-shenzhen и us-kelet-1 (hozzánk legközelebbi pont-kelet4). Aliban us-kelet-1 felemelt egy másik virtuális gépet, hogy legyen még egy komló.

Így alakult:

A böngészőteszt eredményei az alábbiak:

döntés
Uptime
Középső
75 Percentilis
95 Percentilis

CloudFlare
86.6
Ötvenes évek
Ötvenes évek
Ötvenes évek

IPsec
99.79
Ötvenes évek
Ötvenes évek
Ötvenes évek

CEN
99.75
Ötvenes évek
Ötvenes évek
Ötvenes évek

A teljesítmény valamivel jobb, mint az IPSEC. De az IPSEC-en keresztül potenciálisan 100 Mbit/s-os, CEN-en keresztül pedig csak 5 Mbit/s-os vagy nagyobb sebességgel tölthet le.

Hibridnek hangzik, igaz? Kombinálja az IPSEC sebességet és a CEN stabilitást.

Ezt tettük, lehetővé téve a forgalmat az IPSEC-en és a CEN-en is az IPSEC-alagút meghibásodása esetén. Az üzemidő sokkal magasabb lett, de a webhely betöltési sebessége még mindig sok kívánnivalót hagy maga után. Aztán lerajzoltam az összes már használt és tesztelt áramkört, és úgy döntöttem, hogy megpróbálok hozzáadni egy kis GCP-t ehhez az áramkörhöz, nevezetesen sapka.

sapka

sapka - Van Globális terheléselosztó (vagy a Google Cloud Load Balancer). Számunkra fontos előnye van: a CDN kontextusában megvan anycast IP, amely lehetővé teszi, hogy a forgalmat a klienshez legközelebb eső adatközpontba irányítsa, így a forgalom gyorsan bejut a Google gyorshálózatába, és kevesebb a „rendes” interneten keresztül.

Kétszeri gondolkodás nélkül felemeltük HTTP/HTTPS LB A virtuális gépeinket alszűrővel telepítettük GCP-ben és háttérprogramként.

Számos séma volt:

• Használat Cloudflare kínai hálózat, de az Originnek ezúttal globálisat kell megadnia IP GLB.
• Ügyfelek megszüntetése itt: cn-shenzhen, és onnan proxy a forgalmat közvetlenül ide sapka.
• Menjen egyenesen Kínából sapka.
• Ügyfelek megszüntetése itt: cn-shenzhen, onnan proxy to Ázsia-Kelet1 IPSEC-en keresztül (in us-kelet4 a CEN-en keresztül), onnan menj a GLB-re (nyugodtan, lent lesz kép és magyarázat)

Teszteltük ezeket a lehetőségeket, és még több hibridet is:

• Cloudflare + GLB

Ez a séma nem felelt meg nekünk az üzemidő és a DNS hibák miatt. De a tesztet a hiba javítása előtt végezték el a CF oldalon, talán most jobb (ez azonban nem zárja ki a HTTP időtúllépéseket).

• Ali + GLB

Ez a séma az üzemidő szempontjából sem felelt meg nekünk, mivel a GLB gyakran kiesett az upstreamből az elfogadható időn belüli csatlakozás lehetetlensége vagy az időtúllépés miatt, mivel egy Kínán belüli szervernél a GLB-cím kívül marad, így a szerver mögött marad. Kínai tűzfal. A varázslat nem történt meg.

• Csak GLB

Az előzőhöz hasonló lehetőség, csak magában Kínában nem használt szervereket: a forgalom közvetlenül a GLB-re ment (a DNS rekordok megváltoztak). Ennek megfelelően az eredmények nem voltak kielégítőek, mivel az átlagos kínai ügyfelek, akik hagyományos internetszolgáltatók szolgáltatásait használják, sokkal rosszabb helyzetben vannak a tűzfal átjutásával, mint az Ali Cloud.

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

Itt úgy döntöttünk, hogy az összes megoldás közül a legjobbat használjuk:

• stabilitás és garantált SLA a CEN-től
• nagy sebesség az IPSEC-től
• A Google „gyors” hálózata és anycastja.

A séma valahogy így néz ki: a felhasználói forgalom egy virtuális gépen leáll ch-Shenzhen. Az Nginx upstream-ek ott vannak konfigurálva, amelyek egy része az IPSEC alagút másik végén található privát IP-kiszolgálókra mutat, míg néhány upstream a CEN másik oldalán lévő szerverek privát címeire mutat. Az IPSEC régióhoz van konfigurálva Ázsia-Kelet1 a GCP-ben (a megoldás létrehozásakor Kínához legközelebbi régió volt. A GCP jelenleg Hongkongban is jelen van). CEN - régióba us-kelet1 az Ali Cloudban.

Ezután a forgalmat mindkét végéről ide irányították anycast IP GLB, azaz a Google legközelebbi jelenléti pontjához, és hálózatain keresztül eljutott a régióba us-kelet4 GCP-ben, amelyben csere virtuális gépek voltak (nginx-ben alszűrővel).

Ez a hibrid megoldás, ahogy azt vártuk, kihasználta az egyes technológiák előnyeit. Általában a forgalom gyors IPSEC-en megy keresztül, de ha problémák kezdődnek, gyorsan és néhány percre kirúgjuk ezeket a szervereket az upstreamből, és csak a CEN-en keresztül továbbítjuk a forgalmat, amíg az alagút stabilizálódik.

A fenti listából a 4. megoldás megvalósításával elértük, amit szerettünk volna, és amit az üzlet akkoriban megkívánt tőlünk.

Az új megoldás böngészőtesztjének eredményei a korábbiakhoz képest:

döntés
Uptime
Középső
75 Percentilis
95 Percentilis

CloudFlare
86.6
Ötvenes évek
Ötvenes évek
Ötvenes évek

IPsec
99.79
Ötvenes évek
Ötvenes évek
Ötvenes évek

CEN
99.75
Ötvenes évek
Ötvenes évek
Ötvenes évek

CEN/IPsec + GLB
99.79
Ötvenes évek
Ötvenes évek
Ötvenes évek

CDN

Az általunk megvalósított megoldásban minden rendben van, de nincs olyan CDN, amely regionális, sőt városi szinten is gyorsíthatná a forgalmat. Elméletileg ennek fel kell gyorsítania a webhelyet a végfelhasználók számára a CDN-szolgáltató gyors kommunikációs csatornáinak használatával. És állandóan ezen gondolkoztunk. És most eljött az ideje a projekt következő iterációjának: CDN-szolgáltatók keresésének és tesztelésének Kínában.

Erről pedig a következő, utolsó részben mesélek majd :)

Forrás: will.com