в 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? В случае реалити прокси отправит этот принятый пакет на оригинальный сайт, и если администратор сайта заблокировал подсеть хостинга прокси, то именно так, как вы описали, и произойдёт — зависание до таймаута и прокси не будет работать.
Известный кому? Пока что, кроме каких-то сомнительных вбросов, никаких фактов на эту тему не видел.