🥇Как пробихме Великия Китайски Файервол (ч.1)

Здравейте на всички!

На линия е Никита — системен инженер от компанията SЕMrush. Днес ще ви разкажа как пред нас стоеше задачата да осигурим стабилността на нашия сервис semrush.com в Китай и с какви проблеми се сблъскахме по време на нейното изпълнение (имайки предвид местоположението на нашия дата център на източното крайбрежие на САЩ).

Това ще бъде дълга история, разделена на няколко статии. Ще ви разкажа как всичко това се случи при нас: от напълно нефункциониращ сервис в Китай до показатели за работата на сервиса на равнище равностойно на американската версия за американците. Обещавам, ще бъде интересно и полезно. И така, да започнем.

Проблеми на китайския интернет

Дори и най-далечният човек от спецификата на мрежовото администриране поне веднъж е чувал за Великата китайска стена на защитата. Ууу, звучи страхотно, нали? Но какво точно представлява, как всъщност работи — въпросът е доста сложен. В интернет можете да намерите много статии, посветени на това, но от техническа гледна точка устройството на тази стена не е описано никъде. Което, всъщност, не е изненадващо. Признавам веднага, след края на годината работа, няма да можем да кажем точно как работи, но мога да споделя моите наблюдения и практически изводи. И ще започнем с слуховете за тази стена.

Съществуват много слухове за тази стена. Нека съберем основните и най-интересни от тях в един списък:

Google, Facebook, Twitter и други подобни услуги са забранени и не работят в Китай.
Всеки трафик, който преминава ЗА пределите на Китай и В Китай, се анализира и ограничава с помощта на машинно обучение (в случай на подозрителен трафик), което значително забавя трафика, преминаващ през границата.
Китайските специални служби ще хакнат всеки криптиран трафик, който минава през тяхната стена.
VPN тунели, IPSEC тунели са нестабилни, падат и постоянно се блокират.
Колкото по-просто е криптирането, толкова по-проста е паролата, използвана за автентикация/криптиране на трафика, толкова по-бързо преминава през китайската стена.

Ето какво успяхме да установим относно тези слухове:

Google, Facebook, Twitter и други подобни услуги наистина са блокирани (вашето КО), но много технически домейни на Google, например, не са забранени и работят (като gstatic.com). Оттук следва изводът: не трябва безразсъдно да изтривате всички гугъл и други ресурси, които изглеждат блокирани.
Всяка линия на трафик, преминаваща границата, наистина добавя значителен закъснение в времето. Вижте два резултата. Един сайт, една страница, прост GET curl’ом. Първото измерване е от Китай (прекрасния град Шенжен). Второто измерване е отвън от Хонг Конг (има суверенитет, и между него и света няма фаервол). Разстоянието между градовете по права линия е около 30-40 км.

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

Обърнете внимание на time_connect. И като цяло, виждате резултата: фаерволът добавя 4 излишни секунди, което е ужасно дълго.

VPN и IPSEC тунели наистина често спират. Ще говоря за това по-късно и по-подробно. VPN сървърите, които ползват потребителите, с времето се блокират (обикновено в рамките на 24 часа след началото на употреба).
Съществува мнение, получено от хора, живеещи в Китай, че колкото по-просто е криптирането на трафика, толкова по-бързо преминава през границата, защото е лесно да се разбере, че в него няма нищо незаконно. И точно така "чист" трафик получава повече честотна лента и скорост на преминаване, а "мръсен" трафик, в който нищо не е ясно, получава обратно по-бавно преминаване. Като пример, ще дам curl до ifconfig.co по протокол HTTPS и 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

Разликата от 5 секунди в общото време за зареждане на 13 байта. Правейки този тест няколко пъти, може да се забележи, че GET на HTTP завършва приблизително за едно и също време всеки път, докато на HTTPS сайтът отговаря понякога за 3, 5, 10 и дори 17 секунди. Понякога се случват SSL грешки:

Неизвестна SSL протоколна грешка при свързване с ifconfig.co:443.

И така, какво имаме:

Проблемите, причинени от китайската защитна стена, описани по-горе.
Ping-овете до външни ресурси и вътре в тунелите понякога изчезват.
Забавянето между две точки постоянно се променя, а често е просто непредсказуемо. Свързвайки различни градове/райони, очакваш, че въз основа на географското положение на регионите, забавянето ще бъде по-малко, но получаваш точно обратната ситуация.
Интернет и комуникационните канали работят понякога бързо, понякога бавно. Има малка зависимост от времето на деня и дните от седмицата, но не винаги.
DNS-заявките към външния свят от Китай понякога надхвърлят допустимия таймаут.

Картината изглежда просто "отлична".

Дата центърът, както вече казах, е на изток в САЩ, а целият SEMrush се състои от десетки взаимосвързани продукти, бекенди, фронтенди, бази данни, и всичко това е в дата центъра и облаците. Пред нас, като екип от системни администратори, беше поставена задачата бързо да започнем работа в Китай с минимални усилия.

Трябваше да отговорим на важния въпрос: може ли да се справим с малко усилия и да разрешим всички проблеми, свързани с китайския интернет и защитната стена, на ниво мрежа/облаци/сървъри?

Започнахме с получаването на ICP-лицензия.

ICP-лицензия

За да имате възможност да хоствате услугата си в рамките на Китай (Mainland China) и да провеждате тестове, първо трябва да получите ICP-лицензия за домейна.

Ако трафикът на потребителите на вашия сайт се прекратява на територията на континентален Китай и ако домейнът ви няма лицензия ICP, трафикът ви ще бъде блокиран от доставчика/хостинга. Интересно е, че в лицензията ICP е записан конкретен доставчик, независимо дали е Cloudflare или Alibaba Cloud. Следователно, ако сте получили лицензия ICP за Cloudflare и сте хоствали сайта си при тях, впоследствие не можете безпрепятствено да преминете на Alibaba Cloud. Необходимо е да добавите нов хостинг в тази лицензия.

Получавайки лицензия ICP за домейна, успяхме да измислим и реализираме конкретни технически идеи и решения.

Тестване на решения

Но преди да започнем да създаваме варианти на стейджинг, да настройваме и оптимизираме работата на сайта и неговата скорост, трябва да изберем инструмент за тестване, за да видим кои наши действия подобряват или в противен случай влошават работата на сайта.

Нашият инструмент за тестване трябваше да отговаря на две основни изисквания:

той трябва да има възможност за стартиране на тестове от Китай,
той трябва да има браузерни тестове.

Така открихме Catchpoint! Те имат отлично покритие на точки за тестване по целия свят. В Китай чрез този инструмент могат да се стартират тестове и от 100500 провинции. Във всяка по няколко различни доставчици + възможност за правене на Backbone- тестове (нещо подобно на виртуална машина в дата център) и Lastmile- тестове (максимално приближени до условията на потребителите, т.е. работна станция). Последният тип тестове е по-скъп.

След сключване на годишен договор (по-малко не е възможно), започнахме да изучаваме инструмента. Признаваме, бяхме приятно изненадани от функционалността му. Може да стартирате:

DNS тестове,
Уеб тестове (браузерни, прост GET/POST, емоция на мобилен клиент и т.н.),
Транзакционни проверки (например, логин),
API тестове,
Ping, traceroute, NTP и т.н.

Всичко не може да се изброи. И най-важното, всеки тест може да бъде доста добре персонализиран, като добавите пакет заглавия и други параметри. В резултат се получава огромно количество информация, която напълно описва вашия тест. Ако говорим за най-интелигентното за нас (браузерни тестове), то резултатът включва:

Connect, Wait, Load, SSL, DNS време,
TTFB, TTLB, Document complete, Render time, DOM load,
Response (нещо близко до Time To First Byte), Webpage Response (нещо близко до Time To Last Byte),
Всеки percentile, Average, Median time
и т.н.

Следовательно, всички тези метрики ясно помагат да се виждат промените и да се разбере дали е станало по-добре. Основно гледахме на Response, Webpage Response, Median, 75 и 95 Percentiles.

Важно питане, което витае в пространството от самото начало: може ли да се вярва на Catchpoint? Отражает ли этот инструмент реальную скорость загрузки сайта в Китае из разных городов или же это просто какой-то тест в вакууме, не имеющий ничего общего с real user experience?
Това е голям проблем, защото е почти невъзможно да узнаеш как работи сайт от Китай, когато си в Русия. Когато правиш socks-прокси чрез виртуална машина, получаваш зареждане на сайта в продължение на няколко минути, което е неприемливо за тестове, затова единствената опция за ръчно тестване остава curl и прости GET команди от конзолата с измерване на времето. Това помага, защото този тест добре отразява скоростта на мрежовото решение, а ако има и браузърни тестове, е още по-добре.

По-късно сами отидохме в Китай и се уверихме, че можеш да се довериш на Catchpoint, той доста точно отразява реалните показатели на скоростта.

Cloudflare China Network

Тъй като за основния домейн semrush.com успешно използваме Cloudflare, решихме веднага да пробваме тяхната функция, наречена China Network. Тази опция се активира само за сайтове с Enterprise план след отделна заявка и за допълнително заплащане. Освен това, тя е налична само за сайтове с валидна ICP-лицензия, в която Cloudflare е посочен като доставчик. След активирането й, за сайта става достъпен “китайски CDN” от Cloudflare — трафик от китайските региони достига до най-близките PoP (Points of Presence) на CF, а след това през неговите мрежи или мрежите на доставчици/партньори се доставя до origin.

Схемата на този тестов стенд е представена по-долу.

За нас това е страхотен вариант. Получава се, че вторият домейн ще бъде също зад CF, което не увеличава броя на решенията, използвани в компанията, и практически не усложнява инфраструктурата.

Стартирахме браузърни тестове и ето какво се получи:

Червените ромбове — това са провали на тестовете. Провалите отдолу — DNS грешки (resolve timeout). Провалите отгоре — таймаути.

Uptime: 86.6
Медиана: 18s
75 Percentile: 29.3s
95 Percentile: 60s

Медицината, след като беше премахнато зареждането на reCaptcha (услуга на Google, блокирана в Китай), спадна от 28 до 18 сек. Но все пак това са ужасни показатели, ако вземем предвид, че същият тест за semrush.com (от САЩ) даваше по-малко от 10 секунди за 95% от потребителите (от САЩ) на същата страница (статично + динамично).

Във всеки тест можеш да влезеш и да видиш Waterfall и други по-подробни параметри. Започнахме да изследваме причините за грешките и ако за таймаутите всичко е по-очевидно: интернет в Китай "то се събира, то се разпръсва", поради което скоростта на свързване и зареждане на ресурси извън страната е нестабилна и неодинакова, то DNS-грешките много ни изненадаха. Установихме, че PoP в Cloudflare наистина се намират в Китай, адресът на сайта се резолвира в един anycast IP, но DNS-сървърите са американски, поради което DNS-запросите трябва да преминават през границата и затова понякога те пропадат.

След като уточнихме този въпрос с CF, се установи, че нямат свои DNS-сървъри в Китай, а кога ще имат — все още не се знае.

Затова решихме да тестваме само DNS на Cloudflare и сменихме механизма на работа на Cloudflare за нашия сайт на режим "Само DNS". Това е режим, при който Cloudflare не проксира трафика през себе си, а значи, не предоставя DDoS защита, CDN и други функции, а работи в режим на обикновен DNS-сървър.

Тази инсталация е схематично представена на следващата рисунка. На рисунката са взети предвид новите знания за това, че DNS-сървърите на Cloudflare са зад фаервола.

В Catchpoint стартирахме прости GET тестове (не браузърни), които показаха много пропуски. Причината за тях бяха същите тези DNS грешки.

Започнахме да дебъгваме тези грешки с помощта на dig и установихме, че при първото запитване адресът се определя правилно, а при повторно запитване получаваме всеки път SERVFAIL и не е намерен. Защо така?

root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)

При запитване на NS-сървърите на Cloudflare директно, такива грешки няма:

root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases: 

semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases: 

semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192

Следователно, проблемът е на страната на "локалния" DNS-сървър или на сървъра на доставчика.
По-нататъшното разследване показа, че SERVFAIL получаваме резолва AAAA-записи.

Оказа се, че при запитване към Cloudflare AAAAA-запис, който не съществува в домейна, Cloudflare отговори А-съобщение, което е грешка и не съответства на RFC. Поради което локалният резолвер (x.x.x.x) не беше доволен и отговори SERVFAIL. В долния лог това поведение е ясно видимо:

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
;; глобални опции: +cmd
;; Получен отговор:
;; ->>HEADER<<- opcode: QUERY, статус: SERVFAIL, id: 55467
;; флагове: qr rd ra; ЗАПИТВАНЕ: 1, ОТГОВОР: 0, АВТОРИТЕТ: 0, ДОПЪЛНИТЕЛЕН: 1

;; OPT PSEUDOSECTION:
; EDNS: версия: 0, флагове:; udp: 4096
;; СЕКЦИЯ ЗАПИТВАНЕ:
;semrushchina.cn.               IN      AAAA

;; Време за запитване: 334 мсек
;; СЪРВЪР: x.x.x.x#53(x.x.x.x)
;; КОГА: Вт, 14 Авг 23:38:50 CST 2018
;; РАЗМЕР НА СЪОБЩЕНИЕТО  получено: 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.
;; глобални опции: +cmd
;; Получен отговор:
;; ->>HEADER<<- opcode: QUERY, статус: NOERROR, id: 63944
;; флагове: qr aa rd; ЗАПИТВАНЕ: 1, ОТГОВОР: 1, АВТОРИТЕТ: 0, ДОПЪЛНИТЕЛЕН: 1
;; ВНИМАНИЕ: искането за рекурсия но не е налично

;; OPT PSEUDOSECTION:
; EDNS: версия: 0, флагове:; udp: 512
;; СЕКЦИЯ ЗАПИТВАНЕ:
;semrushchina.cn.               IN      AAAA

;; СЕКЦИЯ ОТГОВОР:
semrushchina.cn.        300     IN      A       220.170.186.192

;; Време за запитване: 185 мсек
;; СЪРВЪР: 173.245.58.105#53(173.245.58.105)
;; КОГА: Вт, 14 Авг 23:43:03 CST 2018
;; РАЗМЕР НА СЪОБЩЕНИЕТО  получено: 60

Изпратихме отчет за грешка до Cloudflare и те го поправиха след известно време. Оказа се интересно: към момента в Китай все още няма поддръжка на IPv6, така че Cloudflare не можеше да предостави своя IPv6 адрес в отговора на запитването AAAAA-записи. В крайна сметка всичко беше решено така, че за Китай Cloudflare започна да отговаря NODATA на такива запитвания.

Така че, грешките с DNS в тестовете Catchpoint рязко намаляха, но не напълно. Таймаутите също не изчезнаха:

И започнахме да търсим друго решение.

В следващата част ще разкажа как тествали китайското облако Alibaba Cloud, как с помощта на малко "магия" Nginx успяхме бързо да създадем PoC (Доказателство за концепция) решения, как създавахме Multi-Cloud решения, едно от които в крайна сметка много помогна за ускоряване на услугата от Китай.

Останете на линия!