Как Мы Прорвали Великий Китайский Файрвол (Часть 2)

Привет! С вами снова Никита, системный инженер компании СЭМраш .

И этой статьей я продолжаю рассказ о том, как мы придумали обходное решение.

Китайский брандмауэр для нашего сервиса semrush.com. В предыдущая часть Я сказал:

• какие проблемы возникают после принятия решения «Надо заставить наш сервис работать в Китае»
• Какие проблемы есть у китайского Интернета?
• зачем вам лицензия ICP?
• как и почему мы решили протестировать наши тестовые стенды с помощью Catchpoint
• каков был результат нашего первого решения на базе Cloudflare China Network
• Как мы нашли ошибку в Cloudflare DNS

И начнем, или, вернее, продолжим, с Алибаба Облако .

Алибаба Облако

Хорошо, что у них есть возможность регистрации для иностранных пользователей, и что большая часть сайта переведена на английский язык (для Китая это роскошь).

В этом облаке можно работать со многими регионами мира, материковым Китаем, а также Океанской Азией (Гонконг, Тайвань и др.

).

IPSEC

Поскольку наш тестовый сайт находился в Google Cloud, нам нужно было «связать» Alibaba Cloud с GCP, поэтому мы открыли список локаций, в которых присутствует Google. На тот момент у них еще не было собственного дата-центра в Гонконге.

Ближайшим регионом оказался Азия-Восток1 (Тайвань).

Али оказался ближайшим к Тайваню регионом материкового Китая Китай-Шэньчжэнь (Шэньчжэнь).

Используя терраформировать описал и поднял всю инфраструктуру на GCP и Али.

Туннель со скоростью 100 Мбит/с между облаками поднялся практически мгновенно.

На стороне Шэньчжэня и Тайваня было поднято проксирование виртуальных машин.

В Шэньчжэне пользовательский трафик терминируется, проксируется через туннель на Тайвань и оттуда идет напрямую на внешний IP нашего сервиса в США-Восток (Восточное побережье США).

Пинг между виртуальными машинами через туннель 24 мс , что не так уж и плохо.

В то же время мы разместили тестовую площадку в Облачный DNS Алибаба .

После делегирования зоны NS Ali время разрешения уменьшилось с 470 мс до 50 мс .

До этого зона также была на Cloudlfare. Параллельно тоннелю Азия-Восток1 построил еще один туннель из Шэньчжэня прямо в США-Восток4 .

Там они создали больше прокси-виртуальных машин и начали тестировать оба решения, маршрутизируя тестовый трафик с помощью файлов cookie или DNS. Схематически испытательный стенд представлен на следующем рисунке:



Задержка для туннелей оказалась следующей: Али, Шэньчжэнь <--> GCP Азия-Восток1 — 24 мс Али, Шэньчжэнь <--> GCP США-Восток4 — 200 мс Тесты браузера Catchpoint показали отличное улучшение.

Сравните результаты испытаний для двух решений:

Через us-east4 результаты были хуже, да и ошибок было больше, поэтому результаты приводить не буду.

По результатам этого испытания двух туннелей, один из которых заканчивается в ближайшем к Китаю регионе, а другой в конечном пункте назначения, стало ясно, что важно «выйти» из-под китайского файрвола как можно быстрее.

возможно, а затем использовать быстрые сети (провайдеры CDN, облачные провайдеры и т. д.).

Не нужно пытаться преодолеть брандмауэр и одним махом добраться до пункта назначения.

Это не самый быстрый способ.

В целом результаты неплохие, однако у semrush.com медиана 8,8, а 75-процентиль 9,4 (по тому же тесту).

И прежде чем двигаться дальше, хотелось бы сделать небольшое лирическое отступление.

Лирическое отступление

Ответ возвращается по тому же пути, но домен указан во всех JS-скриптах, HTML-страницах и других элементах веб-страницы.

semrush.com для дополнительных ресурсов, которые должны быть загружены при отображении страницы.

То есть клиент разрешает «основную» А-запись www.semrushchina.c n и заходит в быстрый туннель, быстро получает ответ — HTML-страницу, на которой написано:

• скачать такой-то js с sso.semrush.com,
• Получите файлы CSS с cdn.semrush.com,
• а также сделать несколько фотографий с сайта dab.semrush.com
• и так далее.

Но предыдущий тест показывает результаты, когда на странице нет ресурсов.

semrush.com , только semrushchina.cn , а *.

semrushchina.cn преобразуется в адрес виртуальной машины в Шэньчжэне, чтобы затем попасть в туннель.

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

Мы сделали это без единой правки кода на стороне продукта.

Подфильтр

Нам нужен был PoC (Подтверждение концепции), что наши решения для проникновения в брандмауэры действительно работают хорошо.

Для этого вам необходимо максимально обернуть весь трафик сайта в это решение.

И мы подали заявку подфильтр в нгинксе.

Подфильтр — довольно простой модуль в nginx, позволяющий заменить одну строку в теле ответа на другую.

Итак, мы изменили все вхождения semrush.com на semrushchina.cn во всех ответах.

И… это не сработало, потому что мы получили сжатый контент с бэкендов, поэтому подфильтр не нашел нужную строку.

Пришлось добавить в nginx еще один локальный сервер, который распаковывал ответ и передавал его следующему локальному серверу, который уже был занят заменой строки, ее сжатием и отправкой на следующий прокси-сервер в цепочке.

В результате где клиент получит .

semrush.com , он получил .

semrushina.cn и послушно выполнил наше решение.

Однако недостаточно просто сменить домен в одну сторону, поскольку бэкенды по-прежнему ожидают semrush.com в последующих запросах от клиента.

Соответственно, на том же сервере, где делается односторонняя замена, с помощью простого регулярного выражения получаем поддомен из запроса, а затем делаем proxy_pass с переменной $хост , выставленный в $subdomain.semrush.com .

Это может показаться запутанным, но это работает. И это работает хорошо.

Для отдельных доменов, которым требуется разная логика, просто создайте свои собственные серверные блоки и выполните отдельную конфигурацию.

Ниже приведены сокращенные конфиги nginx для наглядности и демонстрации данной схемы.

Следующая конфигурация обрабатывает все запросы из Китая в .

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

   

semrush.com; location / { resolver 8.8.8.8 ipv6=off; gunzip on; proxy_pass https://$host ; proxy_set_header Accept-Encoding gzip; } }

Повторюсь, это обрезанные конфиги.

Как это.

Это может выглядеть сложно, но это на словах.

На самом деле все проще пареной репы :)

Конец отступления

Но затем туннели начали рушиться.

Несколько раз в день по несколько минут. Немного, но нас это не устроило.

Так как оба туннеля терминировались на стороне Али на одном роутере, мы решили, что возможно это региональная проблема и нужно поднять резервный регион.

Они подобрали это.

Туннели в разное время начинали давать сбои, но у нас аварийное переключение на восходящем уровне в nginx работало нормально.

Но потом примерно в одно и то же время начали падать туннели :) И 502 и 504 начались заново.

Время безотказной работы стало ухудшаться, поэтому мы начали работать над вариантом с Алибаба ЦЕН (Облачная корпоративная сеть).

CEN

И самое главное: на этом канале довольно строгий Соглашение об уровне обслуживания .

Он очень стабилен как по скорости, так и по времени безотказной работы.

Но все не так просто:

• ОЧЕНЬ сложно получить, если вы не являетесь гражданом Китая или юридическим лицом,
• Платить нужно за каждый мегабит емкости канала.

В Али США-Восток-1 поднял еще одну виртуальную машину, чтобы была еще одна прыгать .

Получилось вот так:



Результаты теста браузера приведены ниже:

Звучит как гибрид, да? Сочетайте скорость IPSEC и стабильность CEN. Именно это мы и сделали, разрешив трафик как через IPSEC, так и через CEN в случае сбоя туннеля IPSEC. Uptime стал намного выше, но скорость загрузки сайта по-прежнему оставляет желать лучшего.

Затем я нарисовал все схемы, которые мы уже использовали и тестировали, и решил попробовать добавить в эту схему еще немного GCP, а именно ГЛБ .

ГЛБ

Для нас это имеет важное преимущество: в контексте CDN оно имеет произвольный IP-адрес , что позволяет направлять трафик в ближайший к клиенту дата-центр, чтобы трафик быстрее попадал в быструю сеть Google и меньше проходил через «обычный» Интернет. Недолго думая, мы подняли HTTP/HTTPS LB Мы установили наши виртуальные машины с подфильтром в GCP и в качестве бэкэнда.

Было несколько схем:

• Использовать Сеть Cloudflare в Китае , но на этот раз Origin должен указать глобальный IP ГЛБ .

• Завершение клиентов в Китай-Шэньчжэнь и оттуда проксировать трафик напрямую на ГЛБ .

• Отправляйтесь прямо из Китая в ГЛБ .

• Завершение клиентов в Китай-Шэньчжэнь , оттуда прокси на Азия-Восток1 через IPSEC (в США-Восток4 через CEN), оттуда переходим в GLB (спокойно, ниже будет картинка и пояснение)

• Cloudflare + GLB

• Али + ГЛБ

Волшебства не произошло.

• только GLB

Соответственно, результаты оказались неудовлетворительными, поскольку у обычных китайских клиентов, пользующихся услугами обычных интернет-провайдеров, ситуация с прохождением межсетевого экрана гораздо хуже, чем у Ali Cloud.

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

• стабильность и гарантированное SLA от CEN
• высокая скорость от IPSEC
• «Быстрая» сеть Google и ее Anycast.

Там настраиваются апстримы Nginx, некоторые из которых указывают на частные IP-серверы, расположенные на другом конце туннеля IPSEC, а некоторые апстримы указывают на частные адреса серверов на другой стороне CEN. IPSEC настроен для региона Азия-Восток1 в GCP (на момент создания решения это был ближайший к Китаю регион.

Теперь GCP также присутствует в Гонконге).

CEN - в регион США-Восток1 в Али Клауд. Затем трафик с обоих концов был направлен на произвольный IP-адрес GLB , то есть до ближайшей точки присутствия Google, и прошел через его сети в регион США-Восток4 в GCP, в котором были замены виртуальных машин (с подфильтром в nginx).

Это гибридное решение, как мы и ожидали, воспользовалось преимуществами каждой технологии.

В целом трафик проходит через быстрый IPSEC, но если начинаются проблемы, мы быстро и на несколько минут выкидываем эти сервера из апстрима и отправляем трафик только через CEN, пока туннель не стабилизируется.

Внедрив 4-е решение из списка выше, мы добились того, чего хотели и чего требовал от нас бизнес на тот момент. Результаты браузерного тестирования нового решения в сравнении с предыдущими:

CDN

Теоретически это должно ускорить работу сайта для конечных пользователей за счет использования быстрых каналов связи провайдера CDN. И мы постоянно об этом думали.

И вот пришло время следующей итерации проекта: поиска и тестирования CDN-провайдеров в Китае.

И об этом я расскажу в следующей, заключительной части :)

Все части

• Достаточно Ли Надежен Недорогой Планшетный Компьютер?

  19 Oct, 24

• Шварценеггер Отрицает, Что Потребители Знают Об Их Украденных Данных

  19 Oct, 24

• Наматрасник Luna Превратит Обычную Кровать В «Умную»

  19 Oct, 24

• Проблема С Использованием Runas На Серверах

  19 Oct, 24

• Синдром Самозванца И Выгорание

  19 Oct, 24

• Составление Договора На Дизайн-Студию, Часть 1

  19 Oct, 24

• Как Звали Доктора Ватсона?

  19 Oct, 24

• 5 Слайдов, Которые Опытные Докладчики Игнорируют

  19 Oct, 24

• 37Signals Запускает Онлайн-Планировщик

  19 Oct, 24

• Обновлены Данные О Популярности Cms-Систем, Систем Аналитики И Онлайн-Консультантов В Рунете За 2 Квартал.

  19 Oct, 24