🥇Cumu avemu sfondatu u Great Firewall of China (parte 2)

Hello!

Nikita hè di novu cun voi, un ingegnere di sistemi di a cumpagnia SEMrush. È cù questu articulu cuntinuu a storia di cumu avemu ghjuntu cù una soluzione di soluzione Firewall cinese per u nostru serviziu semrush.com.

В parte precedente Aghju dettu:

quali prublemi nascenu dopu a decisione hè presa "Avemu bisognu di fà u nostru travagliu di serviziu in Cina"
Chì prublemi hà l'Internet Cinese ?
perchè avete bisognu di una licenza ICP?
cumu è perchè avemu decisu di pruvà i nostri testbeds cù Catchpoint
ciò chì era u risultatu di a nostra prima suluzione basatu nantu Cloudflare China Network
Cumu truvamu un bug in Cloudflare DNS

Questa parte hè a più interessante, in my opinion, perchè si cuncentra in implementazioni tecniche specifiche di staging. È avemu da principià, o megliu cuntinuà, cù Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud hè un fornitore di nuvola abbastanza grande, chì hà tutti i servizii chì permettenu di chjamà onestamente un fornitore di nuvola. Hè bonu chì anu l'uppurtunità di registrà per l'utilizatori stranieri, è chì a maiò parte di u situ hè traduttu in inglese (per a Cina questu hè un lussu). In questa nuvola, pudete travaglià cù parechje regioni di u mondu, a Cina continentale, è ancu l'Asia Oceanica (Hong Kong, Taiwan, etc.).

IPsec

Avemu principiatu cù a geografia. Siccomu u nostru situ di prova era situatu in Google Cloud, avemu bisognu di "ligà" Alibaba Cloud cù GCP, cusì avemu apertu una lista di i posti in quale Google hè presente. À quellu mumentu ùn anu micca avutu u so propiu centru di dati in Hong Kong.
A regione più vicina hè stata asia-est1 (Taiwan). Ali hè diventatu a regione più vicina di a Cina continentale à Taiwan cn-shenzhen (Shenzhen).

Cù l'aiutu di terraform hà descrittu è elevatu tutta l'infrastruttura in GCP è Ali. Un tunnel di 100 Mbit/s trà i nuvuli hà cullatu quasi istantaneamente. Da u latu di Shenzhen è Taiwan, e macchine virtuali di proxy sò state alzate. In Shenzhen, u trafficu di l'utilizatori hè terminatu, proxy attraversu un tunnel à Taiwan, è da quì si va direttamente à l'IP esterna di u nostru serviziu in noi-est (Costa Est USA). Ping trà e macchine virtuali via tunnel 24ms, chì ùn hè micca cusì male.

À u listessu tempu, avemu piazzatu una zona di prova Alibaba Cloud DNS. Dopu avè delegatu a zona à NS Ali, u tempu di risoluzione hè diminuitu da 470 ms à 50 ms. Prima di questu, a zona era ancu nantu à Cloudlfare.

Parallela à u tunnel à asia-est1 alzatu un altru tunnel da Shenzhen direttamente à noi-est4. Ci anu creatu più macchine virtuali proxy è cuminciaru à pruvà e duie suluzioni, routing u trafficu di prova cù Cookies o DNS. U bancu di prova hè descrittu schematicamente in a figura seguente:

A latenza per i tunnelli hè stata a seguente:
Ali cn-shenzhen <—> GCP asia-east1 — 24 ms
Ali cn-shenzhen <—> GCP us-east4 — 200 ms

I testi di u navigatore Catchpoint anu riportatu una migliione eccellente.

Comparare i risultati di test per duie soluzioni:

dicisioni
Uptime
Mediu
75 percentile
95 percentile

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Questa hè a dati da una suluzione chì usa un tunnel IPSEC via asia-est1. Attraversu us-east4 i risultati eranu peggiu, è ci era più errore, cusì ùn daraghju micca i risultati.

Basatu nantu à i risultati di sta prova di dui tunnelli, unu di i quali hè finitu in a regione più vicinu à a Cina, è l'altru à a destinazione finale, hè diventatu chjaru chì hè impurtante "emerge" da sottu à u firewall cinese u più prestu. pussibile, è dopu aduprà e rete veloci (provistatori CDN, fornitori di nuvola, etc.). Ùn ci hè bisognu di pruvà à passà à traversu u firewall è ghjunghje à u vostru destinazione in un colpu. Questu hè micca u modu più veloce.

In generale, i risultati ùn sò micca male, però, semrush.com hà una mediana di 8.8s, è 75 Percentile 9.4s (nantu à a stessa prova).
È prima di passà avanti, vogliu fà una breve digressione lirica.

Digressione lirica

Dopu chì l'utilizatore entra in u situ www.semrushchina.cn, chì risolve attraversu i servitori DNS chinesi "rapidi", a dumanda HTTP passa per a nostra suluzione veloce. A risposta hè tornata nantu à a stessa strada, ma u duminiu hè specificatu in tutti i script JS, pagine HTML è altri elementi di a pagina web. semrush.com per risorse supplementari chì deve esse caricate quandu a pagina hè resa. Questu hè, u cliente risolve u "principale" A-record www.semrushchina.cn è entra in u tunnel veloce, riceve rapidamente una risposta - una pagina HTML chì dice:

scaricate tali è tali js da sso.semrush.com,
Ottene i fugliali CSS da cdn.semrush.com,
è pigliate ancu alcune foto da dab.semrush.com
e accussì on.

U navigatore principia à andà à l'Internet "esternu" per queste risorse, ogni volta passendu per un firewall chì manghja u tempu di risposta.

Ma a prova precedente mostra i risultati quandu ùn ci sò risorse in a pagina semrush.com, solu semrushchina.cn, è *.semrushchina.cn risolve à l'indirizzu di a macchina virtuale in Shenzhen in modu per entra in u tunnel.

Solu in questu modu, spinghjendu tuttu u trafficu pussibule à u massimu attraversu a vostra suluzione per passà rapidamente u firewall cinese, pudete ottene velocità accettabili è indicatori di dispunibilità di u situ web, è ancu risultati onesti di teste di suluzione.
Avemu fattu questu senza una sola edizione di codice da u latu di u produttu di a squadra.

Subfiltru

A suluzione hè nata guasi subitu dopu à stu prublema. Avemu bisognu PoC (Prova di cuncettu) chì e nostre soluzioni di penetrazione di firewall funzionanu veramente bè. Per fà questu, avete bisognu à imbulighjà tuttu u trafficu di u situ in questa suluzione quantu pussibule. È avemu applicatu sottufiltru in nginx.

Subfiltru hè un modulu abbastanza simplice in nginx chì permette di cambià una linea in u corpu di risposta à una altra linea. Allora avemu cambiatu tutte l'occurrence semrush.com nantu semrushchina.cn in tutte e risposte.

È ... ùn hà micca travagliatu perchè avemu ricevutu cuntenutu cumpressu da i backends, cusì u subfiltru ùn hà micca truvatu a linea necessaria. Aviu avutu à aghjunghje un altru servitore lucale à nginx, chì decompressa a risposta è l'hà trasmessa à u servitore lucale prossimu, chì era digià occupatu à rimpiazzà a stringa, cumpressendu, è invià à u servitore proxy prossimu in a catena.

In u risultatu, induve riceve u cliente semrush.com, hà ricevutu .semrushchina.cn è ubbidiente caminava per a nostra decisione.

In ogni casu, ùn hè micca abbastanza solu per cambià u duminiu in un modu, perchè i backends aspettanu sempre semrush.com in richieste sussequenti da u cliente. In cunsiquenza, nantu à u stessu servitore induve a sustituzione unidirezionale hè fatta, usendu una espressione regulare simplice avemu u subdominiu da a dumanda, è poi facemu proxy_pass cun variabile $host, esibita in $subdomain.semrush.com. Pò esse cunfusu, ma funziona. È travaglia bè. Per i duminii individuali chì necessitanu una logica diversa, simpricimenti creanu i vostri blocchi di u servitore è fate una cunfigurazione separata. Quì sottu sò accurtati nginx configs per a chiarità è a dimostrazione di stu schema.

A seguente cunfigurazione processa tutte e dumande da a Cina à .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;
    }
}

Questa configurazione proxy à localhost à u portu 83, è a seguente cunfigurazione aspetta quì:

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

Ripetu, queste sò cunfigurazioni cropped.

Cusì. Pò esse cumplicatu, ma hè in parolle. In fatti, tuttu hè più simplice cà i rapi cotti :)

Fine di digressione

Per un tempu eramu felici perchè u mitu di caduta di i tunnel IPSEC ùn era micca cunfirmatu. Ma dopu i tunnellati cuminciaru à falà. Parechji volte à ghjornu per uni pochi di minuti. Un pocu, ma chì ùn ci cunvene micca. Siccomu i dui tunnel sò stati terminati da u latu Ali nantu à u stessu router, avemu decisu chì forse questu era un prublema regiunale è avemu bisognu di elevà a regione di salvezza.

L'anu pigliatu. I tunnellati cuminciaru à fallu in tempi diversi, ma u failover hà travagliatu bè per noi à u livellu upstream in nginx. Ma dopu i tunnellati cuminciaru à cascà quasi à u stessu tempu 🙂 E 502 è 504 cuminciaru di novu Uptime, cusì avemu cuminciatu à travaglià nantu à l'opzione Alibaba CEN (Cloud Enterprise Network).

CEN

CEN - Questa hè a cunnessione di dui VPC da diverse regioni in Alibaba Cloud, vale à dì, pudete cunnette e rete private di qualsiasi regione in u nuvulu cun l'altri. È più impurtante: stu canale hà un abbastanza strettu SLA. Hè assai stabile sia in velocità è uptime. Ma ùn hè mai cusì simplice:

Hè assai difficiuli di ottene sè ùn site micca citadini cinesi o una entità legale,
Avete bisognu di pagà per ogni megabit di larghezza di banda di u canali.

Avè l'uppurtunità di cunnette Mainland China и Dipartimenti, avemu creatu un CEN trà duie regioni Ali : cn-shenzhen и us-est-1 (puntu più vicinu à noi-est4). In Ali us-est-1 hà risuscitatu una altra macchina virtuale in modu chì ci hè una più parisi.

Hè risultatu cusì:

I risultati di a prova di u navigatore sò quì sottu:

dicisioni
Uptime
Mediu
75 percentile
95 percentile

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

U rendiment hè un pocu megliu cà IPSEC. Ma attraversu IPSEC pudete scaricamentu potenziale à una velocità di 100 Mbit/s, è attraversu CEN solu à una velocità di 5 Mbit/s è più.

Sembra un hibridu, nò? Unisce a velocità IPSEC è a stabilità CEN.

Questu hè ciò chì avemu fattu, permettendu u trafficu attraversu l'IPSEC è u CEN in casu di fallimentu di u tunnel IPSEC. U uptime hè diventatu assai più altu, ma a velocità di carica di u situ lascia sempre assai à desiderate. Allora aghju tracciatu tutti i circuiti chì avemu digià utilizatu è pruvatu, è decisu di pruvà à aghjunghje un pocu più GCP à questu circuitu, vale à dì. cappucciu.

cappucciu

cappucciu Is Global Load Balancer (o Google Cloud Load Balancer). Hà un vantaghju impurtante per noi: in u cuntestu di una CDN hà anycast IP, chì permette di indirizzà u trafficu à u centru di dati più vicinu à u cliente, perchè u trafficu entra rapidamente in a reta veloce di Google è menu passa per l'Internet "regular".

Senza pensà duie volte, avemu risuscitatu HTTP/HTTPS LB Avemu installatu e nostre macchine virtuali cù sottofiltru in GCP è cum'è backend.

Ci era parechji schemi:

Aduprate Cloudflare China Network, ma sta volta Origin deve specificà globale IP GLB.
Terminate i clienti à cn-shenzhen, è da quì proxy u trafficu direttamente à cappucciu.
Andate direttamente da a Cina à cappucciu.
Terminate i clienti à cn-shenzhen, da quì proxy à asia-est1 via IPSEC (in noi-est4 via CEN), da quì vai à GLB (calmu, ci sarà una foto è una spiegazione sottu)

Avemu pruvatu tutte queste opzioni è parechji più hibridi:

Cloudflare + GLB

Stu schema ùn ci cunvene per via di uptime è errori DNS. Ma a prova hè stata realizata prima chì u bug hè stata riparata da u latu CF, forse hè megliu avà (in ogni modu, questu ùn esclude micca i timeout HTTP).

Ali + GLB

Stu schema ùn ci cunvene ancu in termini di uptime, postu chì GLB spessu cascà fora di l'upstream per l'impossibilità di cunnette in un tempu accettabile o timeout, perchè per un servitore in Cina, l'indirizzu GLB ferma fora, è dunque daretu à u firewall cinese. A magia ùn hè micca accaduta.

GLB solu

Una opzione simile à a precedente, solu ùn hà micca utilizatu servitori in Cina stessu: u trafficu andò direttamente à GLB (i registri DNS sò stati cambiati). In cunsiquenza, i risultati ùn eranu micca soddisfacenti, postu chì i clienti ordinali chinesi chì utilizanu i servizii di i fornituri d'Internet ordinali anu una situazione assai peggiu cù passà u firewall chì Ali Cloud.

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

Quì avemu decisu di utilizà u megliu di tutte e soluzioni:

stabilità è SLA garantitu da CEN
alta velocità da IPSEC
A reta "veloce" di Google è u so anycast.

U schema s'assumiglia à questu: u trafficu di l'utilizatori hè terminatu nantu à a macchina virtuale in ch-shenzhen. Nginx upstreams sò cunfigurati quì, alcuni di quali puntanu à i servitori IP privati situati à l'altra estremità di u tunnel IPSEC, è certi upstreams puntanu à l'indirizzi privati di i servitori à l'altra parte di u CEN. IPSEC cunfiguratu à a regione asia-est1 in GCP (era a regione più vicinu à a Cina à u mumentu chì a suluzione hè stata creata. GCP hà avà ancu una presenza in Hong Kong). CEN - à a regione noi-est1 in Ali Cloud.

Allora u trafficu da e duie estremità hè stata diretta anycast IP GLB, chì hè, à u puntu più vicinu di prisenza di Google, è andò attraversu e so rete à a regione noi-est4 in GCP, in quale ci sò stati macchine virtuali di rimpiazzamentu (cù subfiltru in nginx).

Questa suluzione hibrida, cum'è l'aspittavamu, hà apprufittatu di i benefici di ogni tecnulugia. In generale, u trafficu passa per IPSEC veloce, ma se i prublemi cumincianu, avemu rapidamente è per uni pochi di minuti cacciate questi servitori fora di l'upstream è mandà u trafficu solu per CEN finu à chì u tunnel si stabilizza.

Implementendu a 4a suluzione da a lista sopra, avemu ottinutu ciò chì vuliamu è ciò chì l'affari ci dumandava à quellu puntu in u tempu.

I risultati di teste di u navigatore per a nova suluzione paragunata à i precedenti:

dicisioni
Uptime
Mediu
75 percentile
95 percentile

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

Tuttu hè bonu in a suluzione chì avemu implementatu, ma ùn ci hè micca CDN chì puderia accelerà u trafficu à u livellu regiunale è ancu di cità. In teoria, questu deve accelerà u situ per l'utilizatori finali utilizendu i canali di cumunicazione veloce di u fornitore CDN. È avemu pensatu à tuttu u tempu. È avà, hè ghjuntu u tempu per a prossima iterazione di u prugettu: ricerca è teste di i fornitori di CDN in Cina.

È vi dicu di questu in a prossima parte finale :)

Source: www.habr.com