Как пробихме Великата китайска защитна стена (част 2)

Привет!

Никита отново е с вас, системен инженер от компанията SEMrush. И с тази статия продължавам историята за това как измислихме заобиколно решение Китайска защитна стена за нашата услуга semrush.com.

В предишна част Казах:

• какви проблеми възникват след вземането на решението „Трябва да накараме нашата услуга да работи в Китай“
• Какви проблеми има китайският интернет?
• защо ви е необходим ICP лиценз?
• как и защо решихме да тестваме нашите тестове с Catchpoint
• какъв беше резултатът от първото ни решение, базирано на Cloudflare China Network
• Как открихме грешка в Cloudflare DNS

Тази част е най-интересна според мен, защото се фокусира върху конкретни технически изпълнения на постановката. И ще започнем или по-скоро ще продължим с Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud е доста голям облачен доставчик, който разполага с всички услуги, които му позволяват честно да се нарече облачен доставчик. Добре е, че имат възможност да се регистрират за чуждестранни потребители и че по-голямата част от сайта е преведена на английски (за Китай това е лукс). В този облак можете да работите с много региони на света, континентален Китай, както и океанска Азия (Хонконг, Тайван и др.).

IPsec

Започнахме с география. Тъй като нашият тестов сайт беше разположен в Google Cloud, трябваше да „свържем“ Alibaba Cloud с GCP, така че отворихме списък с местоположения, в които Google присъства. В този момент те все още нямаха собствен център за данни в Хонконг.
Най-близкият регион се оказа азия-изток1 (Тайван). Али се оказа най-близкият регион на континентален Китай до Тайван cn-Шенжен (Шенжен).

С тераформа описа и повдигна цялата инфраструктура в GCP и Ali. 100 Mbit/s тунел между облаците се издигна почти мигновено. От страна на Шенжен и Тайван бяха повдигнати прокси виртуални машини. В Шенжен потребителският трафик се прекратява, проксира през тунел до Тайван и оттам отива директно към външния IP на нашата услуга в нас-изток (Източното крайбрежие на САЩ). Пинг между виртуални машини чрез тунел 24ms, което не е толкова лошо.

В същото време поставихме тестова зона Alibaba Cloud DNS. След делегиране на зоната на NS Ali, времето за разделяне намаля от 470 ms на 50 мс. Преди това зоната също беше на Cloudlfare.

Успоредно на тунела до азия-изток1 издигна друг тунел от Шенжен директно до нас-изток4. Там те създадоха повече прокси виртуални машини и започнаха да тестват и двете решения, като маршрутизираха тестов трафик с помощта на бисквитки или DNS. Тестовият стенд е описан схематично на следната фигура:

Закъснението за тунели се оказа, както следва:
Ali cn-shenzhen <—> GCP asia-east1 — 24ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

Тестовете на браузъра Catchpoint отчитат отлично подобрение.

Сравнете резултатите от теста за две решения:

Решение
Uptime
Медиана
75 процентил
95 процентил

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Това са данни от решение, което използва IPSEC тунел чрез азия-изток1. Чрез us-east4 резултатите бяха по-лоши и имаше повече грешки, така че няма да давам резултатите.

Въз основа на резултатите от този тест на два тунела, единият от които завършва в най-близкия регион до Китай, а другият в крайната дестинация, стана ясно, че е важно да се „излезе“ изпод китайската защитна стена възможно най-бързо. възможно и след това използвайте бързи мрежи (доставчици на CDN, облачни доставчици и т.н.). Няма нужда да се опитвате да преминете през защитната стена и да стигнете до местоназначението си с един замах. Това не е най-бързият начин.

Като цяло резултатите не са лоши, но semrush.com има медиана от 8.8s и 75 процентила 9.4s (при същия тест).
И преди да продължа, бих искал да направя кратко лирично отклонение.

Лирично отклонение

След като потребителят влезе в сайта www.semrushchina.cn, който разрешава чрез „бързи“ китайски DNS сървъри, HTTP заявката преминава през нашето бързо решение. Отговорът се връща по същия път, но домейнът е посочен във всички JS скриптове, HTML страници и други елементи на уеб страницата semrush.com за допълнителни ресурси, които трябва да бъдат заредени, когато страницата се рендира. Тоест, клиентът разрешава „основния“ A-запис www.semrushchina.cn и отива в бързия тунел, бързо получава отговор - HTML страница, която гласи:

• изтеглете такъв и такъв js от sso.semrush.com,
• Вземете CSS файловете от cdn.semrush.com,
• и също така направете няколко снимки от dab.semrush.com
• и така нататък.

Браузърът започва да отива във „външния“ интернет за тези ресурси, като всеки път преминава през защитна стена, която изяжда времето за реакция.

Но предишният тест показва резултатите, когато на страницата няма ресурси semrush.comсамо semrushchina.cn, и *.semrushchina.cn разрешава адреса на виртуалната машина в Шенжен, за да влезе след това в тунела.

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

Подфилтър

Решението се роди почти веднага след появата на този проблем. Имахме нужда от PoC (Доказателство за концепцията), че нашите решения за проникване през защитна стена наистина работят добре. За да направите това, трябва да включите целия трафик на сайта в това решение колкото е възможно повече. И кандидатствахме подфилтър в nginx.

Подфилтър е доста прост модул в nginx, който ви позволява да промените един ред в тялото на отговора с друг ред. Така че променихме всички събития semrush.com на semrushchina.cn във всички отговори.

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

В резултат на това къде би получил клиентът .semrush.com, той получи .semrushchina.cn и послушно изпълни нашето решение.

Въпреки това не е достатъчно просто да промените домейна по един начин, тъй като бекендът все още очаква semrush.com при последващи заявки от клиента. Съответно, на същия сървър, където се извършва еднопосочното заместване, използвайки прост регулярен израз, ние получаваме поддомейна от заявката и след това правим proxy_pass с променлива $хост, изложен в $поддомейн.semrush.com. Може да изглежда объркващо, но работи. И работи добре. За отделни домейни, които изискват различна логика, просто създайте свои собствени сървърни блокове и направете отделна конфигурация. По-долу са съкратени конфигурации на nginx за яснота и демонстрация на тази схема.

Следната конфигурация обработва всички заявки от Китай до .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;
    }
}

Тази конфигурация е прокси към Localhost към порт 83 и там чака следната конфигурация:

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

Повтарям, това са изрязани конфигурации.

така. Може да изглежда сложно, но е на думи. Всъщност всичко е по-просто от задушена ряпа :)

Край на отклонението

Известно време бяхме щастливи, защото митът за падащите IPSEC тунели не се потвърди. Но тогава тунелите започнаха да падат. Няколко пъти на ден по няколко минути. Малко, но това не ни устройваше. Тъй като и двата тунела бяха прекратени от страната на Ali на един и същ рутер, решихме, че това може би е регионален проблем и трябва да увеличим резервния регион.

Вдигнаха го. Тунелите започнаха да се провалят по различно време, но преходът при срив работи добре за нас на ниво нагоре в nginx. Но след това тунелите започнаха да падат приблизително по едно и също време 🙂 И отново започнаха 502 и 504. Времето за работа започна да се влошава, така че започнахме да работим върху опцията с Alibaba CEN (Cloud Enterprise Network).

CEN

CEN - това е свързаността на два VPC от различни региони в облака на Alibaba, тоест можете да свързвате частни мрежи от всякакви региони в облака един с друг. И най-важното: този канал има доста строг SLA. Той е много стабилен както по отношение на скоростта, така и по време на работа. Но никога не е толкова просто:

• МНОГО е трудно да се получи, ако не сте китайски граждани или юридическо лице,
• Трябва да платите за всеки мегабит честотна лента на канала.

Имайки възможност за свързване Континентален Китай и в чужбина, създадохме CEN между два региона на Ali: cn-Шенжен и нас-изток-1 (най-близка точка до нас-изток4). В Али нас-изток-1 повдигна друга виртуална машина, така че да има още една хмел.

Оказа се така:

Резултатите от теста на браузъра са по-долу:

Решение
Uptime
Медиана
75 процентил
95 процентил

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Производителността е малко по-добра от IPSEC. Но чрез IPSEC можете потенциално да теглите със скорост от 100 Mbit/s, а чрез CEN само със скорост от 5 Mbit/s и повече.

Звучи като хибрид, нали? Комбинирайте IPSEC скорост и CEN стабилност.

Това е, което направихме, позволявайки трафик през IPSEC и CEN в случай на повреда на IPSEC тунела. Времето за работа е станало много по-високо, но скоростта на зареждане на сайта все още оставя много да се желае. След това начертах всички вериги, които вече бяхме използвали и тествали, и реших да опитам да добавя малко повече GCP към тази верига, а именно шапка с козирка.

шапка с козирка

шапка с козирка - Global Load Balancer (или Google Cloud Load Balancer). Има важно предимство за нас: в контекста на CDN има anycast IP, което ви позволява да насочвате трафика към центъра за данни, който е най-близо до клиента, така че трафикът бързо да попадне в бързата мрежа на Google и по-малко да минава през „обикновения“ интернет.

Без да мислим два пъти, вдигнахме HTTP/HTTPS LB Инсталирахме нашите виртуални машини с подфилтър в GCP и като бекенд.

Имаше няколко схеми:

• употреба Cloudflare China Network, но този път Origin трябва да посочи глобален IP GLB.
• Прекратете клиенти на cn-Шенжен, и оттам прокси трафика директно към шапка с козирка.
• Отидете направо от Китай до шапка с козирка.
• Прекратете клиенти на cn-Шенжен, оттам прокси към азия-изток1 чрез IPSEC (в нас-изток4 чрез CEN), оттам отидете на GLB (спокойно, по-долу ще има снимка и обяснение)

Тествахме всички тези опции и още няколко хибридни:

• Cloudflare + GLB

Тази схема не ни подхожда поради ъптайм и DNS грешки. Но тестът беше извършен преди грешката да бъде коригирана от страна на CF, може би сега е по-добре (това обаче не изключва изчакване на HTTP).

• Али + GLB

Тази схема също не ни подхождаше по отношение на времето за работа, тъй като GLB често падаше от upstream поради невъзможността за свързване в приемливо време или таймаут, тъй като за сървър в Китай GLB адресът остава извън и следователно зад Китайска защитна стена. Магията не се случи.

• Само GLB

Опция, подобна на предишната, само че не използваше сървъри в самия Китай: трафикът отиваше директно към GLB (DNS записите бяха променени). Съответно резултатите не бяха задоволителни, тъй като обикновените китайски клиенти, използващи услугите на обикновени интернет доставчици, имат много по-лоша ситуация с преминаването на защитната стена, отколкото Ali Cloud.

• Шенжен -> (CEN/IPSEC) -> Прокси -> GLB

Тук решихме да използваме най-доброто от всички решения:

• стабилност и гарантирано SLA от CEN
• висока скорост от IPSEC
• „Бързата“ мрежа на Google и нейното предаване.

Схемата изглежда така: потребителският трафик се прекъсва на виртуална машина в ч-шенджън. Nginx upstreams са конфигурирани там, някои от които сочат към частни IP сървъри, разположени в другия край на IPSEC тунела, а някои upstreams сочат към частни адреси на сървъри от другата страна на CEN. IPSEC е конфигуриран за регион азия-изток1 в GCP (беше най-близкият регион до Китай по времето, когато решението беше създадено. GCP вече има присъствие и в Хонг Конг). CEN - към региона нас-изток1 в Али Клауд.

След това трафикът от двата края беше насочен към anycast IP GLB, тоест до най-близката точка на присъствие на Google, и премина през мрежите му към региона нас-изток4 в GCP, в който имаше заместващи виртуални машини (с подфилтър в nginx).

Това хибридно решение, както очаквахме, се възползва от предимствата на всяка технология. По принцип трафикът преминава през бърз IPSEC, но ако започнат проблеми, ние бързо и за няколко минути изхвърляме тези сървъри от upstream и изпращаме трафик само през CEN, докато тунелът се стабилизира.

С внедряването на 4-то решение от горния списък постигнахме това, което искахме и това, което бизнесът изискваше от нас в този момент.

Резултати от теста на браузъра за новото решение в сравнение с предишните:

Решение
Uptime
Медиана
75 процентил
95 процентил

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

Всичко е добро в решението, което внедрихме, но няма CDN, който да ускори трафика на регионално и дори градско ниво. На теория това трябва да ускори сайта за крайните потребители чрез използване на бързите комуникационни канали на доставчика на CDN. И мислехме за това през цялото време. И сега дойде времето за следващата итерация на проекта: търсене и тестване на CDN доставчици в Китай.

И за това ще ви разкажа в следващата, последна част :)

Източник: www.habr.com