ProHoster > Блог > Administracija > Kako smo probili Veliki kineski zaštitni zid (2. dio)

Kako smo probili Veliki kineski zaštitni zid (2. dio)

Zdravo!

Nikita je ponovo sa vama, sistem inženjer iz kompanije SEMrush. I ovim člankom nastavljam priču o tome kako smo došli do rješenja za zaobilazno rješenje Kineski zaštitni zid za našu uslugu semrush.com.

В prethodni dio Rekao sam:

  • koji problemi nastaju nakon donošenja odluke "Moramo učiniti da naša usluga radi u Kini"
  • Kakve probleme ima kineski internet?
  • zašto vam je potrebna ICP licenca?
  • kako i zašto smo odlučili da testiramo naše testne ploče sa Catchpoint-om
  • što je bio rezultat našeg prvog rješenja baziranog na Cloudflare China Network
  • Kako smo pronašli grešku u Cloudflare DNS-u

Ovaj dio je po mom mišljenju najzanimljiviji jer se fokusira na specifične tehničke implementacije inscenacije. I mi ćemo početi, odnosno nastaviti sa Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud je prilično veliki provajder u oblaku, koji ima sve usluge koje mu omogućavaju da se iskreno nazove cloud provajderom. Dobro je što imaju mogućnost da se registruju za strane korisnike, a većina sajta je prevedena na engleski (za Kinu je to luksuz). U ovom oblaku možete raditi sa mnogim regijama svijeta, kontinentalnom Kinom, kao i okeanskom Azijom (Hong Kong, Tajvan, itd.).

IPsec

Počeli smo sa geografijom. S obzirom da se naša testna stranica nalazila na Google Cloud-u, morali smo "povezati" Alibaba Cloud sa GCP-om, pa smo otvorili listu lokacija na kojima je Google prisutan. U tom trenutku još nisu imali svoj data centar u Hong Kongu.
Ispostavilo se da je najbliža regija azija-istok1 (Tajvan). Ispostavilo se da je Ali najbliža regija kontinentalne Kine Tajvanu cn-shenzhen (Shenzhen).

Uz pomoć teraform opisao i podigao cjelokupnu infrastrukturu u GCP i Ali. Tunel od 100 Mbit/s između oblaka krenuo je gotovo trenutno. Na strani Šenžena i Tajvana, pokrenute su virtuelne mašine za proxy. U Shenzhenu se korisnički promet prekida, proksi kroz tunel do Tajvana, a odatle ide direktno na vanjski IP našeg servisa u us-istok (Istočna obala SAD). Ping između virtuelnih mašina putem tunela 24ms, što i nije tako loše.

Istovremeno smo postavili i testno područje Alibaba Cloud DNS. Nakon delegiranja zone na NS Ali, vrijeme rezolucije se smanjilo sa 470 ms na 50 ms. Prije toga, zona je također bila na Cloudlfareu.

Paralelno sa tunelom do azija-istok1 podigao još jedan tunel od Šenžena direktno do us-istok4. Tamo su kreirali još proxy virtuelnih mašina i počeli da testiraju oba rešenja, usmeravajući probni saobraćaj koristeći kolačiće ili DNS. Ispitni sto je shematski opisan na sljedećoj slici:

Pokazalo se da je kašnjenje za tunele sljedeće:
Ali cn-shenzhen <—> GCP asia-east1 — 24ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

Catchpoint testovi pretraživača su pokazali odlično poboljšanje.

Uporedite rezultate testova za dva rješenja:

odluka
Uptime
srednji
75 Percentil
95 Percentil

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Ovo su podaci iz rješenja koje koristi IPSEC tunel preko azija-istok1. Preko nas-istok4 rezultati su bili lošiji, a bilo je i više grešaka, tako da rezultate neću iznositi.

Na osnovu rezultata ovog testa dva tunela, od kojih je jedan završen u regionu najbližem Kini, a drugi na konačnom odredištu, postalo je jasno da je važno „izaći“ ispod kineskog zaštitnog zida što je brže moguće. moguće, a zatim koristiti brze mreže (CDN provajderi, cloud provajderi, itd.). Nema potrebe da pokušavate da prođete kroz zaštitni zid i jednim potezom stignete na odredište. Ovo nije najbrži način.

Generalno, rezultati nisu loši, međutim, semrush.com ima medijanu od 8.8s, a 75 Percentile 9.4s (na istom testu).
I prije nego što krenem dalje, želio bih napraviti kratku lirsku digresiju.

Lirska digresija

Nakon što korisnik uđe na stranicu www.semrushchina.cn, koji se rješava kroz „brze“ kineske DNS servere, HTTP zahtjev prolazi kroz naše brzo rješenje. Odgovor se vraća na istom putu, ali je domen specificiran u svim JS skriptama, HTML stranicama i drugim elementima web stranice semrush.com za dodatne resurse koji se moraju učitati kada se stranica prikaže. To jest, klijent rješava “glavni” A-zapis www.semrushchina.cn i ide u brzi tunel, brzo prima odgovor - HTML stranicu koja kaže:

  • preuzmi takav i takav js sa sso.semrush.com,
  • Preuzmite CSS fajlove sa cdn.semrush.com,
  • i uzmite neke slike sa dab.semrush.com
  • i tako dalje.

Pretraživač počinje da ide na „eksterni“ Internet za ove resurse, svaki put prolazeći kroz zaštitni zid koji troši vreme odgovora.

Ali prethodni test pokazuje rezultate kada nema resursa na stranici semrush.com, samo semrushchina.cn, a *.semrushchina.cn se razrješava na adresu virtuelne mašine u Shenzhenu kako bi potom ušao u tunel.

Samo na taj način, maksimalno gurajući sav mogući promet kroz svoje rješenje za brzo prolazak kineskog firewall-a, možete dobiti prihvatljive brzine i pokazatelje dostupnosti web stranice, kao i poštene rezultate testova rješenja.
Ovo smo uradili bez ijednog uređivanja koda na strani proizvoda tima.

Podfilter

Rješenje se rodilo gotovo odmah nakon što se ovaj problem pojavio. Trebali smo PoC (Dokaz koncepta) da naša rješenja za prodor na firewall zaista dobro funkcioniraju. Da biste to učinili, morate umotati sav promet stranice u ovo rješenje što je više moguće. I mi smo se prijavili podfilter u nginxu.

Podfilter je prilično jednostavan modul u nginx-u koji vam omogućava da promijenite jednu liniju u tijelu odgovora u drugu liniju. Tako smo promijenili sve pojave semrush.com na semrushchina.cn u svim odgovorima.

I... nije funkcioniralo jer smo primili komprimirani sadržaj od pozadina, tako da podfilter nije pronašao potrebnu liniju. Morao sam dodati još jedan lokalni server u nginx, koji je dekomprimirao odgovor i proslijedio ga sljedećem lokalnom serveru, koji je već bio zauzet zamjenom stringa, komprimiranjem i slanjem sljedećem proxy serveru u lancu.

Kao rezultat toga, gdje bi klijent primio .semrush.com, primio je .semrushchina.cn i poslušno prošao kroz našu odluku.

Međutim, nije dovoljno jednostavno promijeniti domenu na jedan način, jer backendovi i dalje očekuju semrush.com u narednim zahtjevima od klijenta. Shodno tome, na istom serveru na kojem se vrši jednosmjerna zamjena, pomoću jednostavnog regularnog izraza dobijamo poddomenu iz zahtjeva, a zatim proxy_pass sa promenljivom $host, izložen u $subdomain.semrush.com. Možda izgleda zbunjujuće, ali funkcionira. I dobro radi. Za pojedinačne domene koje zahtijevaju drugačiju logiku, jednostavno kreirajte vlastite serverske blokove i napravite zasebnu konfiguraciju. Ispod su skraćene nginx konfiguracije radi jasnoće i demonstracije ove šeme.

Sljedeća konfiguracija obrađuje sve zahtjeve iz Kine prema .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;
    }
}

Ova konfiguracija proksije za localhost na port 83, a tamo čeka sljedeća 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, ovo su izrezane konfiguracije.

Kao to. Možda izgleda komplikovano, ali to je na rečima. Zapravo, sve je jednostavnije od repe na pari :)

Kraj digresije

Neko vrijeme smo bili sretni jer mit o padu IPSEC tunela nije potvrđen. Ali onda su tuneli počeli da padaju. Nekoliko puta dnevno po nekoliko minuta. Malo, ali to nam nije odgovaralo. Pošto su oba tunela prekinuta na Ali strani na istom ruteru, odlučili smo da je to možda regionalni problem i da moramo podići rezervnu regiju.

Oni su ga pokupili. Tuneli su počeli kvariti u različito vrijeme, ali nam je prelazak na grešku dobro funkcionirao na uzvodnom nivou u nginxu. Ali onda su tuneli počeli padati otprilike u isto vrijeme 🙂 I ponovo su počeli 502 i 504. Uptime je počelo da se pogoršava, pa smo počeli raditi na opciji sa Alibaba CEN (Cloud Enterprise Network).

CEN

CEN - ovo je povezanost dva VPC-a iz različitih regiona unutar Alibaba Cloud-a, odnosno možete međusobno povezati privatne mreže bilo koje regije unutar oblaka. I što je najvažnije: ovaj kanal ima prilično strogu SLA. Vrlo je stabilan kako u brzini tako iu vremenu rada. Ali nikad nije tako jednostavno:

  • JAKO je teško dobiti ako niste kineski državljani ili pravno lice,
  • Morate platiti za svaki megabit kapaciteta kanala.

Imati priliku za povezivanje Kopno и prekomorski, kreirali smo CEN između dvije Ali regije: cn-shenzhen и us-istok-1 (najbliža tačka nama-istok4). U Ali us-istok-1 podigao još jednu virtuelnu mašinu tako da postoji još jedna skakutati.

Ispalo je ovako:

Rezultati testa pretraživača su u nastavku:

odluka
Uptime
srednji
75 Percentil
95 Percentil

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Performanse su nešto bolje od IPSEC-a. Ali kroz IPSEC potencijalno možete preuzeti brzinom od 100 Mbit/s, a preko CEN-a samo brzinom od 5 Mbit/s i više.

Zvuči kao hibrid, zar ne? Kombinujte IPSEC brzinu i CEN stabilnost.

To je ono što smo uradili, dozvoljavajući saobraćaj kroz IPSEC i CEN u slučaju kvara IPSEC tunela. Vrijeme rada je postalo mnogo veće, ali brzina učitavanja stranice i dalje ostavlja mnogo željenog. Zatim sam nacrtao sva kola koja smo već koristili i testirali, i odlučio da pokušam dodati još malo GCP ovom kolu, tj. kapa.

kapa

kapa Je Global Load Balancer (ili Google Cloud Load Balancer). Za nas ima važnu prednost: u kontekstu CDN-a ima anycast IP, koji vam omogućava da usmjerite promet u podatkovni centar koji je najbliži klijentu, tako da promet brzo ulazi u Googleovu brzu mrežu, a manje prolazi kroz „običan“ internet.

Bez razmišljanja, podigli smo HTTP/HTTPS LB Instalirali smo naše virtuelne mašine sa podfilterom u GCP i kao backend.

Bilo je nekoliko šema:

  • Upotreba Cloudflare kineska mreža, ali ovaj put Origin treba specificirati global IP GLB.
  • Ukinuti klijente na cn-shenzhen, a odatle proxy promet direktno na kapa.
  • Idite pravo iz Kine u kapa.
  • Ukinuti klijente na cn-shenzhen, odatle proxy za azija-istok1 preko IPSEC-a (in us-istok4 preko CEN-a), odatle u GLB (mirno, bit će slika i objašnjenje ispod)

Testirali smo sve ove opcije i još nekoliko hibridnih:

  • Cloudflare + GLB

Ova šema nam nije odgovarala zbog neprekidnog rada i DNS grešaka. Ali test je obavljen prije nego što je greška ispravljena na strani CF-a, možda je sada bolje (međutim, ovo ne isključuje HTTP timeouts).

  • Ali + GLB

Ova šema nam takođe nije odgovarala u smislu produženja rada, jer je GLB često ispadao iz upstream-a zbog nemogućnosti povezivanja u prihvatljivom vremenu ili tajm-autu, jer za server unutar Kine GLB adresa ostaje izvan, a samim tim i iza Kineski zaštitni zid. Magija se nije dogodila.

  • Samo GLB

Opcija slična prethodnoj, samo što nije koristila servere u samoj Kini: saobraćaj je išao direktno na GLB (promijenjeni su DNS zapisi). Shodno tome, rezultati nisu bili zadovoljavajući, jer obični kineski klijenti koji koriste usluge običnih internet provajdera imaju mnogo lošiju situaciju sa prolaskom firewall-a od Ali Cloud-a.

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

Ovdje smo odlučili koristiti najbolje od svih rješenja:

  • stabilnost i zagarantovani SLA od CEN-a
  • velika brzina od IPSEC-a
  • Googleova "brza" mreža i njen anycast.

Shema izgleda otprilike ovako: korisnički promet se prekida na virtuelnoj mašini u ch-shenzhen. Tamo su konfigurisani Nginx upstreamovi, od kojih neki upućuju na privatne IP servere koji se nalaze na drugom kraju IPSEC tunela, a neki uzvodni na privatne adrese servera s druge strane CEN-a. IPSEC konfiguriran za regiju azija-istok1 u GCP-u (bio je najbliži region Kini u vrijeme kada je rješenje kreirano. GCP je sada prisutan iu Hong Kongu). CEN - regiji us-istok1 Ali Cloud.

Tada je saobraćaj sa oba kraja bio usmjeren na anycast IP GLB, odnosno do najbliže tačke prisustva Gugla, i preko njegovih mreža otišao u region us-istok4 u GCP-u, u kojem su bile zamjenske virtuelne mašine (sa podfilterom u nginx-u).

Ovo hibridno rješenje, kao što smo i očekivali, iskoristilo je prednosti svake tehnologije. Općenito, promet ide kroz brzi IPSEC, ali ako počnu problemi, brzo i na nekoliko minuta izbacujemo ove servere iz uzvodnog i šaljemo promet samo kroz CEN dok se tunel ne stabilizira.

Implementacijom 4. rješenja sa gore navedene liste, postigli smo ono što smo željeli i ono što je poslovanje u tom trenutku od nas zahtijevalo.

Rezultati testiranja pretraživača za novo rješenje u poređenju sa prethodnim:

odluka
Uptime
srednji
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

Sve je dobro u rješenju koje smo implementirali, ali ne postoji CDN koji bi mogao ubrzati promet na regionalnom, pa i gradskom nivou. U teoriji, ovo bi trebalo ubrzati stranicu za krajnje korisnike korištenjem brzih komunikacijskih kanala CDN provajdera. I stalno smo razmišljali o tome. A sada je došlo vrijeme za sljedeću iteraciju projekta: pretraživanje i testiranje CDN provajdera u Kini.

A o tome ću vam pričati u narednom, završnom dijelu :)

izvor: www.habr.com

Dodajte komentar