Cum am spart Marele Firewall al Chinei (Partea 2)

Hi!

Nikita este din nou cu tine, un inginer de sisteme de la companie SEMrush. Și cu acest articol continui povestea despre cum am venit cu o soluție de soluție Firewall chinezesc pentru serviciul nostru semrush.com.

В partea anterioară Am spus:

• ce probleme apar după ce se ia decizia „Trebuie să ne facem serviciul să funcționeze în China”
• Ce probleme are internetul chinezesc?
• de ce aveți nevoie de o licență ICP?
• cum și de ce am decis să ne testăm paturile de testare cu Catchpoint
• care a fost rezultatul primei noastre soluții bazate pe Cloudflare China Network
• Cum am găsit o eroare în Cloudflare DNS

Această parte este cea mai interesantă, după părerea mea, pentru că se concentrează pe implementări tehnice specifice ale punerii în scenă. Și vom începe, sau mai bine zis să continuăm Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud este un furnizor de cloud destul de mare, care deține toate serviciile care îi permit să se numească sincer furnizor de cloud. Este bine că au posibilitatea de a se înregistra pentru utilizatorii străini și că majoritatea site-ului este tradus în engleză (pentru China este un lux). În acest nor, puteți lucra cu multe regiuni ale lumii, China continentală, precum și Asia Oceanică (Hong Kong, Taiwan etc.).

IPSEC

Am început cu geografia. Deoarece site-ul nostru de testare se afla pe Google Cloud, trebuia să „legăm” Alibaba Cloud cu GCP, așa că am deschis o listă de locații în care Google este prezent. În acel moment nu aveau încă propriul centru de date în Hong Kong.
Cea mai apropiată regiune s-a dovedit a fi asia-est1 (Taiwan). Ali s-a dovedit a fi cea mai apropiată regiune a Chinei continentale de Taiwan cn-shenzhen (Shenzhen).

Cu terraform a descris și a ridicat întreaga infrastructură în GCP și Ali. Un tunel de 100 Mbit/s între nori s-a ridicat aproape instantaneu. De partea Shenzhen și Taiwan, au fost ridicate mașinile virtuale de proxy. În Shenzhen, traficul utilizatorilor este terminat, trimis printr-un tunel către Taiwan și de acolo merge direct la IP-ul extern al serviciului nostru în noi-est (Coasta de Est a SUA). Ping între mașinile virtuale prin tunel 24ms, ceea ce nu este chiar atât de rău.

În același timp, am amplasat o zonă de testare Alibaba Cloud DNS. După delegarea zonei către NS Ali, timpul de rezoluție a scăzut de la 470 ms la 50 ms. Înainte de aceasta, zona era și pe Cloudlfare.

Paralel cu tunelul spre asia-est1 a ridicat un alt tunel de la Shenzhen direct la noi-est4. Acolo au creat mai multe mașini virtuale proxy și au început să testeze ambele soluții, direcționând traficul de testare folosind Cookie-uri sau DNS. Bancul de testare este descris schematic în următoarea figură:

Latența pentru tuneluri s-a dovedit a fi după cum urmează:
Ali cn-shenzhen <—> GCP asia-east1 — 24ms
Ali cn-shenzhen <—> GCP us-east4 — 200 ms

Testele browserului Catchpoint au raportat îmbunătățiri excelente.

Comparați rezultatele testelor pentru două soluții:

decizie
Uptime
Median
75 de procente
95 de procente

Cloudflare
86.6
Anii 18
Anii 30
Anii 60

IPsec
99.79
Anii 18
Anii 21
Anii 30

Acestea sunt date dintr-o soluție care utilizează un tunel IPSEC prin asia-est1. Prin us-east4 rezultatele au fost mai rele și au fost mai multe erori, așa că nu voi da rezultatele.

Pe baza rezultatelor acestui test a două tuneluri, dintre care unul se încheie în cea mai apropiată regiune de China, iar celălalt la destinația finală, a devenit clar că este important să „ieșim” ​​de sub firewall-ul chinez cât mai repede. posibil și apoi utilizați rețele rapide (furnizori CDN, furnizori de cloud etc.). Nu este nevoie să încercați să treceți prin firewall și să ajungeți la destinație dintr-o lovitură. Aceasta nu este cea mai rapidă cale.

În general, rezultatele nu sunt rele, totuși, semrush.com are o mediană de 8.8 s, iar 75 Percentila 9.4 s (la același test).
Și înainte de a trece mai departe, aș vrea să fac o scurtă digresiune lirică.

Retragerea lirică

După ce utilizatorul intră pe site www.semrushchina.cn, care se rezolvă prin servere DNS chinezești „rapide”, cererea HTTP trece prin soluția noastră rapidă. Răspunsul este returnat pe aceeași cale, dar domeniul este specificat în toate scripturile JS, paginile HTML și alte elemente ale paginii web semrush.com pentru resurse suplimentare care trebuie încărcate atunci când pagina este redată. Adică, clientul rezolvă înregistrarea A „principală”. www.semrushchina.cn și intră în tunelul rapid, primește rapid un răspuns - o pagină HTML care spune:

• descărcați astfel de js de pe sso.semrush.com,
• Obțineți fișierele CSS de pe cdn.semrush.com,
• și fă, de asemenea, câteva poze de pe dab.semrush.com
• și așa mai departe.

Browserul începe să meargă la Internetul „extern” pentru aceste resurse, trecând de fiecare dată printr-un firewall care consumă timp de răspuns.

Dar testul anterior arată rezultatele când nu există resurse pe pagină semrush.comnumai semrushchina.cn, iar *.semrushchina.cn se rezolvă la adresa mașinii virtuale din Shenzhen pentru a intra apoi în tunel.

Doar astfel, prin împingerea la maximum a întregului trafic posibil prin soluția dumneavoastră pentru trecerea rapidă a firewall-ului chinezesc, puteți obține viteze acceptabile și indicatori de disponibilitate a site-ului web, precum și rezultate oneste ale testelor soluției.
Am făcut acest lucru fără o singură modificare a codului din partea de produs a echipei.

Subfiltru

Soluția a luat naștere aproape imediat după ce această problemă a apărut. Ne-a trebuit PoC (Dovada conceptului) că soluțiile noastre de penetrare a firewallului funcționează foarte bine. Pentru a face acest lucru, trebuie să includeți tot traficul site-ului în această soluție cât mai mult posibil. Și am aplicat subfiltru în nginx.

Subfiltru este un modul destul de simplu în nginx care vă permite să schimbați o linie din corpul răspunsului cu o altă linie. Așa că am schimbat toate aparițiile semrush.com pe semrushchina.cn în toate răspunsurile.

Și... nu a funcționat pentru că am primit conținut comprimat de la backend-uri, așa că subfiltrul nu a găsit linia necesară. A trebuit să adaug un alt server local la nginx, care a decomprimat răspunsul și l-a transmis următorului server local, care era deja ocupat să înlocuiască șirul, să-l comprima și să-l trimită la următorul server proxy din lanț.

Ca urmare, unde ar primi clientul .semrush.com, el a primit .semrushchina.cn și am trecut cu ascultare prin decizia noastră.

Cu toate acestea, nu este suficient să schimbați domeniul într-un fel, deoarece backend-urile încă așteaptă semrush.com în cererile ulterioare din partea clientului. În consecință, pe același server unde se face înlocuirea unidirecțională, folosind o expresie regulată simplă obținem subdomeniul din cerere și apoi facem proxy_pass cu variabila $ gazdă, expus în $subdomain.semrush.com. Poate părea confuz, dar funcționează. Și funcționează bine. Pentru domeniile individuale care necesită o logică diferită, pur și simplu creați propriile blocuri de server și faceți o configurație separată. Mai jos sunt scurtate configurațiile nginx pentru claritate și demonstrație a acestei scheme.

Următoarea configurație procesează toate cererile din China către .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;
    }
}

Această configurare este proxy la localhost la portul 83, iar următoarea configurație așteaptă acolo:

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

Repet, acestea sunt configurații decupate.

Ca asta. Poate părea complicat, dar este în cuvinte. De fapt, totul este mai simplu decât napii aburiți :)

Sfârșitul digresiunii

O vreme ne-am bucurat pentru că mitul despre căderea tunelurilor IPSEC nu a fost confirmat. Dar apoi tunelurile au început să cadă. De câteva ori pe zi timp de câteva minute. Puțin, dar asta nu ne convine. Deoarece ambele tuneluri au fost terminate pe partea Ali pe același router, am decis că poate aceasta este o problemă regională și trebuie să creștem regiunea de rezervă.

L-au ridicat. Tunelurile au început să eșueze în momente diferite, dar failover-ul a funcționat bine pentru noi la nivelul amonte în nginx. Dar apoi tunelurile au început să cadă cam în același timp 🙂 Și au început din nou 502 și 504. Timpul de funcționare a început să se deterioreze, așa că am început să lucrăm la opțiunea cu Alibaba CEN (Cloud Enterprise Network).

CEN

CEN - aceasta este conectivitatea a două VPC-uri din diferite regiuni din Alibaba Cloud, adică puteți conecta rețele private din orice regiuni din cloud între ele. Și cel mai important: acest canal are un canal destul de strict SLA. Este foarte stabil atât ca viteză, cât și ca timp de funcționare. Dar niciodată nu este atât de simplu:

• este FOARTE dificil de obținut dacă nu sunteți cetățeni chinezi sau o entitate juridică,
• Trebuie să plătiți pentru fiecare megabit de lățime de bandă a canalului.

Având posibilitatea de a vă conecta China continentală и de peste mări, am creat un CEN între două regiuni Ali: cn-shenzhen и noi-est-1 (cel mai apropiat punct de noi-est4). În Ali noi-est-1 a ridicat o altă mașină virtuală, astfel încât să mai existe una hop.

A ieșit așa:

Rezultatele testului browserului sunt mai jos:

decizie
Uptime
Median
75 de procente
95 de procente

Cloudflare
86.6
Anii 18
Anii 30
Anii 60

IPsec
99.79
Anii 18
Anii 21
Anii 30

CEN
99.75
Anii 16
Anii 21
Anii 27

Performanța este puțin mai bună decât IPSEC. Dar prin IPSEC puteți descărca potențial la o viteză de 100 Mbit/s, iar prin CEN doar la o viteză de 5 Mbit/s și mai mult.

Sună a hibrid, nu? Combinați viteza IPSEC și stabilitatea CEN.

Aceasta este ceea ce am făcut, permițând traficul atât prin IPSEC, cât și prin CEN în cazul unei defecțiuni a tunelului IPSEC. Uptime a devenit mult mai mare, dar viteza de încărcare a site-ului lasă încă de dorit. Apoi am desenat toate circuitele pe care le-am folosit și testat deja și am decis să încerc să adaug puțin mai mult GCP la acest circuit, și anume capac.

capac

capac - E Global Load Balancer (sau Google Cloud Load Balancer). Are un avantaj important pentru noi: în contextul unui CDN îl are IP anycast, care vă permite să direcționați traficul către centrul de date cel mai apropiat de client, astfel încât traficul să ajungă rapid în rețeaua rapidă a Google și mai puțin să treacă prin internetul „obișnuit”.

Fără să ne gândim de două ori, am crescut HTTP/HTTPS LB Ne-am instalat mașinile virtuale cu subfiltru în GCP și ca backend.

Au existat mai multe scheme:

• Использовать Rețeaua Cloudflare China, dar de data aceasta Origin ar trebui să specifice global IP GLB.
• Terminați clienții la cn-shenzhen, iar de acolo proxy traficul direct către capac.
• Du-te direct din China în capac.
• Terminați clienții la cn-shenzhen, de acolo proxy la asia-est1 prin IPSEC (în noi-est4 prin CEN), de acolo mergi la GLB (calm, va fi o poza si explicatie mai jos)

Am testat toate aceste opțiuni și mai multe altele hibride:

• Cloudflare + GLB

Această schemă nu ne-a potrivit din cauza timpului de funcționare și a erorilor DNS. Dar testul a fost efectuat înainte ca eroarea să fie remediată pe partea CF, poate că este mai bine acum (cu toate acestea, acest lucru nu exclude timeout-urile HTTP).

• Ali + GLB

Această schemă nu ne convenea nici în ceea ce privește timpul de funcționare, deoarece GLB a căzut adesea din amonte din cauza imposibilității conectării într-un timp acceptabil sau timeout, deoarece pentru un server din China, adresa GLB rămâne în afara și, prin urmare, în spatele Firewall chinezesc. Magia nu s-a întâmplat.

• Numai GLB

O optiune asemanatoare celei anterioare, doar ca nu folosea servere chiar in China: traficul mergea direct catre GLB (s-au schimbat inregistrarile DNS). În consecință, rezultatele nu au fost satisfăcătoare, deoarece clienții chinezi obișnuiți care folosesc serviciile furnizorilor de internet obișnuiți au o situație mult mai proastă cu trecerea firewall-ului decât Ali Cloud.

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

Aici am decis să folosim cea mai bună dintre toate soluțiile:

• stabilitate și SLA garantat de la CEN
• viteză mare de la IPSEC
• Rețeaua „rapidă” Google și anycast-ul său.

Schema arată cam așa: traficul utilizatorului este terminat pe o mașină virtuală în ch-shenzhen. Acolo sunt configurate Nginx upstream, dintre care unele indică servere IP private situate la celălalt capăt al tunelului IPSEC, iar unele upstream indică adrese private ale serverelor de cealaltă parte a CEN. IPSEC configurat la regiune asia-est1 în GCP (era cea mai apropiată regiune de China în momentul în care a fost creată soluția. GCP are acum o prezență și în Hong Kong). CEN - la regiune noi-est1 în Ali Cloud.

Apoi traficul din ambele capete a fost direcționat către anycast IP GLB, adică până la cel mai apropiat punct de prezență al Google și a mers prin rețelele sale până în regiune noi-est4 în GCP, în care existau mașini virtuale de înlocuire (cu subfiltru în nginx).

Această soluție hibridă, așa cum ne așteptam, a profitat de avantajele fiecărei tehnologii. În general, traficul trece prin IPSEC rapid, dar dacă încep problemele, dăm rapid și pentru câteva minute aceste servere din amonte și trimitem trafic doar prin CEN până când tunelul se stabilizează.

Prin implementarea celei de-a patra soluții din lista de mai sus, am realizat ceea ce ne-am dorit și ceea ce ne-a cerut afacerea la acel moment.

Rezultatele testului de browser pentru noua soluție în comparație cu cele anterioare:

decizie
Uptime
Median
75 de procente
95 de procente

Cloudflare
86.6
Anii 18
Anii 30
Anii 60

IPsec
99.79
Anii 18
Anii 21
Anii 30

CEN
99.75
Anii 16
Anii 21
Anii 27

CEN/IPsec + GLB
99.79
Anii 13
Anii 16
Anii 25

CDN

Totul este bine în soluția pe care am implementat-o, dar nu există un CDN care ar putea accelera traficul la nivel regional și chiar de oraș. În teorie, acest lucru ar trebui să accelereze site-ul pentru utilizatorii finali prin utilizarea canalelor de comunicare rapide ale furnizorului CDN. Și ne gândim la asta tot timpul. Și acum, a sosit momentul pentru următoarea iterație a proiectului: căutarea și testarea furnizorilor de CDN în China.

Și vă voi spune despre asta în următoarea parte finală :)

Sursa: www.habr.com