Так, я создал эту тему отдельно для того, чтобы осветить возможности других протоколов, конкретнее - naive proxy. Как упоминалось в этой теме мы искали рабочий протокол т.к. лично у меня vless + reality + xhttp - всё. Я поискл по интернету, в том числе и на этом форуме и чего-то, что бы решило мою проблему не нашёл. Поэтому решил сам во всём разобраться и запилить свой ультимативный гайд, мб кому-то будет полезно.
У NaiveProxy есть свои минусы по сравнению с Vision. Есть конечно и плюсы. На самом деле выбор зависит исключительно от текущих алгоритмов РКН. Нет никакого смысла готовиться к чему-то заранее. Работает что-то? Не трогаем, не паримся. Сломалось? Ищем новый протокол.
Минусы Naive - там TLS в TLS, что сильно влияет на размеры пакетов и вид трафика. В Vision это исправлено, они начинают передавать данные без лишней обертки. В Naive же такое не исправить без MITM (о чем пишет автор). Но очевидный плюс Naive по сравнению с Vision - мультиплексирование, всё идет в одном соединении (и автор настоятельно не рекомендует использовать даже 2 параллельных соединения). Чем больше конечных соединений внутри одного с мультиплексированием, тем сложнее опознать TLS in TLS. В Vision мультиплексирования нет по дизайну.
Сегодня пытался разобраться с реализацией padding в Naive при использовании h2c между Caddy и sing-box. Нашел баг, отправил PR, автор уже забрал его.
В пакеты для маскировки длины протокол вставляет пустые блоки рандомно, padding называется. Хотел проверить, что промежуточный сервер их не вырезает. А вместо нулевых байт padding иногда находил куски памяти, в том числе имена доменов и прочее. Оказалось, что сервер sing-box буфера брал из общего пула, добавлял место для padding, но не обнулял. В итоге, своеобразная утечка происходила произвольных данных из памяти. Да и по спецификации протокола там должны быть нули, хотя это и ни на что не влияет, данные игнорируются. Добавил обнуление этих участок после выделения буфера до отправки.
Да, я абсолютно с вами согласен. Мне экстренно пришлось искать решение, как было описано в исходном посте, в связи с тем, что у меня резко отвалилась моя связка vless + reality + xhttp. Да, может быть это не идеальное решение, но оно меня вполне устраивает. Пока что.
если честно, я не сетевой инженер, а обычный разработчит. в связи с этим всем мне пришлось экстренно разбираться в технологиях, поэтому во многих понятиях я “хромаю”. благодарю за предложение помочь, но пока вынужден откланяться т.к. сильно занят на ближайшее время, еле выделил время для записи видео. но потом, как появится время я был бы рад помощи.
У меня VLESS + XHTTP + REALITY с разделением up/downstream работает без проблем даже на подсети, где одновременно присутствуют сибирская и 16КБ блокировки.
Ещё у NaiveProxy плюс в том, что используется стек Chromium, в итоге маскровка куда лучше, чем uTLS у Xray. Но насколько это (пока что) актуально не очень понятно.
Я писал именно про Vision. В xhttp другой принцип работы со своими минусами. Vision заявляет, что убирает TLS in TLS, если внутри идет TLS 1.3. Он в процессе соединения переходит в режим копирования трафика, что убирает оверхед. Но этот режим включается не всегда (если нагрузка не подходит). Плюс при таком подходе мультиплексирование исключается, поэтому его там и нет.
Преимущество в том, что в Naive сетевой стек хрома (вот прямо исходный код хрома), все отпечатки один в один совпадают, вся реализация один в один за исключением того, что внутри другой трафик спрятан. Этот стек используют хром, youtube, google maps и вообще почти всё сетевое от гугл на андроид. Не нужен uTLS, не нужно пытаться подо что-то кое-как замаскироваться. Выдаёт только длина пакетов, раздутая из-за вложенных TLS, но какой-то padding для сглаживания тоже реализован (там 3 вида padding, в заголовках подключения, в первых пакетах, в RST кадрах).
Так разве это не портит всю малину? TLS внутри TLS считался слишком заметным ещё во времена, когда метой обхода блокировок был shadowsocks + v2ray plugin
топик для того, чтобы люди могли найти нормальную структурированную информацию по naive proxy которой я не смог найти, пришлось читать мануалы, форумы и возиться со всем самому. после этого на основе своих попыток я сформировал более или менее структурированный гайд который и залил сюда.