🥇Cum am spart Marele Firewall al Chinei (partea 1)

Bună ziua tuturor!

Nikita este în legătură - un inginer de sistem de la companie SEMrush. Astăzi vă voi spune despre cum ne-am confruntat cu sarcina de a asigura stabilitatea serviciului nostru semrush.com în China și ce probleme am întâmpinat în timpul implementării acestuia (având în vedere locația centrului nostru de date pe coasta de est a Statelor Unite).

Aceasta va fi o poveste mare, împărțită în mai multe articole. Vă voi spune cum s-a întâmplat totul pentru noi: de la un serviciu complet nefuncțional din China, la indicatorii de performanță ai serviciului la nivelul versiunii americane pentru americani. Promit că va fi interesant și util. Deci să mergem.

Probleme ale internetului chinezesc

Despre a auzit chiar și cea mai îndepărtată persoană de specificul administrării rețelei Marele firewall al Chinei. Wow, sună tare, nu? Dar ce este și cum funcționează de fapt este o întrebare destul de complicată. Puteți găsi multe articole pe Internet dedicate acestui lucru, dar din punct de vedere tehnic, designul acestui firewall nu este descris nicăieri. Ceea ce, însă, nu este surprinzător. Recunosc imediat că, pe baza rezultatelor unui an de muncă, nu voi putea spune exact cum funcționează, dar vă pot spune despre comentariile și concluziile mele practice. Și vom începe cu zvonuri despre acest firewall.

Există multe zvonuri despre acest firewall. Să colectăm cele mai importante și mai interesante dintre ele într-o singură listă:

Google, Facebook, Twitter și alte servicii similare sunt blocate și nu funcționează în China.
Orice trafic care merge ÎN AFARA Chinei și INTRO China este analizat și limitat folosind învățarea automată (în cazul traficului suspect), ceea ce îl încetinește foarte mult (traficul) care trece prin graniță.
Agențiile de informații chineze vor pirata orice trafic criptat care trece prin firewall-ul lor.
Tunelurile VPN, tunelurile IPSEC sunt instabile, se prăbușesc și sunt blocate în mod constant.
Cu cât criptarea este mai simplă, cu atât expresia de acces folosită pentru autentificarea/criptarea traficului este mai simplă, cu atât trece mai repede prin firewall-ul chinez.

Iată ce am aflat despre aceste zvonuri:

Google, Facebook, Twitter și alte servicii similare sunt într-adevăr blocate (KO), dar multe domenii tehnice Google, de exemplu, nu sunt interzise și funcționează (același gstatic.com). De aici rezultă concluzia: nu ar trebui să tăiați cu nesăbuință toate resursele Google și alte resurse care par a fi blocate.
Orice trafic care trece granița adaugă într-adevăr o întârziere serioasă la timpul său. Uită-te la cele două rezultate. Un site, o pagină, simplu GET răsuci'om. Prima măsurătoare a fost chiar din China (frumosul oraș Shenzhen). Al doilea a fost măsurat din exterior din Hong Kong (are suveranitate și nu există firewall între el și lume). Distanța dintre orașe în linie dreaptă este de aproximativ 30-40 km.

nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  381k    0  381k    0     0  71824      0 --:--:--  0:00:05 --:--:-- 82832
time_namelookup:  0.004500
time_connect:  0.169342
time_appconnect:  0.723189
time_pretransfer:  0.723499
time_redirect:  0.000000
time_starttransfer:  1.532912
----------
time_total:  5.443407
----------
size_download:  390968 Bytes
speed_download:  71824.000B/s

nikita@china-hongkong:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  319k    0  319k    0     0  2555k      0 --:--:-- --:--:-- --:--:-- 2573k
time_namelookup:  0.029366
time_connect:  0.030742
time_appconnect:  0.047310
time_pretransfer:  0.047388
time_redirect:  0.000000
time_starttransfer:  0.120793
----------
time_total:  0.124871
----------
size_download:  326755 Bytes
speed_download:  2616740.000B/s

Notă time_connect. Și, în general, vezi rezultatul: firewall-ul adaugă 4 secunde în plus, ceea ce este monstruos de lung.

Tunelurile VPN și IPSEC eșuează adesea. Voi vorbi despre asta puțin mai târziu și mai detaliat. Serverele VPN care sunt utilizate de utilizatori sunt blocate în timp (de obicei, într-o zi după începerea utilizării).
Există o opinie primită de la oamenii care locuiesc în China că, cu cât criptarea traficului este mai simplă, cu atât trece mai repede granița, pentru că este ușor de înțeles că nu este nimic ilegal în asta. Și în același mod, traficul „curat” primește mai multă lățime de bandă și viteză de trecere, în timp ce traficul „murdar”, în care nimic nu poate fi înțeles, primește, dimpotrivă, o trecere mai lentă. De exemplu, voi folosi curl to ifconfig.co prin protocolul HTTPS și HTTP.

curl -o /dev/null -w@curl_time "https://ifconfig.co/"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    13  100    13    0     0      2      0  0:00:06  0:00:05  0:00:01     3
time_namelookup:  0.004305
time_connect:  0.397465
time_appconnect:  5.149305
time_pretransfer:  5.149393
time_redirect:  0.000000
time_starttransfer:  5.568847
----------
time_total:  5.568893
----------
size_download:  13 Bytes
speed_download:  2.000B/s

curl -o /dev/null -w@curl_time "http://ifconfig.co/"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    13  100    13    0     0     28      0 --:--:-- --:--:-- --:--:--    28
time_namelookup:  0.004282
time_connect:  0.212457
time_appconnect:  0.000000
time_pretransfer:  0.212484
time_redirect:  0.000000
time_starttransfer:  0.450565
----------
time_total:  0.450620
----------
size_download:  13 Bytes
speed_download:  28.000B/s

O diferență de 5 secunde pentru un timp total de descărcare de 13 octeți. Mai mult, atunci când faceți un astfel de test de mai multe ori, puteți observa că GET pe HTTP este finalizat în general în același timp de fiecare dată, în timp ce pe HTTPS site-ul răspunde uneori în 3, 5, 10 și chiar 17 secunde. Uneori apar erori SSL:

Unknown SSL protocol error in connection to ifconfig.co:443.

Deci ce avem:

Problemele create de firewall-ul chinezesc sunt descrise mai sus.
Ping-urile la resurse externe și în interiorul tunelurilor dispar periodic.
Latența dintre două puncte este în continuă schimbare și, adesea, este pur și simplu imprevizibilă. Când conectați diferite orașe/regiuni, vă așteptați ca, pe baza locației geografice a regiunilor, întârzierea să fie mai mică, dar obțineți exact situația inversă.
Internetul și canalele de comunicare sunt fie rapide, fie lente. Există o ușoară dependență de ora și ziua săptămânii, dar nu întotdeauna.
Solicitările DNS către lumea exterioară din China depășesc uneori timpul de expirare permis.

Imaginea care apare este pur și simplu „excelentă”.

Centrul de date, așa cum am spus deja, se află în estul Statelor Unite, iar întregul SEMrush constă din zeci de produse interconectate, backend-uri, frontend-uri, baze de date și toate acestea în DC și cloud. Noi, ca o echipă de administratori de sistem, am primit sarcina de a începe rapid să lucrăm în China, cu puțin efort.

A trebuit să răspundem la o întrebare importantă: este posibil să ne descurcăm cu cheltuieli mici și să rezolvăm toate problemele asociate cu internetul și firewall-ul chinezesc la nivel de rețea/cloud/server?

Am început prin a primi ICP-licențele.

Licență ICP

Pentru a vă putea găzdui serviciul în China (China continentală) și a efectua teste, trebuie mai întâi să obțineți o licență ICP pentru domeniu.

Dacă traficul de utilizatori al site-ului dvs. este încheiat în China continentală și dacă domeniul dvs. nu are o licență ICP, traficul dvs. va fi blocat pe partea ISP/gazdă. Interesant este că licența ICP include un anumit furnizor, fie că este Cloudflare sau Alibaba Cloud. Prin urmare, dacă ați primit o licență ICP pentru Cloudflare și ați găzduit site-ul web cu aceștia, nu veți putea să vă mutați „fără probleme” la Alibaba Cloud. Va trebui să adăugați o altă găzduire la această licență.

După ce am primit o licență ICP pentru domeniu, am putut veni cu și implementăm idei și soluții tehnice specifice.

Soluții de testare

Dar înainte de a crea direct opțiuni de punere în scenă, rotiți butoanele, optimizați performanța site-ului și viteza acestuia, trebuie să alegeți un instrument de testare pentru a vedea care dintre acțiunile noastre îmbunătățesc sau, dimpotrivă, înrăutățesc performanța site-ului.

Instrumentul nostru de testare trebuia să îndeplinească două cerințe principale:

ar trebui să poată rula teste din China,
trebuie să aibă teste de browser.

Așa că am găsit Punct de captură! Au o acoperire excelentă a locațiilor de testare din întreaga lume. În China, testele pot fi efectuate și din 100500 de provincii prin intermediul acestui instrument. Fiecare are mai mulți furnizori diferiți + capacitatea de a face Șira spinării-teste (ceva ca o mașină virtuală într-un centru de date) și Ultima milă-teste (cât mai aproape de condițiile utilizatorului, aka stație de lucru). Ultimul tip de teste este mai scump.

După ce am încheiat un contract anual (mai puțin de atât nu este posibil), am început să studiem instrumentul. Sincer, am fost plăcut surprinși de funcționalitatea sa. Puteți rula:

teste DNS,
Teste web (teste de browser, GET/POST simplu, emulare client mobil etc.),
Verificări tranzacționale (de exemplu, autentificare),
teste API,
Ping, traceroute, NTP etc.

Nu poți enumera totul. Și cel mai important, fiecare test poate fi personalizat destul de bine adăugând o grămadă de anteturi și alți parametri. Rezultatul este o cantitate imensă de informații care descrie complet testul dvs. Dacă vorbim despre cele mai interesante lucruri pentru noi (teste de browser), rezultatul include:

Conectare, așteptare, încărcare, SSL, timp DNS,
TTFB, TTLB, document complet, timp de randare, încărcare DOM,
Răspuns (ceva apropiat de Time To First Byte), Webpage Response (ceva apropiat de Time To Last Byte),
Orice percentilă, medie, timp median
etc.

În consecință, toate aceste valori sunt excelente pentru a vedea schimbările și pentru a înțelege dacă lucrurile s-au îmbunătățit. Ne-am uitat în principal la Răspuns, răspuns la pagina web, mediană, 75 și 95 de percentile.

O întrebare importantă care a fost în aer încă de la început: Poți avea încredere în Catchpoint?? Acest instrument reflectă viteza reală de încărcare a site-ului din China din diferite orașe sau este doar un fel de test într-un vid care nu are nimic de-a face cu experiența reală a utilizatorului?
Aceasta este o mare problemă, deoarece fiind în Rusia, este aproape imposibil să aflați în mod fiabil cum funcționează un site din China. Făcând un proxy șosete printr-o mașină virtuală, rezultatul final este că site-ul se încarcă în câteva minute, ceea ce este pur și simplu inacceptabil pentru teste, deci singura opțiune pentru testarea manuală este curl și simplu GET de pe consolă cu un temporizator. . Acest lucru ajută, deoarece acest test reflectă bine viteza soluției de rețea, iar dacă există și teste de browser, atunci este foarte bun.

Mai târziu, noi înșine am mers în China și ne-am convins că Puteți avea încredere în Catchpoint; acesta reflectă destul de exact indicatori reali de performanță.

Rețeaua Cloudflare China

Deoarece folosim cu succes Cloudflare pentru domeniul principal semrush.com, am decis să încercăm imediat funcția lor numită Rețeaua Chinei. Această opțiune este activată numai pentru site-urile Enterprise la cerere separată și pentru o taxă suplimentară. De asemenea, este disponibil numai pentru site-urile care au o licență ICP corespunzătoare care listează Cloudflare ca furnizor. După activare, „CDN-ul chinezesc” de la Cloudflare devine disponibil pentru site - traficul din regiunile chineze aterizează la cel mai apropiat PoP (Points of Presence) CF, iar apoi prin rețelele sale sau prin rețelele de furnizori/parteneri este livrat la origine. .

Diagrama acestui banc de testare este prezentată mai jos.

Aceasta este o opțiune grozavă pentru noi. Se pare că al doilea domeniu va fi și pentru CF, ceea ce nu se adaugă la numărul de soluții folosite în companie și, de asemenea, practic nu complică infrastructura.

Am efectuat teste de browser și iată ce s-a întâmplat:

Diamantele roșii sunt eșecuri ale testului. Fișierele de mai jos sunt erori DNS (rezolvare timeout). Eșecurile din partea de sus sunt timeout-uri.

Timp de funcționare: 86.6
Mediană: 18 s
75 Percentila: 29.3s
95 Percentila: 60s

Mediana, după ce încărcarea a fost eliminată reCAPTCHA (Serviciul Google blocat în China) a scăzut de la 28 la 18 secunde. Dar acestea sunt încă rezultate teribile, având în vedere că același test pentru semrush.com (din SUA) a dat mai puțin de 10 secunde pentru 95% dintre utilizatori (din SUA) pe aceeași pagină (static + dinamic).

Puteți intra în fiecare test și puteți privi Cascadă și alți parametri mai detaliați. Am început să investigăm motivele erorilor și, dacă pentru timeout-uri totul este mai mult sau mai puțin clar: Internetul în China „se mișcă și iese”, din această cauză viteza de conectare și încărcare a resurselor din străinătate este instabilă și inegală, atunci erorile DNS ne-au surprins foarte mult. Am aflat ca PoP Cloudflare se află de fapt în China, adresa site-ului se rezolvă la un IP anycast, dar serverele DNS sunt americane, motiv pentru care solicitările DNS sunt forțate să treacă peste graniță, așa că uneori eșuează.

După ce am clarificat această întrebare cu CF, s-a dovedit că Ei nu au propriile lor servere DNS în China, iar când va fi este încă necunoscut.

Prin urmare, am decis să testăm doar DNS Cloudflare și am schimbat mecanismul de operare Cloudflare pentru site-ul nostru în „Doar DNS" Acesta este un mod în care Cloudflare nu realizează traficul prin proxy, ceea ce înseamnă că nu oferă protecție DDoS, CDN și alte caracteristici și funcționează în modul unui server DNS obișnuit.

Acest suport este prezentat schematic în figura următoare. Cifra ține cont de cunoștințele emergente că serverele DNS Cloudflare se află în spatele unui firewall.

La Catchpoint am rulat teste GET simple (nu teste de browser), care au arătat o mulțime de eșecuri. Au fost cauzate de aceleași erori DNS.

Am început depanarea acestor erori folosind săpa și am constatat că la prima solicitare adresa este determinată corect, iar la cererea repetată o primim de fiecare dată SERVFAIL и nu a fost gasit. De ce se întâmplă asta dintr-o dată?

root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)

Când interogați direct serverele Cloudflare NS, nu există astfel de erori:

root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases: 

semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases: 

semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192

Aceasta înseamnă că problema este de partea serverului DNS „local” sau a serverului furnizorului.
Investigațiile ulterioare au arătat că SERVFAIL ajungem la hotărâre aaaa-înregistrări.

S-a dovedit că atunci când a solicitat de la Cloudflare aaaa-înregistrare care nu există în domeniu, a răspuns Cloudflare А-o intrare care este o eroare și neconformitate cu RFC. De ce rezoluția locală (xxxx) Nu mi-a plăcut, iar el a răspuns SERVFAIL. Acest comportament este clar vizibil în jurnalul de mai jos:

root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @x.x.x.x

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @x.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;semrushchina.cn.               IN      AAAA

;; Query time: 334 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Tue Aug 14 23:38:50 CST 2018
;; MSG SIZE  rcvd: 44

root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @dana.ns.cloudflare.com.

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;semrushchina.cn.               IN      AAAA

;; ANSWER SECTION:
semrushchina.cn.        300     IN      A       220.170.186.192

;; Query time: 185 msec
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; WHEN: Tue Aug 14 23:43:03 CST 2018
;; MSG SIZE  rcvd: 60

Am trimis un raport de eroare la Cloudflare și l-au remediat după ceva timp. Sa dovedit a fi interesant: momentan nu există încă suport IPv6 în China, așa că Cloudflare nu și-a putut emite adresa IPv6 acolo ca răspuns la o solicitare. aaaa-înregistrări. În cele din urmă, totul a fost rezolvat în așa fel încât Cloudflare a început să răspundă pentru China NU EXISTĂ DATE la astfel de cereri.

Astfel, erorile DNS din testele Catchpoint au scăzut drastic, dar nu complet. Timeout-urile sunt încă aici:

Și am început să căutăm o altă soluție.

În partea următoare vă voi spune cum am testat cloud-ul chinezesc Alibaba Cloud, cum, cu ajutorul unei mici „magie” a lui Nginx, am reușit să creăm rapid soluții PoC (Proof of Concept), cum am creat soluții Multi-Cloud, dintre care una în cele din urmă a ajutat foarte mult la accelerarea activității serviciului din China.

Rămâneţi aproape!