Обход БС через CDN

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

1 Serverless (Yandex Cloud Functions / Cloud Run-подобное).
Сам не раскапывал, только принцип понял, но основное ограничение в том что такие функции ограничены по времени жизни на сервере и не подходят ни для чего кроме обычных http запросов. Условный контэйнер поднялся, передал запрос, вернул ответ и умер.

2 CDN (Content Delivery Network).
Это как я понял довольно популярный способ обхода БС даже для больших VPNсервисов.
Друг тестировал у автора это статьи ( Обход белых списков с помощью CDN и XHTTP · frank-underwood64/whitelists_bypass · Discussion #1 · GitHub ) пару серверов с такой настройкой и они довольно успешно обходили БС.

Среди успешных сервисов был Beget.
Сейчас уже 2 сутки бьюсь с тем чтобы через него пустить трафик.
Когда создавал cdn ресурс источник указал правильно, сильно больше этого по мимо кэширования и прочей лабуды там настроек нет.
На vps стоит caddy которая проксирует весь трафик на локальный xray.
Создал отдельный инбаунд под cdn с ws транспортом, т.к. была инфа что beget режет xhttp трафик (до этого пробовал и с xhttp), но картина не меняется. Пинг в приложении на клиенте есть, 6-9 мс а интернета нет вообще.

Небольшое уточнение сразу, я не сетевик и не дэвопс, я просто ищу решение проблемы и адаптирую под себя всеми возможными способами. В том числе значительную часть ресерча и правок делает ии т.к. я не спец. У меня что-то не работает Фикшу сам, если не фиксится и в интернете ничего не могу найти понятного иду за разъяснениями к нейронке. В большинстве случаев прокатывало, но сейчас видимо нет. Я стараюсь понять всё что делаю, но опять таки это очень локальные знания по тому вопросу и проблеме которуюя сам решаю, масштабно с другой стороны я посмотреть на вопрос не могу.

Поэтому обращаюсь сюда за помощю.

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

Тесты

Условие: проверка бэкенда напрямую, минуя CDN (XHTTP-инбаунд).
Тест: curl -v https://***.***.ru/***/
Результат: :white_check_mark: HTTP 400 + via: 1.1 Caddy + x-padding — нормальный ответ XHTTP. Бэкенд жив.


Условие: проверка WS-инбаунда напрямую, минуя CDN.
Тест: curl -v https://***.***.ru/***/ (в т.ч. с заголовками WebSocket-апгрейда).
Результат: :white_check_mark: HTTP 400 + via: 1.1 Caddy. Caddy проксирует в Xray:30001, WS-инбаунд отвечает. Бэкенд жив.


Условие: запрос через CDN на секретный путь XHTTP.
Тест: curl -k https://***.begetcdn.cloud/***/ -H "Host: ***.***.ru"
Результат: :cross_mark: HTTP 403, server: nginx, x-cdn-edge-cache: HIT. Нет via: Caddy, нет x-padding — ответ отдал сам CDN-эдж, до origin не дошло.


Условие: запрос через CDN на WS-путь, с уникальным query для обхода кэша.
Тест: curl -k "https://***.begetcdn.cloud/***/?x=$(date +%s)" -H "Host: ***.***.ru"
Результат: :cross_mark: HTTP 403, server: nginx, x-cdn-edge-cache: HIT — на уникальном URL, где кэша быть не может. Т.е. HIT = отдаёт замороженную заглушку 403, origin не опрашивает.


Условие: запрос через CDN на корень / (там у Caddy file_server, простейший кейс).
Тест: curl -k "https://***.begetcdn.cloud/?x=$(date +%s)" -H "Host: ***.***.ru"
Результат: :cross_mark: HTTP 403 nginx, HIT. Даже корень не проксируется.


Условие: контрольный — несуществующий путь, без заголовка Host.
Тест: curl -k "https://***.begetcdn.cloud/anything123/?z=$(date +%s)"
Результат: :cross_mark: HTTP 403 nginx, HIT. CDN отдаёт 403 вообще на всё, независимо от пути и Host.


Условие: очистка кэша CDN в панели Beget.
Тест: кнопка Purge/Очистить кэш.
Результат: первый раз :cross_mark: «ошибка операции», далее операция удачна, но не влияет ни на что.


Условие: WS-апгрейд напрямую на origin как эталон (правильные заголовки Upgrade/Sec-WebSocket-*). Тест: curl -k https://***.***.ru/***/ -H "Connection: Upgrade" -H "Upgrade: websocket" -H "Sec-WebSocket-Key: ***==" -H "Sec-WebSocket-Version: 13"
Результат: :white_check_mark: HTTP 400 + via: 1.1 Caddy. Origin принимает WS-апгрейд корректно.

Очень примерно понимаю что это значит, но как я понял через cdn вообще не получается достучаться до источника. Не понимаю почему, несколько раз пересоздавал cdn ресурс. Пролистал всю доку на сайте beget. Очевидных причин почему не работает эта цепочка не вижу. При этом у друга на тесте от автора той статьи полноценно работало всё с этим cdn.

Помогите разобраться где и что я не так сделал. Я сам пока в тупике…

Всегда отключайте кеширование на CDN и пробуйте менять кучу “незадокументированных” параметров xhttp. В частности xPadding и session.

Параметры

Я когда пробовал белосписочные впн-боты из тг, сервера которых располагались за cdn такими как ngenix/curator там был полный пакет из noGRPCHeader, noSSEHeader, xPaddingPlacement, uplinkDataPlacement, uplinkHTTPMethod, sessionIDPlacement

Но основаная проблема почти всех белосписочных CDN так это то, что на них забанены POST запросы

Да и не особо нужен POST. А вот подбирать параметры обфускации бывает затруднительно, особенно если не понимаешь в вебтехологиях. И всё ухудшает отсутствие документации, а лишь крупицы инфы между срачами в коментах к PR гитхаба.
Например, мне не очень понятны зависимости между эти параметрами. Например, зависят ли друг от друга xPaddingPlacement, sessionIDPlacement, seqPlacement, uplinkDataPlacement?

Да согласен, документации по этим параметрам не хватает.

Но я сомневаюсь по поводу связи между этими параметрами т.к насколько я помню xPadding это и есть основное место куда xray заворачивает передаваемые данные, а sessionID это uuid клиента в конфиге. Вот по поводу seqPlacement, uplinkDataPlacement уже сказать не могу

Настройте CDN на обычный веб-сайт, на веб-сервер, и добейтесь, чтобы он отдавал вам ответы. Далее меняйте веб-сервер на прокси, и смотрите изменения в поведении, отлаживайте по-порядку.

Спасибо, сэкономил время, реально нет ничего, мб там с CNAME - доменом покопаться нужно… В поддержку напишу уточню, спасибо) если чё курсану тут дальше в ответах.

Короче Beget сами отлавливают впн трафик и режут его…

вот ответ поддержки

Здравствуйте.

Благодарим за длительное ожидание!

Ограничение установлено на стороне нашего партнера провайдера CDNVideo автоматической системой защиты, так как по вашему CDN-ресурсу были зафиксированы признаки трафика, похожего на VPN/proxy-использование. В связи с этим часть запросов к CDN может блокироваться с ответом 403.

Данный продукт направлен для ускорение доставки контента.

Если CDN в вашем проекте не используется для VPN/proxy, проксирования API, WebSocket-трафика, подписок или конфигураций, направьте, пожалуйста, дополнительную информацию для диагностики:

  1. Для какого проекта используется CDN?
  2. Какие именно файлы/разделы должны отдаваться через CDN?
  3. Используется ли CDN только для статического контента: изображения, CSS, JS, видео, документы?
  4. Приложите несколько URL, на которых сейчас воспроизводится 403, и примерное время проверки.

После получения информации передадим данные CDN-партнёру для повторной проверки трафика и возможности снятия ограничения. Обращаем внимание, что после передачи запроса партнёру может потребоваться длительное время на проверку и предоставление ответа с их стороны.

Я с этой дичью воевать не хочу, пойду поищу провайдеров лояльных к впн, на примете таймвэб и Gcore

Это G-Core Labs? Если да, не понимаю как они могут быть полезны, если это международная компания

Да, G-Core точно также как и cloudflare находится под 16кб блоком, а если сейчас нет то даже близко не в БС. Если речь идеть о ASN которая бьется как g-core RUS то это edgecenter и у них действительно есть пара IP в бс

Хз пока не дошел до них, с таймвэбом разбирался.

На таймвэбе из-за буферизации даунлинка рвется xhttp стрим на пакет ап моде, а метод гет по другому не поставить в 3x-ui он пакетапонли. Поэтому дилема…
Написал автору той статейки про которую в начале говоил, он сказал что в целом верно всё, но есть специфические настройки для каждого провайдера на всех уровнях от самой цдн панели до xray предлогает купить инструкции но я пока хз на сколько это нужно и на скольок это актуальная тема в послевыборной перспективе…

Параметры все документированы, просто в разных местах:

Если обход нужен по принципу “канал связи чисто текстом на крайний случай” - можно рассмотреть проксирование через DNS - всякие slipstream, masterdns и прочая. У меня настроено, оно работает, канал тухлый, но на тележку хватает

Я из тех у кого работает только tailscale, все xray/singbox коннекты обрываются через 3 минуты, что до рф серверов(таймвеб), что до иностранных/CDN. С разными фингерпринтами и на свой домен в рф с обратной записью. UDP протоколы вроде hysteria тоже не работают.

Что можно мне попробовать из этого поста?

tailscale это чистый wireguard-go, к каким нодам ты подключаешься?

к иностранным нодам напрямую. Координационный headscale в рф

Все уже придумано до вас, через них при желании можно проксировать любые TCP-потоки (а если немного напрячься - то даже и UDP): noiseonwires/yac-ws-bridge: YC Serverless Functions websocket tunnel/proxy

Может быть, кто-то разобрался, как нужно настроить веб-сервер или сам CDN, чтобы на Timeweb/Beget при открытии сайта по домену cdn.example.com открывался сайт, а не 403?

Я понимаю, что эти провайдеры блокируют все пути, кроме тех, в которых есть файл с расширением. Но не понимаю, как исправить именно открытие сайта. Пытался в nginx настроить редирект с / на /index.html, но это не помогло, так как такой запрос с / не доходит до origin. До origin доходит лишь cdn.example.com/index.html

Складывается ощущение, что эти провайдеры настолько упоролись с защитой от проксиков, что ломают всё остальное, либо я просто не умею настраивать веб-штучки

у CDNvideo режутся все пути с trailing slash и задан фильтр на пути, а xray в старых версиях безусловно добавляет его в конец, поэтому единственный фикс — клиент с версией xray-core v26.7.11 и новее (в happ вроде старше)

От 403 в timeweb мне удалось избавится включением опций cdn-кэширование и кэширование в браузере, установкой их значений на 0 и полной чисткой кэша. Правда подключение у меня так и не удалось заставить работать. В клиенте dial TLS connection: EOF, в логах caddy и xray пусто

Короче я сдался, пока что я не на столько крут чтобы самому это всё раскурить. Пошел купил гайд, раскидался с нейронкой что и как и всё заработало!

Короче нужн оставить нджинкс вместо кадди, он позволяет детальней управлять пакетами и т.д.
Нужно правильно указать специфичные значения в экстро полях xhttp в конфиге… ну и в целом всё, дальше всё работает…