Speaker A
Всем привет. С вами я, Assassin VPN. И сегодня я хочу рассказать, как же починить обход белых списков через CDN Яндекс. Последние буквально несколько дней все начали массово писать примерно одно и то же: перестал пинговаться Яндекс CDN. Вчера ещё работал, VPN не подключается, пингов нет. Что произошло? И если вы сталкивались или пользовались схемой обхода белых списков через Яндекс, то, скорее всего, вы уже столкнулись с этой проблемой. Примерно с 28 сентября начали появляться сообщения о том, что CDN перестала нормально работать. По наблюдениям, сначала обкатывали на Йоте, Мегафоне и Билайне, но затем на следующий день похожие симптомы начали появляться и на других операторах. Причём выглядит это довольно странно. Пинг не проходит, но при этом сам ресурс не заблокирован и сайт CDN открывается. Так работал старый обход. Когда у оператора включался режим белых списков, обычный VPN не может достучаться до своего сервера. Причина довольно простая. У вас есть условный VPN-сервер где-нибудь в датацентре. Телефон пытается подключиться прямо к его IP, но этот IP не находится среди разрешённых ресурсов. Соединение просто не проходит. Поэтому появилась схема с использованием CDN. Вместо того, чтобы выглядеть для сетей как прямое подключение с каким-то VPN-сервером, клиент обращается к разрешённому CDN. Для пользователя это всё ещё туннель, но снаружи соединение идёт через инфраструктуру CDN. И долгое время такая схема действительно позволяла работать там, где включают белые списки и глушат мобильный интернет. Самое интересное здесь начинается с того, как именно клиент передаёт исходящие данные. У транспорта XHTTP есть несколько вариантов того, куда положить аплинк данные. Один из них — body. Если совсем упрощённо, клиент делает HTTP-запрос и кладёт передаваемые данные внутрь тела этого запроса. То есть примерно заголовки запроса, потом body, а внутри body уже находится часть трафика нашего туннеля. И именно этот вариант долгое время показывал себя очень хорошо. Можно было передавать достаточно большие куски данных, поэтому сохранялась нормальная скорость и всё работало. Можно было загружать фотографии, файлы, отправлять большие сообщения, то есть пользоваться интернетом практически нормально. Поэтому у многих в конфигах использовался именно data placement body. И вот здесь мы подходим к тому, что случилось сейчас. С 28 сентября Яндекс ввёл ограничение на старый вариант с передачей uplink через body на все свои сервера CDN, поэтому туннель перестал проходить также, как и раньше. То есть сам CDN может оставаться доступным, соединение с ним устанавливается, но конкретно тот способ, которым через него передавались данные, просто намертво умер. И получается очень неприятная ситуация. Внешне кажется, что весь способ обхода умер. Хотя на самом деле проблема больше не в CDN целиком и даже не в самом XHTTP. Проблема именно в способе передачи аплинк. И первое очевидное решение: хорошо, body больше нормально не проходит, давайте переключимся на header. И да, header действительно может работать, но здесь появляется вторая проблема. Когда вы просто берёте старый конфиг и переключаете Applink Data Placement Body на Applink Data Placement Header, может показаться, что проблема решена. VPN снова подключается, некоторые сайты открываются, пакеты начинают ходить. Но запускаем замеритель скорости, пробуем зайти в браузер YouTube, пытаемся что-то загрузить и видим совершенно смешную отдачу, потому что HTTP-заголовки изначально вообще не предназначены для передачи огромных байтданных. Это не какой-нибудь бесконечный контейнер. У них есть ограничения по размеру, есть ограничения на стороне клиента, есть ограничения на промежуточной инфраструктуре, есть ограничения непосредственно на сервере. Поэтому, если оставить стандартные параметры, XHTTP будет вынужден передавать uplink очень маленькими кусками. Представьте, что раньше вы переносили воду ведром, а теперь вам оставили только стакан. Воду переносить всё ещё можно, но чтобы передать тот же объём, вам потребуется огромное количество отдельных проходов. Примерно такая же проблема возникает здесь. Именно поэтому получается очень характерный эффект. Скачка вроде есть, а отдача почти отсутствует. И без нормального оплота современный интернет работает гораздо хуже, чем кажется. Даже когда вы просто смотрите YouTube, клиент постоянно что-то отправляет обратно. Запросы подтверждения, служебные домены, переключения качества, новые сегменты. Если исходящий канал начинает захлёбываться, сервер может ощущаться вообще как полностью нерабочий. Поэтому простое переключение body на header — это только половина решения. Assassin VPN. Если вы сейчас смотрите и всё думаете: я просто хотел пользоваться интернетом, почему я вообще должен разбираться в body, header, CDN, чанках, размерах HTTP-запросов? Именно поэтому у меня есть Assassin VPN. Мы развиваем его в том числе под подобные сценарии с ограничением мобильного интернета. Обходит всё, включая белые списки. Работают все нейросети, включая G Mini. Цена всего 200 рублей на пять устройств. Доступ либо прямо на сайте, либо через Telegram-бота. Ну а мы возвращаемся дальше. Если ваш старый конфиг работал через Applink Data Placement Body, но сейчас соединение просто перестало передавать данные, первым делом переподключаем на Uplink Data Placement Header. Но на этом не заканчивается, потому что если оставить header со стандартными значениями, как я уже говорил, скорее всего, получите очень маленькую отдачу. Поэтому меняем четыре параметра. Uplink chunk size. Мы увеличиваем размер части данных, которые клиент пытается передать за один раз. SK Max each post bytes. Увеличиваем максимальный объём данных, который будет отправляться за один запрос. Server Max Header bytes. Это особенно важно при использовании header, потому что теперь мы передвигаем данные непосредственно через HTTP-заголовки и должны разрешить серверу принимать заголовки большого размера. SK min po interval миллисекунд. Уменьшаем минимальный интервал между отправкой, то есть местной ситуации, когда мы пытаемся резать маленькими кусками, ещё и ждём между запросами. Данные начинают уходить значительно быстрее. Но есть ещё один важный момент. Веб-сервер. Если у вас перед X-Ray стоит Nginx, то просто поменять настройки XHTTP может оказаться недостаточным. Почему? Потому что теперь мы специально передаём достаточно большие объёмы через HTTP-заголовки, а у самого Nginx тоже есть ограничение на размер входящих заголовков. В блоке HTTP нужного сервера можно увеличить буферы заголовков. Например, client header buffer size, large client header buffer. Главный параметр здесь — large client header buffer. Он отвечает за большие HTTP-заголовки. То есть логика теперь такая. Клиент отправляет данные через header. Nginx должен этот header принять. Только после этого запрос доходит до X-Ray. И здесь аккуратней, не нужно бездумно ставить гигантские значения на несколько мегабайт. Нам нужно просто дать достаточно места для нашего хедера, а не полностью убрать ограничения. После этого переподключаем VPN и уже проверяем скорость. Сначала можно проверить обычный сайт, потом YouTube и обязательно смотрим именно отдачу, потому что в нашем случае это главный показатель того, что header действительно начал нормально передавать аплинк. Ну а на этом у меня всё. С вами был я, Assassin VPN. Всем спасибо за просмотр. Пока. M.
