Одна из основных фишек xhttp - возможность пробиваться через cdn, пряча свой прокси за ip cdn и таким образом вынуждая цензора или блочить весь cdn, или не делать ничего (на что и остается надежда). Плюс лучше маскировка - куча траффика на ip cdn легко объясняется популярностью cdn, тогда как если клиент постоянно активно обменивается мегабайтами траффика через 443 на рандомном ip, который возвращает килобайтный html или yahoo.com, то могут легко возникнуть подозрения (пока таких темпоральных анализов скорее всего не делается, но тем не менее). В китае тема работает норм, т.к. запросы идут на CF сервера вне страны (да есть cf china network, но он не связан с глобальной сетью cf, к которой они и вяжут свои домены). В россии же у CF есть свои сервера в нескольких городах, являющиеся частью их сети, соответственно любой cf домен резолвится на эти ру ip (можно узнать конкретную локацию через эндпоинт your-domain.com/cdn-cgi/trace в поле colo). Пакеты до ориджин сервера все так же будут обрабатываться здесь dpi системой. Или я чего-то недопонимаю, или никаких бенефитов в проксировании xhttp через cf в россии абсолютно нет.
конкретно через CF - нет, потому что трафик до серверов CF в последнее время РКН активно начал резать.
но есть и другие CDN. в том числе и такие, которые наврядли заблокируют (подсказка: российские, ага), и их очень даже можно использовать для XHTTP.
а может и не будут.
понятно, т.е. все на авось повезет держится. чем возиться с рос. cdn наверно проще взять впс в ру дц и оттуда проксировать на иностранный, если уж надеяться, что дц траффик не анализируется dpi. но по мне так это очень слабая надежда и в целом сильно подрывает смысл xhttp в россии. попробую лучше иностранные cdn, у которых нет серверов в россии, т.к. думаю вероятность что заблочат рандомный cdn гораздо меньше чем вероятность, что на выходе ру серверов нет dpi (сейчас или в будущем)
-
и как это работает? не оxень понятен смысл сидеть за российским CDN..
-
есть пример конфига такого с условным CDN?
спасибо
еще раз напомню простые вещи:
- за РФ CDN можно платить российскими картами (и довольно недорого), когда других бесплатных вариантов не осталось
- трафик до серверов внутри страны фильтруется гораздо меньше чем наружу
- трафик в дата-центрах часто тоже фильтруется гораздо слабее, чем у конечных абонентов (плюс нет регионального фактора когда блокировки врубают при каких-то событиях), а часто не фильтруется вообще
- у РФ CDN есть в том числе балансеры за границей которые можно использовать если понадобится, и есть довольно неиллюзорная вероятность что они тоже окажутся в белых списках исходя из принадлежности к “правильной” AS
- Некоторые РФ CDN разрешают domain fronting. Еще раз: разрешают domain fronting. И еще раз: да, да, да, они разрешают domain fronting.
- трафик “в обратную сторону” не фильтруется вообще (кроме очевидных ошибок в конфигурации), поэтому если уж вместо CDN заморачиваетесь промежуточным сервером в России, то смотреть надо в эту сторону
доброе утро, уже периодически блочат Cloudflare, AWS (Cloudfront), Gcore, CDN77, BunnyCDN и Fastly.
выше ответил
абсолютно точно так же как с любым другим CDN. например вот этот вариант Xray-examples/VLESS-XHTTP3-Nginx at main · XTLS/Xray-examples · GitHub, только убрать alpn: h3, его как раз многие CDN пока не умеют.
Reality тут вообще не используется?
Получается nginx впереди сидит а xray за ним? Мнеказалось что рекомендуют ставить спереди xray на 443?
Выглядит сложновато для меня =( Скажите, есть какие-нибудь гайды чтобы все так настроить для 3x-ui например? Или уже готовый гайд, если делать все через конфиг файлы вручную полностью.
Reality не совместим с CDN по определению. Но схожего с Reality эффекта можно достичь с использованием domain fronting.
да
Зависит от используемого протокола и транспорта. В каких-то случаях лучше одно, в каких-то другое (например, для XHTTP/gRPC/WS со своим доменом Nginx спереди предпочтительнее чем XRay с Reality на 443, потому что может работать и с QUIC, и с заблокированным TLS1.3).
Хороших гайдов не встречал, увы.
У MiraclePtr на хабр был гайд по рабоет через CDN, но там у него прям переусложнено сильно, как мне показалось.
Понятно..
Возник другой вопрос..учитывая что все российские ЦДН подконтрольны (или будут подконтрольны) чекистам..то не будет ли так ,что все это выйдет в один большой хонипот.. Зарегистрирусь я на этом российском ЦДН сервисе, вставлю туда адрес своего сервера.. соотв сервер засветится, а выгружать списки и проверять где хостится -как раз плюнуть..
Ага, хостится не в Раше- лови бан на ТСПУ сервера или всего хостера , которого еще не охватили предыдущими банами… Или я что-то не так понимаю?
Крайне маловероятно, по крайней мере на данном этапе.
Не вижу смысла играть в “а если то, а если это”, мое дело - предложить рабочие и проверенные идеи, а решения для себя каждый принимает сам в границах здравого смысла.
Можно узнать какие именно?
Можешь, пожалуйста, подсказать российский CDN, который разрешает Domain Fronting и который физ. лицу можно оплатить картой?
Есть мнение, что Google CDN, был бы более живучим вариантом, незнаю разрешен ли у них DF, но учитывая как во время последних блокировок неработало почти все, кроме гуглосервисов, даже пробив ютуба не был таким испытанием, как например пробитие варпа. Думаю это связано с впервую очередь с нежеланием убивать андроид телефоны большинства пользователей РФ, которые без гугла фактически окирпичатся.
С 2018 года забанен и является нарушением ToS.
Источник
Domain fronting возможен в cloud run, можно ставить sni google.com, gmail.com и т.п., подходят айпи от google.com, gmail.com и т.п., только цена кусается там и нужна реальная карта для реги/оплаты. На ютубе есть инструкции как поднять через него vless.
У Cloud Run есть бесплатный тариф, либо 2,000,000 http запросов или 240,000 vCPU-секунд + 450,000 GiB-секунд ОЗУ. Всё выше этого на самом деле выйдет в копейки, там проблема в другом, стоймости сети. Через Cloud Run можно спокойно Dockerfile развертывать (того же 3x-ui) и так пользоваться. Не понятно как сам google к такому относится будет. Можно будет сделать PoC, но только люди для тестирования нужны будут. Да и трафик у google первые 200GiB бесплатно, затем конские 0.08 евроцента за GiB, что около 65 евро за 1 TiB (с учётом 200 GiB)
Это всего 66 часов для 1 vCPU.
Поскольку простой XRay/3X-UI - это не serverless, а полноценное приложение, то и считаться оно будет все время работающим. А останавливать-запускать контейнер каждый раз когда нужно воспользоваться прокси - такое себе удовольствие.
А вариант с биллингом запросов судя вот по этому документу весьма непрост, и скорее всего простой непеределанный XRay в таком режиме вообще не заведется. А если и заведется - там процессорное время тоже считается и всего 180,000 vCPU-seconds включено в тариф.
Базированный на реквесты:
Базированный на использовании:
Тут так оказывается. Ну не суть важно.
Google даёт ставить меньше одного vCPU, но производительность тут под вопросом тогда будет.
Я панельку сумел поставить и она работает, а вот как подключение реализовать ещё надо подумать, может через nginx прокидывать? Суть в том что контейнер может слушать только один порт, от этого и надо плясать
Смотря какие протоколы в планах использовать.
У Cloud Run балансер пропускает только HTTP/HTTPS, или он разруливает по SNI и ему пофиг что там внутри бегает?
XRay умеет в fallbacks, можно настроить VLESS-inbound, а у него сделать fallback на Websocket-inbound для какого-нибудь урла, и на порт панели для другого урла.
В итоге подключаться можно будет и по вебсокетам, и чистым VLESS, и на панель можно зайти если ввести определенный урл.
Пока что пытаюсь ws завести.
Ему побоку пока протокол читаемый и понятный. ShadowSocks и ему подобные мимо моментально.
Именно. Я этим на данный момент занимаюсь.