ProHoster > Blogg > Administration > Hur vi bröt igenom den Stora Kinesiska BrandvÀggen (del 2)

Hur vi bröt igenom den Stora Kinesiska BrandvÀggen (del 2)

Hej!

Det Ă€r Ă„terigen Nikita – systemingenjör frĂ„n företaget SEMrush. I denna artikel fortsĂ€tter jag berĂ€ttelsen om hur vi kom fram till en lösning för att kringgĂ„ Kinas brandvĂ€gg för vĂ„r tjĂ€nst semrush.com.

I den föregÄende delen Jag berÀttade:

  • vilka problem som uppstĂ„r efter att beslutet har tagits "Vi behöver fĂ„ vĂ„r tjĂ€nst att fungera i Kina"
  • vilka problem det finns med det kinesiska internet
  • varför en ICP-licens behövs
  • hur och varför vi beslutade oss för att testa vĂ„ra teststand med hjĂ€lp av Catchpoint
  • vilket resultat vĂ„r första lösning baserad pĂ„ Cloudflare China Network gav
  • hur vi hittade en bugg i Cloudflares DNS

Denna del Àr den mest intressanta, enligt mig, dÄ den fokuserar pÄ konkreta tekniska implementationer. Och vi börjar, eller snarare fortsÀtter, med Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud – en ganska stor molnleverantör som har alla tjĂ€nster för att rĂ€ttvist kunna kalla sig en cloud provider. Det Ă€r bra att de tillĂ„ter utlĂ€ndska anvĂ€ndare att registrera sig, och att en stor del av deras webbplats Ă€r översatt till engelska (för Kina Ă€r det en lyx). I detta moln kan man arbeta i mĂ„nga delar av vĂ€rlden, det kinesiska fastlandet samt Oceaniska Asien (Hongkong, Taiwan osv.).

IPSEC

Vi började med geografi. Eftersom vÄr testwebbplats fanns pÄ Google Cloud behövde vi "ansluta" Alibaba Cloud med GCP, sÄ vi öppnade listan över platser dÀr Google Àr nÀrvarande. Vid den tiden hade de fortfarande inte nÄgot datacenter i Hongkong.
Den nÀrmaste regionen visade sig vara asia-east1 (Taiwan). Den mest nÀrliggande regionen för Alibaba pÄ kinesiska fastlandet till Taiwan visade sig vara cn-shenzhen (Shenzhen).

Med hjĂ€lp av terraform beskrev och stĂ€llde vi upp hela infrastrukturen i GCP och Alibaba. Tunneln pĂ„ 100 Mbit/s mellan molnen upprĂ€ttades nĂ€stan omedelbart. PĂ„ Shenzhen-sidan och Taiwan upprĂ€ttades proxyvirtuella maskiner. AnvĂ€ndartrafiken i Shenzhen termineras, proxieras genom tunneln till Taiwan, och dĂ€rifrĂ„n gĂ„r den direkt till den externa IP-adressen för vĂ„r tjĂ€nst i us-east (Östkusten i USA). Ping mellan de virtuella maskinerna över tunneln 24 ms, vilket inte Ă€r sĂ„ illa.

Samtidigt placerade vi testzonen i Alibaba Cloud DNS. Efter att ha delegerat zonen till NS Ali, minskade upplösningstiden frÄn 470 ms till 50 ms. Innan detta var zonen ocksÄ pÄ Cloudflare.

Parallellt med tunneln till asia-east1 vi har byggt ytterligare en tunnel frÄn Shenzhen direkt till us-east4. DÀr har vi skapat fler proxy-VM:ar och började mÀta bÄda lösningarna genom att dirigera testtrafik med hjÀlp av cookies eller DNS. Den schematiska testuppstÀllningen beskrivs i följande bild:

Latency för tunnlarna var följande:
Ali cn-shenzhen GCP asia-east1 — 24ms
Ali cn-shenzhen GCP us-east4 — 200ms

WebblÀsartester frÄn Catchpoint rapporterade om en fantastisk förbÀttring av prestanda.

JÀmför testresultaten för de tvÄ lösningarna:

Lösning
TillgÀnglighet
Median
75 Percentil
95 Percentil

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Detta Àr data frÄn lösningen som anvÀnder en IPSEC-tunnel genom asia-east1. Genom us-east4 var resultaten sÀmre och det fanns fler fel, sÄ jag kommer inte att redovisa resultaten.

UtifrÄn resultaten av detta test av de tvÄ tunnlarna, dÀr den ena termineras i den nÀrmaste regionen till Kina och den andra i slutdestinationen, blev det tydligt att det Àr viktigt att sÄ snabbt som möjligt "emergiera" frÄn den kinesiska brandvÀggen, och sedan anvÀnda snabba nÀtverk (CDN-leverantörer, molnleverantörer etc.). Man bör inte försöka ta sig förbi brandvÀggen pÄ en gÄng för att nÄ destinationen. Det Àr inte den snabbaste vÀgen.

Överlag Ă€r resultaten bra, men semrush.com har en median pĂ„ 8.8s och 75 Percentil pĂ„ 9.4s (i samma test).
Och innan jag gÄr vidare, vill jag göra en liten litterÀr avstickare.

En lyrisk avstickare

Efter att anvÀndaren kommer in pÄ sidan www.semrushchina.cn, som resolveras via "snabba" kinesiska DNS-servrar, gÄr HTTP-förfrÄgan genom vÄr snabba lösning. Svaret ÄtervÀnder pÄ samma vÀg, men i alla JS-skript, HTML-sidor och andra element av webbsidan anges domÀnen semrush.com för ytterligare resurser som ska laddas vid sidan av. Det vill sÀga att klienten resolverar "huvud" A-postenwww.semrushchina.c

  • n och gĂ„r in i den snabba tunneln, fĂ„r snabbt svar — en HTML-sida dĂ€r det stĂ„r:
  • ladda ner den hĂ€r js frĂ„n sso.semrush.com,
  • hĂ€mta CSS-filer frĂ„n cdn.semrush.com,
  • och hĂ€mta bilder frĂ„n dab.semrush.com

och sÄ vidare.

WebblÀsaren börjar gÄ ut pÄ det "externa" internet för dessa resurser, och passerar varje gÄng genom den tidskrÀvande brandvÀggen. semrush.comMen i det föregÄende testet presenteras resultaten nÀr sidan inte har nÄgra resurser , endastsemrushchina.cn, som resolvers till adressen för en virtuell maskin i Shenzhen, för att sedan gÄ in i tunneln.

Endast pÄ detta sÀtt, genom att maximera all möjlig trafik genom vÄr lösning för snabb genomgÄng av den kinesiska brandvÀggen, kan acceptabla hastigheter och tillgÀnglighetsvÀrden pÄ webbplatsen, samt Àrliga resultat av lösningstester, uppnÄs.
Vi gjorde detta utan en enda kodÀndring pÄ produktteamens sida.

Subfilter

Lösningen föddes praktiskt taget direkt efter att detta problem uppstod. Vi behövde PoC (Proof of Concept), för att vÄra lösningar för brandvÀggspassering verkligen fungerar bra. För detta behövde vi maximera all webbplatstrafik i denna lösning. Och vi tillÀmpade subfilter i nginx.

Subfilter — det Ă€r en ganska enkel modul i nginx som lĂ„ter oss byta ut en strĂ€ng i svaret mot en annan strĂ€ng. SĂ„ vi bytte ut alla förekomster semrush.com till , endast i alla svar.

Och... det fungerade inte, eftersom vi fick komprimerat innehÄll frÄn backend, vilket gjorde att subfilter inte kunde hitta den nödvÀndiga strÀngen. Vi var tvungna att lÀgga till ytterligare en lokal server i nginx, som dekomprimerade svaret och skickade det till nÀsta lokala server som hanterade strÀngbytet, komprimeringen och levererade det till nÀsta proxyserver i kedjan.

Som en följd av detta, dÀr klienten skulle fÄ .semrush.com, fick han .semrushchina.cn och gick lydigt igenom vÄr lösning.

Men det rÀcker inte bara att byta domÀn Ät ett hÄll, eftersom backend fortfarande vÀntar pÄ semrush.com i de efterföljande förfrÄgningarna frÄn klienten. Följaktligen, pÄ samma server dÀr bytet görs Ät ett hÄll, anvÀnder vi ett enkelt reguljÀrt uttryck för att hÀmta undermappen frÄn förfrÄgan, och sedan gör vi proxy_pass med variabeln $host, instÀlld pÄ $subdomain.semrush.com. Det kan verka förvirrat, men det fungerar. Och det fungerar bra. För specifika domÀner som krÀver en annan logik skapas helt enkelt egna serverblock och en separat konfiguration görs. Nedan visas förkortade nginx-konfigurationer för tydlighet och demonstration av detta schema.

NÀsta konfiguration hanterar alla förfrÄgningar frÄn Kina pÄ .semrushchina.cn:

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

Den hÀr konfigurationen proxar till localhost till port 83, dÀr nÀsta konfiguration invÀntar:

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

Jag upprepar, detta Àr avklippta konfigurationer.

UngefĂ€r sĂ„. Det kan verka komplicerat, men det Ă€r bara verbalt. I verkligheten Ă€r allt enklare Ă€n skrĂ€ddarsydda klĂ€der 🙂

Slut pÄ den lyriska avstickaren

Vi var lyckliga ett tag, eftersom myten om fallande IPSEC-tunnlar inte bekrÀftades. Men sedan började tunnlarna falla. Flera gÄnger om dagen i nÄgra minuter. Lite, men vi var inte nöjda. Eftersom bÄda tunnlarna terminerades pÄ Ali-sidan pÄ en router, beslutade vi att det kanske var ett regionalt problem och att vi behövde aktivera backupregionen.

Vi aktiverade den. Tunnlarna började falla vid olika tillfĂ€llen, men failovern fungerade utmĂ€rkt pĂ„ upstream-nivĂ„ i nginx. Men sedan började tunnlarna falla ungefĂ€r samtidigt 🙂 Och 502 och 504 började igen. Uptime blev sĂ€mre, sĂ„ vi började utreda alternativet med Alibaba CEN (Cloud Enterprise Network).

CEN

CEN Àr anslutningen mellan tvÄ VPC:er frÄn olika regioner inom Alibaba Cloud, vilket innebÀr att du kan koppla samman privata nÀtverk i vilken region som helst i molnet. Och det viktigaste av allt: denna kanal har en ganska strikt SLA. Den Àr mycket stabil bÄde nÀr det gÀller hastighet och uptime. Men det Àr aldrig sÄ enkelt:

  • det Ă€r MYCKET svĂ„rt att fĂ„, om du inte Ă€r kinesisk medborgare eller juridisk person,
  • du mĂ„ste betala för varje megabit bandbredd.

Genom att fÄ möjlighet att koppla ihop Fastlandskina och Utomlands, skapade vi en CEN mellan tvÄ Ali-regioner: cn-shenzhen och us-east-1 (den nÀrmaste punkten till us-east4). I Ali us-east-1 aktiverade vi en annan virtuell maskin för att fÄ ytterligare en hop.

Det blev sÄ hÀr:

Resultaten frÄn webblÀsartesterna nedan:

Lösning
TillgÀnglighet
Median
75 Percentil
95 Percentil

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Resultaten Àr nÄgot bÀttre Àn för IPSEC. Men genom IPSEC kan du potentiellt ladda ner med hastigheter pÄ 100 Mbit/s, medan CEN bara klarar 5 Mbit/s och Àr dyrare.

Det Àr inte svÄrt att se en hybrid, eller hur? Att förena hastigheten hos IPSEC med stabiliteten hos CEN.

SÄ vi gjorde det, och lÀt trafiken gÄ bÄde via IPSEC och CEN i hÀndelse av att IPSEC-tunneln faller. Uptime blev mycket högre, men laddningstiden för webbplatsen lÀmnade fortfarande mycket att önska. DÄ ritade jag upp alla scheman som vi redan hade anvÀnt och testat, och beslutade att försöka lÀgga till lite mer GCP, nÀmligen GLB.

GLB

GLB — detta Ă€r Global Load Balancer (eller Google Cloud Load Balancer). Den har en viktig fördel för oss: i CDN-sammanhang har den anycast IP, vilket gör att trafiken kan ruttas till det datacenter som ligger nĂ€rmast kunden, vilket gör att trafiken snabbare nĂ„r Googles snabba nĂ€t och mindre gĂ„r genom den "vanliga" internettrafiken.

Utan att tveka lyfte vi HTTP/HTTPS LB i GCP och satte vÄra virtuella maskiner med subfilter som backend.

Det fanns flera scheman:

  • AnvĂ€nd Cloudflare China Network, men den hĂ€r gĂ„ngen angav vi den globala IP GLB.
  • Att terminera kunder i cn-shenzhen, och dĂ€rifrĂ„n proxya trafiken direkt till GLB.
  • GĂ„ direkt frĂ„n Kina till GLB.
  • Att terminera kunder i cn-shenzhen, dĂ€rifrĂ„n proxya till asia-east1 via IPSEC (genom us-east4 via CEN), dĂ€rifrĂ„n gĂ„ till GLB (inga bekymmer, det kommer att finnas en bild och förklaring neranför)

Vi testade alla dessa alternativ och nÄgra fler hybridvarianter:

  • Cloudflare + GLB

Detta schema uppfyllde inte vÄra krav pÄ uptime och DNS-fel. Men testet genomfördes innan CF-fel rÀttades, sÄ det kan ha blivit bÀttre nu (men det utesluter inte HTTP-tidsgrÀnser).

  • Ali + GLB

Detta schema uppfyllde inte heller vÄra uptime-krav, eftersom GLB ofta föll ur upstreamen pÄ grund av att det inte gick att ansluta inom rimlig tid eller tidsgrÀnser, eftersom GLB-adressen för servern inom Kina fortfarande Àr utanför, vilket innebÀr att den Àr bakom den kinesiska brandvÀggen. Ingen magi skedde.

  • GLB only

Ett alternativ som liknar det föregÄende, men dÀr inga servrar anvÀndes i Kina sjÀlvt: trafiken gick direkt till GLB (vi Àndrade DNS-poster). DÀrmed uppfylldes inte resultaten, eftersom vanliga kinesiska kunder som anvÀnder vanliga internetleverantörer har mycket vÀrre förhÄllanden för att passera brandvÀggen Àn Ali Cloud.

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

HÀr beslutade vi att anvÀnda det bÀsta frÄn alla lösningar:

  • stabilitet och garanti SLA frĂ„n CEN
  • hög hastighet frĂ„n IPSEC
  • "snabbt" Googles nĂ€tverk och dess anycast.

Schematiskt ser det ungefĂ€r ut sĂ„ hĂ€r: anvĂ€ndartrafik termineras pĂ„ en virtuell maskin i ch-shenzhen. Det finns upstreams för nginx, varav en del refererar till privata IP-servrar som ligger pĂ„ andra sidan IPSEC-tunneln, och en del upstreams refererar till privata adresser för servrar pĂ„ andra sidan CEN. IPSEC konfigurerades till regionen asia-east1 i GCP (det var den nĂ€rmaste regionen till Kina vid tidpunkten för lösningens skapande. Nu har GCP Ă€ven nĂ€rvaro i Hongkong). CEN — till regionen us-east1 i Ali Cloud.

DÀrefter dirigerades trafik frÄn bÄda Àndarna till anycast IP GLB, det vill sÀga till den nÀrmaste Google-nÀrvaron, och sÀndes via deras nÀtverk till regionen us-east4 i GCP, dÀr de ersÀttande virtuella maskinerna fanns (med subfilter i nginx).

Denna hybridlösning, som vi förvÀntade oss, gjorde att vi kunde dra nytta av fördelarna med varje teknik. Sammanfattningsvis gÄr trafiken genom snabb IPSEC, men om problem uppstÄr tar vi snabbt och tillfÀlligt bort dessa servrar frÄn upstreams och skickar trafik endast via CEN, tills tunneln stabiliseras.

Genom att implementera den fjÀrde lösningen frÄn listan ovan uppnÄdde vi det vi ville och vad affÀren krÀvde av oss vid den tiden.

Resultaten av webblÀsartester för den nya lösningen jÀmfört med tidigare:

Lösning
TillgÀnglighet
Median
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

I den implementerade lösningen fungerar allt bra, bara att det inte finns nÄgon CDN som kan accelerera trafiken pÄ regions- och till och med stadsnivÄ. I teorin borde detta snabba upp webbplatsens prestanda för slutanvÀndare genom att anvÀnda snabba kommunikationskanaler frÄn CDN-leverantören. Och vi har alltid tÀnkt pÄ detta. Nu har tiden kommit för nÀsta iteration av projektet: att söka och testa CDN-leverantörer i Kina.

Och detta kommer jag att berĂ€tta om i nĂ€sta och avslutande del 🙂

KĂ€lla: habr.com

Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar đŸ”„ Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar | ProHoster