🥇Hvordan vi brød gennem Den Store Kinesiske Firewall (del 1)

Hej alle sammen!

Mødt! Nikita her – systemingeniør fra virksomheden SEMrush. I dag vil jeg fortælle om, hvordan vi stod over for opgaven med at sikre stabilitet i vores service semrush.com i Kina, og hvilke udfordringer vi stødte på undervejs (taget vores datacenter beliggenhed på Østkysten af USA i betragtning).

Dette vil blive en stor historie, opdelt i flere artikler. Jeg vil fortælle om, hvordan det hele foregik for os: fra en service, der slet ikke fungerede fra Kina, til serviceydelser på niveau med den amerikanske version for amerikanerne. Jeg lover, det bliver interessant og nyttigt. Så lad os komme i gang.

Kinas internetproblemer

Selv den, der er mest fremmed for netværksadministration, har hørt om Den Store Kinesiske Brandmur. Uuh, det lyder sejt, ikke? Men hvad er det, og hvordan fungerer det i virkeligheden – det er et ret komplekst spørgsmål. Der findes mange artikler om dette på internettet, men fra et teknisk synspunkt er apparatet bag denne brandmur ikke beskrevet noget sted. Hvilket, ikke overraskende, giver mening. Jeg må indrømme, at efter et års arbejde kan jeg ikke præcist sige, hvordan det fungerer, men jeg kan dele nogle observationer og praktiske konklusioner. Lad os starte med rygterne om denne brandmur.

Der er mange rygter om denne brandmur. Lad os samle de vigtigste og mest interessante af dem i én liste:

Google, Facebook, Twitter og andre lignende tjenester er blokeret og fungerer ikke i Kina.
Al trafik, der går UD af Kina og TIL Kina, analyseres og begrænses via maskinlæring (i tilfælde af mistænkelig trafik), hvilket forsinker den (trafik), der passerer over grænsen, betydeligt.
Kinesiske efterretningstjenester kan bryde enhver krypteret trafik, der passerer gennem deres brandmur.
VPN-tunneler og IPSEC-tunneler er ustabile, falder og bliver konstant blokeret.
Jo simplere krypteringen er, jo simplere er adgangskoden, der bruges til autentificering/kryptering af trafikken, jo hurtigere passerer den kinesiske brandmur.

Her er, hvad vi har fundet ud af om disse rygter:

Google, Facebook, Twitter og andre lignende tjenester er faktisk blokerede (din KO), men mange tekniske domæner fra Google, for eksempel, er ikke blokerede og fungerer (det samme gælder gstatic.com). Derfor: det er ikke klogt at blindt fjerne alle Google- og andre ressourcer, der synes at være blokerede.
Al trafik, der krydser grænsen, tilføjer virkelig en betydelig forsinkelse til sin tid. Se på to resultater. Én hjemmeside, én side, simpel GET curlfra. Den første måling er fra Kina (den skønne by Shenzhen). Den anden måling er udenfor fra Hongkong (har suverænitet, og der er ikke nogen firewall mellem den og verden). Afstanden mellem byerne er ca. 30-40 km i fugleflugt.

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

Bemærk venligst time_connect. Og generelt ser du resultatet: firewallen tilføjer 4 ekstra sekunder, hvilket er forfærdeligt lang tid.

VPN og IPSEC tunneler falder ofte ud. Det vil jeg fortælle mere om senere. VPN-servere, der bruges af brugere, bliver over tid blokeret (som regel inden for en dag efter brugens start).
Der er en opfattelse, som kommer fra folk, der bor i Kina, om at jo simplere krypteringen af trafikken er, jo hurtigere passerer den grænsen, fordi det er let at forstå, at der ikke er noget ulovligt i den. Og ligeledes får "ren" trafik mere båndbredde og hastighed, mens "beskidt" trafik, hvor der ikke er noget, der kan analyseres, får en langsommere passage. Som eksempel vil jeg nævne curl til ifconfig.co over HTTPS og 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

Forskellen på 5 sekunder i den samlede downloads tid for 13 bytes. Når man kører testen flere gange, bemærker man, at GET-anmodninger på HTTP generelt afsluttes på omtrent den samme tid hver gang, mens HTTPS-svarene nogle gange tager 3, 5, 10 og endda 17 sekunder. Der opstår nogle gange SSL-fejl:

Ukendt SSL-protokolfejl i forbindelsen til ifconfig.co:443.

Så hvad har vi:

Problemerne forårsaget af den kinesiske firewall, som beskrevet ovenfor.
Ping til eksterne ressourcer og inde i tunneler forsvinder periodisk.
Latency mellem to punkter ændrer sig konstant, og ofte er den helt uforudsigelig. Når man forbinder forskellige byer/regioner, forventer man, at latency baseret på geografisk placering skal være lavere, men man får ofte det stik modsatte.
Internettet og kommunikationskanalerne arbejder nogle gange hurtigt, nogle gange langsomt. Der er en lille afhængighed af tid på dagen og ugen, men ikke altid.
DNS-forespørgsler til den eksterne verden fra Kina overskrider nogle gange den tilladte timeout.

Billedet ser ganske "fremragende" ud.

Datacenteret, som jeg allerede har nævnt, er i Østasien, og hele SEMrush består af dusinvis af sammenkoblede produkter, backend-systemer, frontend-systemer, databaser, og det hele er i datacenteret og i skyen. Som systemadministratorer har vi fået til opgave hurtigt at begynde at arbejde i Kina med minimalt af vores ressourcer.

Vi skulle besvare et vigtigt spørgsmål: Kan vi finde en løsning med lidt indsats for at håndtere alle problemerne relateret til det kinesiske internet og firewall på netværks-/cloud-/serverniveau?

Vi begyndte med at få ICP-licensen.

ICP-licens

For at kunne hoste din service inden for Kina (Mainland China) og udføre tests, skal man først have en ICP-licens til domænet.

Hvis din hjemmesides brugertrafik termineres i fastlandet Kina, og hvis din domæne ikke har en ICP-licens, vil din trafik blive blokeret hos udbyderen/hosten. Det er interessant, at ICP-licensen inkluderer en specifik udbyder, hvad enten det er Cloudflare eller Alibaba Cloud. Derfor, hvis du har fået en ICP-licens til Cloudflare og hostet din hjemmeside hos dem, vil du ikke kunne "sømløst" flytte til Alibaba Cloud senere. Det vil være nødvendigt at tilføje endnu en hosting til denne licens.

Efter at have modtaget en ICP-licens til domænet, kunne vi tænke på og implementere specifikke tekniske idéer og løsninger.

Test af løsninger

Men før vi direkte opretter staging-muligheder, drejer knapper, optimerer hjemmesideens funktion og hastighed, skal vi vælge et værktøj til at teste det, så vi kan se, hvilke af vores handlinger der forbedrer eller omvendt forringer hjemmesidefunktionaliteten.

Vores testværktøj skulle opfylde to hovedkrav:

det skal have mulighed for at køre tests fra Kina,
det skal have browser-tests.

Så vi fandt Catchpoint! De har fremragende dækning med testpunkter over hele verden. I Kina kan tests også køres gennem dette værktøj fra et stort antal provinser. I hver af dem flere forskellige udbydere + mulighed for at lave Backbone-tests (noget der ligner en virtuel maskine i datacenteret) og Lastmile-tests (maksimalt tæt på brugerforholdene, aka arbejdsstation). Den sidste type tests er dyrere.

Efter at have indgået en årlig kontrakt (mindre kan ikke lade sig gøre), begyndte vi at lære værktøjet at kende. Ærligt talt, vi var positivt overraskede over dets funktionalitet. Man kan køre:

DNS-tests,
Web-tests (browser, simpel GET/POST, emulering af mobilklient osv.),
Transaktionskontroller (f.eks. login),
API-tests,
Ping, traceroute, NTP osv.

Man kan ikke nævne alt. Og det vigtigste er, at hver test kan tilpasses ganske godt ved at tilføje en række overskrifter og andre parametre. Resultatet giver en enorm mængde information, der fuldt ud beskriver din test. Hvis vi taler om det mest interessante for os (browser tests), inkluderer resultatet:

Connect, Wait, Load, SSL, DNS tid,
TTFB, TTLB, Dokument færdig, Render tid, DOM load,
Respons (noget der ligner Time To First Byte), Webpage Respons (noget der ligner Time To Last Byte),
Enhver percentil, Gennemsnit, Median tid
Og så videre.

Disse målinger hjælper os med at se ændringer og forstå, om tingene er blevet bedre. Vi har primært set på Response, Webpage Response, Median, 75 og 95 Percentiles.

Et vigtigt spørgsmål, der har været i luften fra starten: Kan man stole på Catchpoint?? Отражает ли этот инструмент реальную скорость загрузки сайта в Китае из разных городов или же это просто какой-то тест в вакууме, не имеющий ничего общего с real user experience?
Det er et stort problem, fordi det i Rusland næsten er umuligt at få pålidelige oplysninger om, hvordan en hjemmeside fungerer fra Kina. Ved at lave en socks-proxy gennem en virtuel maskine får man lastingstiden til hjemmesiden over et par minutter, hvilket er uacceptabelt til tests, så den eneste mulighed for manuel testning er at bruge curl og simple GET-kommandoer fra konsollen med tidsmålinger. Dette hjælper, da denne test godt afspejler hastigheden af netværksløsningen, og hvis der er browser tests, er det endnu bedre.

Senere rejste vi selv til Kina og bekræftede, at Catchpoint kan man stole på, det afspejler ret præcist de faktiske hastighedsdata.

Cloudflare China Network

Da vi med succes bruger Cloudflare til hoveddomænet semrush.com, besluttede vi at prøve deres funktion kaldet China Network. Denne mulighed aktiveres kun for Enterprise-websteder på en separat anmodning og til en separat betaling. Den er også kun tilgængelig for websteder, der har en passende ICP-licens, hvor Cloudflare er angivet som udbyder. Når den er aktiveret, bliver "kinesisk CDN" fra Cloudflare tilgængeligt for webstedet — trafik fra kinesiske regioner ledes til nærmeste PoP (Points of Presence) CF, og derfra leveres det videre gennem deres netværk eller netværk fra udbydere/partnere til origin.

Skemaet for dette testopstilling er vist nedenfor.

For os er det en fantastisk mulighed. Det betyder, at det andet domæne også vil være bag CF, hvilket ikke øger antallet af løsninger, der bruges i virksomheden, og heller ikke komplicerer infrastrukturen nævneværdigt.

Vi har kørt browser tests, og her er resultatet:

De røde romber er testfejl. Fejlene nederst er DNS fejl (resolve timeout). Fejlene øverst er timeouts.

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

Medianen, efter at belastningen fra reCaptcha (en Google-tjeneste, der er blokeret i Kina), faldt fra 28 til 18 sek. Men det er stadig uacceptable tal, når man tager i betragtning, at den samme test for semrush.com (fra USA) gav mindre end 10 sekunder for 95% af brugerne (fra USA) på den samme side (statisk + dynamisk).

I hver test kan man gå ind og se Waterfall og andere mere detaljerede parametre. Vi begyndte at undersøge årsagerne til fejlene, og hvis det er mere eller mindre klart med timeoutene: internettet i Kina "samler sig og skiller sig igen", hvilket gør forbindelseshastigheden og indlæsningen af ressourcer fra udlandet ustabil og varierende, så blev DNS-fejlene os en stor overraskelse. Vi opdagede, at PoP hos Cloudflare faktisk findes i Kina, webadressen resolvedes til en anycast IP, men der bruges amerikanske DNS-servere, hvilket tvinger DNS-forespørgsler til at passere grænsen, og derfor fejler de nogle gange.

Ved at præcisere dette spørgsmål til CF fandt vi ud af, at de ikke har deres egne DNS-servere i Kina, og hvornår de får det — er stadig ukendt.

Derfor besluttede vi kun at teste DNS fra Cloudflare og ændrede Cloudflare's driftsmekanisme for vores website til "Kun DNS". Det er en tilstand, hvor Cloudflare ikke proxyer trafikken gennem sig selv, hvilket betyder, at de ikke tilbyder DDoS-beskyttelse, CDN og andre funktioner, og fungerer som en almindelig DNS-server.

Denne opsætning er skematisk præsenteret i den følgende illustration. Illustrationen tager højde for den nye viden om, at Cloudflare's DNS-servere ligger bag en firewall.

I Catchpoint kørte vi enkle GET-tests (ikke browser-baserede), som viste mange fejl. Årsagen til dem var de samme DNS-fejl.

Vi begyndte at debugge disse fejl med hjælp fra dig og opdagede, at ved den første forespørgsel bliver adressen korrekt bestemt, men ved gentagne forespørgsler får vi hver gang SERVFAIL og not found. Hvordan kan det pludselig ske?

root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn har adresse 220.170.186.192
Host semrushchina.cn ikke fundet: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn har adresse 220.170.186.192
Host semrushchina.cn ikke fundet: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn har adresse 220.170.186.192
Host semrushchina.cn ikke fundet: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn har adresse 220.170.186.192
Host semrushchina.cn ikke fundet: 2(SERVFAIL)

Ved direkte forespørgsel til Cloudflare's NS-servere er der ingen sådanne fejl:

root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Bruger domæneserver:
Navn: ray.ns.cloudflare.com.
Adresse: 173.245.59.138#53
Alias:

semrushchina.cn har adresse 220.170.186.192
semrushchina.cn har adresse 220.170.186.192
Bruger domæneserver:
Navn: ray.ns.cloudflare.com.
Adresse: 173.245.59.138#53
Alias:

semrushchina.cn har adresse 220.170.186.192
semrushchina.cn har adresse 220.170.186.192

Så problemet ligger hos den "lokale" DNS-server eller udbyderens server.
Yderligere undersøgelser viste, at SERVFAIL vi får på resolutionen AAAA-poster.

Det viste sig, at når der blev foretaget en forespørgsel hos Cloudflare AAAA-post, som ikke eksisterer på domænet, Cloudflare svarede A-post, som er en fejl og ikke overholder RFC. Dette gjorde, at den lokale resolver (x.x.x.x) ikke brød sig om det og svarede SERVFAIL. I loggen nedenfor kan denne adfærd tydeligt ses:

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
;; globale indstillinger: +cmd
;; Fik svar:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; flags: qr rd ra; QUERY: 1, SVAR: 0, AUTORITET: 0, YDERLIGERE: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; SPØRGSMÅL SECTION:
;semrushchina.cn. IN AAAA

;; Spørgetid: 334 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; HVORNÅR: Tue Aug 14 23:38:50 CST 2018
;; MSG STØRRELSE 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.
;; globale indstillinger: +cmd
;; Fik svar:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; flags: qr aa rd; QUERY: 1, SVAR: 1, AUTORITET: 0, YDERLIGERE: 1
;; ADVARSEL: rekursion anmodet, men ikke tilgængelig

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; SPØRGSMÅL SECTION:
;semrushchina.cn. IN AAAA

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

;; Spørgetid: 185 msec
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; HVORNÅR: Tue Aug 14 23:43:03 CST 2018
;; MSG STØRRELSE rcvd: 60

Vi sendte en bug-rapport til Cloudflare, og de rettede det efter noget tid. Det viste sig at være interessant: lige nu er der stadig ikke støtte for IPv6 i Kina, så Cloudflare kunne ikke returnere sin IPv6-adresse i svaret på anmodningen AAAA-poster. I sidste ende blev det løst, så for Kina begyndte Cloudflare at svare NODATA på sådanne anmodninger.

Så, DNS-fejlene i Catchpoint-testene faldt dramatisk, men ikke helt. Timeouts forsvandt heller ikke:

Og vi begyndte at lede efter en anden løsning.

I næste del vil jeg fortælle, hvordan vi testede det kinesiske sky Alibaba Cloud, og hvordan vi med lidt 'magi' fra Nginx hurtigt kunne skabe PoC (Proof of Concept) løsninger, og hvordan vi skabte Multi-Cloud-løsninger, hvoraf en i sidste ende hjalp meget med at forbedre serviceydelsen fra Kina.

Hold dig opdateret!