в 1 статье какой-то бред. ТСПУ не может отличить браузер от прокси на сетях с сибирской блокировкой, для обхода блока протоколов достаточно в начале пару пакетов с мусором. намёка на ИИ даже не видно (по крайней мере на ТСПУ никаких нейронок нет и сомневаюсь что будут в будущем. отдельно для актив пробинга возможно что-то сделают).
Для обычных пользователей, решивших его попробовать, на практике означает лишь одно - это невозможность найти эти Naive proxy в Сети в виде подписок, хотя поддержка Naive в моб. VPN не редкость, например в виде плагинов.
Стоит naive. Иногда переключаюсь, проверяю. Последние несколько дней на naive сильно резалась скорость, vless, trojan - все ок. Сегодня все нормально у naive. Что это было - хз?
naive, понятное дело, только на клиенте. Nekobox, плагин. На сервере не ставил никаких caddy. Просто proxy-inbound в серверном xray - туда подключается naive, после снятия tls.
Если это просто инструкция по настройке то ок. Но из прочитанного названия и первого сообщения у меня сложилось вечатление, что вы наткнулись на новую блокировку, с которой не справляется uTLS, но справляется Naive — в таком случае, хотелось бы видеть само исследование и побайтовое сравнение реализаций с указанием места затыка. Ещё не понятно, зачем вообще использовалось reality + xhttp, для РФ это только дополнительная точка отказа — иметь доступ к оригинальному сайту с сервера прокси.
да, это просто гайд, который я бы хотел найти в тот момент когда пытался в этом всём разобраться. сделан он с простой целью - если кому-то нужно попробовать naive, вот готовая инструкция, проверенная личным опытом.
насчёт исследования: полноценный побайтовый реверс-инжиниринг я не проводил, но проблему получилось выявить через анализ трафика в wireshark. на проблемных провайдерах (Мослайн, МГТС, Дом.ру) в дампах при использовании vless четко наблюдался TCP Retransmission.
более конкретно, что я видел в дампах:
-
после отправки Client Hello с клиента, сервер просто уходил в молчание, хотя TCP-коннект был установлен. пакеты TLS-хендшейка просто дропались на ТСПУ, не доходя до апстрима. uTLS в данном случае не спасал. видимо, сигнатурный анализ научился цепляться за специфику реализации хендшейка в Xray.
-
при использовании XHTTP наблюдались бесконечные петли TCP Dup ACK. ТСПУ выборочно отбрасывал пакеты внутри туннеля, что приводило к падению скорости до 0.5 Мбит/с.
переход на Naive решил проблему “в лоб”: стек, на котором он работает, тобишь сhromium, даёт идентичный браузерному отпечаток, который на текущий момент проходит через фильтры без селективного дропа.
по поводу Reality+XHTTP согласен, что это лишняя точка отказа, но я пробовал этот стек как одну из итераций борьбы с ТУСП, которая в итоге и привела меня к NaiveProxy. как-то так.
Отключите reality, настройте xhttp и мультиплексирование через xmux.
Если сильно хотите использовать браузер для управления соединениями, Naive - не лучший выбор. Там автор периодически выковыривает сетевой стек хрома вручную. Зачем, если у xhttp есть BrowserDialer, который умеет использовать для этого любой установленный в системе браузер?
Звучит как новая поверхность атаки. Ничего не мешает “что-то лишнее” встроить туда (читайте – бэкдор).
Зависит от диапазона. Если хотите одновременно избежать сибирскую блокировку и 16КБ блокировку без каскада, то вполне себе вариант.
Client Hello в uTLS chrome и Naive побайтово идентичны, различия могут появится позже (последующие обмены я пока не исследовал, т.к. ТСПУ их пока не смотрит). А на сервере то что происходит после отправки клиентом Client Hello? В случае реалити прокси отправит этот принятый пакет на оригинальный сайт, и если администратор сайта заблокировал подсеть хостинга прокси, то именно так, как вы описали, и произойдёт — зависание до таймаута и прокси не будет работать.
Известный кому? Пока что, кроме каких-то сомнительных вбросов, никаких фактов на эту тему не видел.
Опубликовал статью о Naive на хабре: NaïveProxy в sing-box (альтернатива VLESS) / Хабр
Я бы не говорил, что naive - годный вариант. У меня на мобильной сети т.н. “сибирская” блокировка, блочатся все uTLS, кроме пустого. Соответственно, naive со своим “хромовым” отпечатком сразу же попадает в блок и, в отличии от всяких клиентов влесс или троян, там “пусто” никак не выставишь.
То есть, якобы полностью идентичный браузерному отпечаток naive в наших реалиях совсем не плюс, а скорее большой минус.
Ты уверен что там множество тлс сессий? Я сам не проверял, но везде написано что как будто там 1 сессия, + в синге есть параметр
insecure_concurrency
Я уже пишу это не первый раз. Да, сессий создаётся множество. Потому что со смартфона - а там каждая собака каждую секунду лезет в интернет )
Тогда пропиши параметр в =1
Прописал. Нихрена. То же самое. Блок.
Ещё раз повторю свою мысль. Причина не в протоколах, не в мультиплексировании, а именно в специфике смартфонов. Каждое приложение в смартфоне долбится в интернет, причем овердох..я раз в секунду. В нормальном режиме эти запросы идут по разным адресам, соответственно ничего критического нет. А вот когда эти запросы направляются в одну точку, промежуточный сервер, их становится слишком много, соответственно мы имеем “сибириаду” ) Тем более если ещё udp завернуть в tcp.
По-хорошему, здесь не мультиплексировать нужно, когда в одно соединение идут восемь от одного процесса, приложения или на один домен, а вообще делать два-три-пять туннелей с девайса, имитируя не только браузерный отпечаток, но и количество браузерных подключений, куда заворачивать всю эту смартфоновскую хрень. По типу как один туннель получается при ssh оver https. Но один это слишком палевно. Тогда и не будет никакой “сибириады”.
“Специфика смартфонов” вообще никак не относится к теме, вы пишете какую-то ерунду.
Тспу триггерится на множество тлс сессий к одному и тому же серверу, мультиплекс решает это раз и навсегда: 1 тлс сессия, да хоть миллион приложений с телефона пусть туда долбятся, тспу это не увидит.
Если в клиенте naive действительно есть мультиплекс, но блок всё равно есть, то стоит начать с отправки ключа мне в лс.
Откуда у тебя такая уверенность, что мультиплексируется бесконечное количество сессий в одну? У vless например 8 или 16 в одну. По-умолчанию 8.