🥇Cum am depășit Marele Firewall Chinezesc (partea 1)

Salut tuturor!

Sunt Nikita — inginer sistem de la compania SEMrush. Astăzi vă voi povesti despre cum ne-am confruntat cu provocarea de a asigura stabilitatea serviciului nostru semrush.com în China și cu ce probleme ne-am întâlnit în timpul realizării acesteia (având în vedere localizarea centrului nostru de date pe coasta de est a SUA).

Va fi o poveste mare, împărțită în mai multe articole. Vă voi spune cum a fost totul pentru noi: de la un serviciu complet nefuncțional din China, până la indicatori de performanță la nivelul versiunii americane pentru americani. Promit, va fi interesant și util. Așadar, să începem.

Problemele internetului chinezesc

Chiar și cea mai îndepărtată persoană de specificul administrării rețelelor a auzit, măcar o dată, despre Marele Firewall Chinezesc. Uuu, sună grozav, nu? Dar ce este, cum funcționează de fapt — este o întrebare destul de complexă. Pe internet se pot găsi multe articole dedicate acestuia, dar din punct de vedere tehnic, structura acestui firewall nu este descrisă nicăieri. Ceea ce, de altfel, nu este surprinzător. Recunosc din start, în urma unui an de muncă nu voi putea spune exact cum funcționează, dar pot să vă împărtășesc observațiile și concluziile mele practice. Și vom începe cu zvonurile despre acest firewall.

Există multe zvonuri despre acest firewall. Să adunăm cele mai importante și 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 intră și iese din China este analizat și restricționat prin învățare automată (în cazul unui trafic suspect), ceea ce îl încetinește considerabil (traficul) în momentul trecerii graniței.
Serviciile de securitate chinezești pot sparge orice trafic criptat care trece prin firewall-ul lor.
Tunelurile VPN, tunelurile IPSEC sunt instabile, căzând și fiind constant blocate.
Cu cât criptarea este mai simplă, cu atât pass phrase-ul folosit pentru autentificarea/criptarea traficului este mai simplu, cu atât mai repede trece prin firewallul chinezesc.

Iată ce am reușit să aflăm despre aceste zvonuri:

Google, Facebook, Twitter și alte servicii similare sunt într-adevăr blocate (KO-ul dvs.), dar multe domenii tehnice ale Google, de exemplu, nu sunt blocate și funcționează (același gstatic.com). Prin urmare, concluzia este: nu trebuie să eliminați fără discernământ toate resursele Google și altele care par a fi blocate.
Orice trafic care traversează granița adaugă cu adevărat un delay considerabil. Uitați-vă la cele două rezultate. O singură pagină, un singur site, un simplu GET curl’. Prima măsurare este din China (frumos oraș Shenzhen). A doua măsurare este din exterior, din Hong Kong (are suveranitate, iar între el și lume nu există un firewall). Distanța dintre orașe pe o 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

Rețineți că time_connect. Și în general, observați rezultatul: firewall-ul adaugă 4 secunde suplimentare, ceea ce este extrem de lung.

VPN-urile și tunelurile IPSEC cad adesea. Voi discuta despre acest subiect în detaliu mai târziu. Serverele VPN utilizate de utilizatori sunt blocate în timp (de obicei, în termen de 24 de ore de la începutul utilizării).
Există o opinie din partea celor care locuiesc în China, conform căreia cu cât criptarea traficului este mai simplă, cu atât trece mai repede granița, deoarece este ușor de înțeles că în ea nu există nimic ilegal. De asemenea, traficul "curat" primește mai multă lățime de bandă și viteză de trecere, în timp ce traficul "murdar", în care nu se poate decifra nimic, are parte de un parcurs mai lent. Ca exemplu, voi prezenta curl către 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

Diferența de 5 secunde pentru timpul total de încărcare a 13 bytes. De asemenea, făcând acest test de mai multe ori, se poate observa că GET pe HTTP se finalizează într-un timp relativ constant, pe când pe HTTPS, site-ul răspunde uneori în 3, 5, 10 și chiar 17 secunde. Uneori apar erori SSL:

Eroare necunoscută a protocolului SSL în conexiunea cu ifconfig.co:443.

Așadar, ce avem:

Problemele create de firewall-ul chinez, descrise mai sus.
Pings către resurse externe și în interiorul tuneluri dispar periodic.
Latenta între două puncte variază constant și adesea este pur și simplu imprevizibilă. Conectând diferite orașe/regiuni, te aștepți ca, având în vedere locația geografică a regiunilor, latenta să fie mai mică, dar obții exact opusul.
Internetul și canalele de comunicație funcționează pe rând rapid și lent. Există o mică dependență de ora din zi și de ziua săptămânii, dar nu întotdeauna.
DNS-urile externe din China depășesc uneori timeout-ul acceptabil.

Imaginea se conturează ca fiind „excelentă”.

Datacenterul, după cum am menționat, se află în estul Statelor Unite, iar tot SEMrush este format din zeci de produse interconectate, backend-uri, frontend-uri, baze de date, și totul se află în datacenter și în cloud. Ca echipă de administratori de sistem, ne-a fost stabilită sarcina de a începe rapid activitatea în China cu eforturi minime.

Trebuia să răspundem la o întrebare importantă: putem să economisim resurse și să rezolvăm toate problemele legate de internetul și firewall-ul chinez la nivel de rețea/cloud/servere?

Am început cu obținerea licenței ICP-licenței.

licența ICP

Pentru a putea să îți găzduiești serviciul în interiorul Chinei (Mainland China) și să efectuezi teste, trebuie mai întâi să obții licența ICP pentru domeniu.

Dacă traficul utilizatorului de pe site-ul dvs. este terminat în Mainland China și dacă domeniul dvs. nu are o licență ICP, traficul va fi blocat de către furnizorul de servicii de internet/găzduire. Interesant este că licența ICP este legată de un anumit furnizor, fie acesta Cloudflare sau Alibaba Cloud. Prin urmare, dacă ați obținut o licență ICP pentru Cloudflare și v-ați găzduit site-ul la ei, ulterior nu veți putea să migrați „fără întreruperi” pe Alibaba Cloud. Va trebui să adăugați un alt furnizor de găzduire la această licență.

După obținerea licenței ICP pentru domeniu, am putut să venim cu soluții și idei tehnice specifice.

Testarea soluțiilor

Dar înainte de a crea efectiv variantele de staging, de a regla setările, de a optimiza funcționarea site-ului și viteza acestuia, trebuie să alegem un instrument pentru testare, pentru a vedea care dintre acțiunile noastre îmbunătățesc sau, dimpotrivă, afectează negativ funcționarea site-ului.

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

trebuie să aibă capacitatea de a rula teste din China,
trebuie să aibă teste în browsere.

Astfel, am găsit Catchpoint! Au o acoperire excelentă cu puncte de testare în întreaga lume. În China, prin acest instrument se pot rula teste și din 100500 de provincii. În fiecare există mai mulți furnizori diferiți + posibilitatea de a efectua teste Backbone (ceva de genul unei mașini virtuale în centru de date) șiteste Lastmile (foarte apropiate de condițiile utilizatorilor, adică stație de lucru). Ultimul tip de teste este mai costisitor. După încheierea unui contract anual (nu se poate mai puțin), am început să studiem instrumentul. Trebuie să recunoaștem că am fost plăcut surprinși de funcționalitatea sa. Se pot rula:teste DNS,

teste Web (în browsere, simple GET/POST, simularea unui client mobil etc.),

verificări tranzacționale (de exemplu, autentificare),
teste API,
Ping, traceroute, NTP etc.
Nu se pot enumera toate. Și ceea ce este cel mai important, fiecare test poate fi personalizat destul de bine, adăugând un set de antete și alte parametri. La final, se obține o cantitate imensă de informații, descriind pe deplin testul dumneavoastră. Dacă vorbim despre ceea ce este cel mai interesant pentru noi (teste în browsere), rezultatul include:
Connect, Wait, Load, SSL, DNS time,

TTFB, TTLB, Document complete, Render time, DOM load,

Response (ceva apropiat de Time To First Byte), Webpage Response (ceva apropiat de Time To Last Byte),
Orice percentilă, Timp mediu, Timp median
Și așa mai departe.
Orice percentil, medie, mediană de timp
Și altele

Prin urmare, toate aceste metrici ajută excelent la observarea schimbărilor și înțelegerea dacă s-au îmbunătățit lucrurile. Ne-am concentrat în principal pe Response, Webpage Response, Median, 75 și 95 Percentile.

O întrebare importantă care a plutesc în aer de la început: dar poate fi de încredere Catchpoint? Отражает ли этот инструмент реальную скорость загрузки сайта в Китае из разных городов или же это просто какой-то тест в вакууме, не имеющий ничего общего с real user experience?
Este o problemă mare, deoarece fiind în Rusia este practic imposibil să afli cu certitudine cum funcționează un site din China. Folosind un socks-proxy printr-o mașină virtuală, obții o încărcare a site-ului în câteva minute, ceea ce este inacceptabil pentru teste, astfel că singura opțiune pentru testarea manuală rămâne curl și simple GET din consolă cu măsurarea timpului. Acest lucru ajută, deoarece acest test reflectă bine viteza soluției de rețea, iar dacă există și teste în browser, devine și mai bine.

Ulterior, am călătorit în China și ne-am convins că se poate avea încredere în Catchpoint, el reflectă destul de precis indicatorii reali de viteză.

Cloudflare China Network

Din moment ce pentru domeniul principal semrush.com folosim cu succes Cloudflare, am decis să încercăm imediat funcția lor numită China Network. Această opțiune se activează doar pentru site-urile Enterprise, la cerere separată și contra unui cost suplimentar. De asemenea, este disponibilă doar pentru site-urile care au o licență ICP corespunzătoare, în care este specificat Cloudflare ca furnizor. După activare, site-ul beneficiază de "CDN chinezesc" de la Cloudflare — traficul din regiunile chineze ajunge la cel mai apropiat PoP (Punct de Prezență) CF, iar apoi este livrat prin rețelele sale sau rețelele providerilor/partenerilor până la origine.

Schema acestui stand de test este prezentată mai jos.

Pentru noi, acesta este o opțiune excelentă. Așadar, al doilea domeniu va fi, de asemenea, sub CF, ceea ce nu adaugă la numărul soluțiilor utilizate în companie, precum și nu complică practic infrastructura.

Am inițiat teste în browser și iată ce a rezultat:

Rombergile roșii reprezintă eșecurile testelor. Eșecurile de jos — erori DNS (timeout la rezolvare). Eșecurile de sus — timeout-uri.

Uptime: 86.6
Median: 18s
75 Percentile: 29.3s
95 Percentile: 60s

Mediana, după ce am eliminat încărcarea reCaptcha (serviciul Google, blocat în China), a scăzut de la 28 la 18 secunde. Dar, totuși, sunt indicatori teribili, având în vedere că același test pentru semrush.com (din SUA) a livrat mai puțin de 10 secunde pentru 95% din utilizatori (din SUA) pe aceeași pagină (statică + dinamică).

În fiecare test poți intra și viziona Waterfall și alte informații detaliate. Am început să investigăm cauzele erorilor, și dacă pentru timpii de așteptare totul este mai mult sau mai puțin clar: internetul din China „se leagă, apoi se deconectează”, din această cauză viteza de conectare și încărcarea resurselor din străinătate este instabilă și variabilă, atunci erorile DNS ne-au surprins profund. Am descoperit că PoP la Cloudflare se află cu adevărat în China, adresa site-ului este rezolvată într-un IP anycast, dar serverele DNS folosite sunt americane, motiv pentru care cererile DNS trebuie să treacă prin graniță, de aceea uneori acestea eșuează.

După ce am clarificat această problemă cu CF, am aflat că nu au propriile servere DNS în China, iar când vor avea – 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 modul „Doar DNS”. Acest mod este cel în care Cloudflare nu proxy-ează traficul, ceea ce înseamnă că nu oferă protecție DDoS, CDN și alte funcții, și funcționează ca un server DNS obișnuit.

Această configurație este prezentată schematic în imaginea următoare. În imagine sunt luate în considerare cunoștințele apărute cu privire la faptul că serverele DNS Cloudflare sunt în spatele unui firewall.

În Catchpoint, am executat teste GET simple (nu în browser), care au arătat foarte multe erori. Cauza acestora au fost aceleași erori DNS.

Am început să depanăm aceste erori cu ajutorul dig și am descoperit că la prima cerere adresa este determinată corect, iar la cererea repetată primim de fiecare dată SERVFAIL și not found. De ce a apărut asta?

root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn are adresă 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn are adresă 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn are adresă 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn are adresă 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)

La cererea serverelor NS Cloudflare direct, astfel de erori nu există:

root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Folosind serverul de domeniu:
Nume: ray.ns.cloudflare.com.
Adresă: 173.245.59.138#53
Aliasuri:

semrushchina.cn are adresă 220.170.186.192
semrushchina.cn are adresă 220.170.186.192
Folosind serverul de domeniu:
Nume: ray.ns.cloudflare.com.
Adresă: 173.245.59.138#53
Aliasuri:

semrushchina.cn are adresă 220.170.186.192
semrushchina.cn are adresă 220.170.186.192

Deci, problema este de partea serverului DNS „local” sau a serverului furnizorului.
O investigație ulterioară a arătat că SERVFAIL obținem la rezolvare AAAA-înregistrări.

Se pare că la cererea de la Cloudflare AAAA-înregistrare, care nu există în domeniu, Cloudflare a răspuns Un-înregistrare, ceea ce reprezintă o eroare și o inconformitate cu RFC. Din acest motiv, rezolvatorul local (x.x.x.x) nu a fost mulțumit și a răspuns SERVFAIL. În jurnalul de mai jos, acest comportament este clar vizibil:

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
;; opțiuni globale: +cmd
;; Am primit răspuns:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; steaguri: qr rd ra; ÎNTREBARE: 1, RĂSPUNS: 0, AUTORITATE: 0, ADIȚIONAL: 1

;; SECȚIUNE PSEUDOOPT:
; EDNS: versiune: 0, steaguri:; udp: 4096
;; SECȚIUNE ÎNTREBARE:
;semrushchina.cn.               IN      AAAA

;; Timp de interogare: 334 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; CÂND: Mar Aug 14 23:38:50 CST 2018
;; DIMENSIUNE MSG  primit: 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.
;; opțiuni globale: +cmd
;; Am primit răspuns:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; steaguri: qr aa rd; ÎNTREBARE: 1, RĂSPUNS: 1, AUTORITATE: 0, ADIȚIONAL: 1
;; AVERTISMENT: recursiune solicitată, dar nu disponibilă

;; SECȚIUNE PSEUDOOPT:
; EDNS: versiune: 0, steaguri:; udp: 512
;; SECȚIUNE ÎNTREBARE:
;semrushchina.cn.               IN      AAAA

;; SECȚIUNE RĂSPUNS:
semrushchina.cn.        300     IN      A       220.170.186.192

;; Timp de interogare: 185 msec
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; CÂND: Mar Aug 14 23:43:03 CST 2018
;; DIMENSIUNE MSG  primit: 60

Am trimis un raport de bug către Cloudflare, iar ei l-au rezolvat după o perioadă. A fost interesant: în acest moment, în China nu există încă suport pentru IPv6, astfel încât Cloudflare nu putea oferi adresa sa IPv6 în răspunsul la solicitare AAAA-înregistrare. În final, totul s-a rezolvat astfel încât pentru China, Cloudflare a început să răspundă NODATA la astfel de solicitări.

Astfel, erorile DNS în testele Catchpoint s-au redus brusc, dar nu au dispărut complet. Ceasurile de timeout nu au dispărut nici ele:

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

În partea următoare voi povesti cum am testat cloudul chinezesc Alibaba Cloud, cum, cu ajutorul unei mici 'magii' Nginx, am reușit să creăm rapid soluții PoC (Proof of Concept), cum am creat soluții Multi-Cloud, una dintre ele ajutând foarte mult la accelerarea serviciului din China.

Rămâneți conectați!