VLESS: три подхода. Какой выбрали вы и почему?

1

Привет. Вдохновился этим тредом. Вижу следующие варианты.

  1. VLESS + VISION + REALITY под чужой сайт.
  2. VLESS + VISION + REALITY под свой сайт.
  3. VLESS + VISION + TLS + FALLBACK под свой сайт.

Первый вариант выглядит хорошо, но правильно ли я понял, что блокиратор может запросить все IP сайта, под который идёт маскировка, и заблокировать ваш IP, так как его не будет в этом списке? Почему в Китае так не делают? или делают? В чём заключаются издержки таких блокировок?

Между вторым и третьим вариантом вроде бы нет большой разницы? Я только заметил, что во втором варианте SNI клиента и сервера должны совпадать (хотя вбить можно что угодно; необязательно даже домен покупать свой).

Если вы пользуетесь третьим вариантом, можно ли настроить так, чтобы одно подключение умело принимать соединения с разными SNI от клиента? Может пригодиться, если выбранный SNI улетит в блок. Если можно, то вместо второго варианта, я бы выбрал третий.

Ещё есть такие мысли.

  1. Если маскироваться под чужой сайт, то надо нагнать туда трафика, иначе очень странно выглядит сервер майкрософта, к которому из всей необъятной подключается один Вася Пупкин.
  2. Если маскироваться под свой сайт, то надо строго ограничивать трафик и локации, с которых к нему подключаются.

Как вы думаете?

2

Каким образом? Я так и представляю что какая-нибудь условная локальная газета определённый страны, Швеция например должна будет Китайцам все свои ip выдать. Это бред же, основной траффик DDOS атак это как раз Китай и США,а тут прям в наглую просить будут ип сервера (с подписью точно не для ддос атак).

А если под большие кто-то маскироваться будет, то будет достаточно сменить sni на что-то поменьше

Делают, если трафик с vps идёт из Китая обратно в Китай = бан ип или бан порта.

То что цензору понадобиться или забанить ип сервера который маскируется, или забанить домен под который маскируються

У них есть “жёсткая” политика блокировок, это когда всё что plain text и понятный поток байт не баниться, а всё остольное умирает, такое в основном если какая-то тряска в стране происходит.

Есть, я бы даже сказал титаническая. Прочитайте про TLS-in-TLS. На гитхабе у создателей xray вообще тулза лежит для определения такого трафика, в Reality такого не происходит. GitHub - XTLS/Trojan-killer: Detect TLS in TLS.

На 99% уверен что нет, к сожалению

Я думаю вряд ли через ТСПУ кол-во трафика (в плане людей) регестрируют, а условный CF фиг РКН чё выдадит по сайту васи пупкина. Если маскироваться, то под средний сайт, желательно в сети вашего же хостера. Ведь тупо будет смотреться как мелкомягкие хостяться у хостера которого знает и пользуються 2 с половиной человека (от общего масштаба).

А толк? Active probing’ом РКН будет с ру ип заниматься. А вот АНБ твой сервак не нужен. Ну на крайний случай АНБ не заблокирует твой сервер в отлчии от РКН. А забанив все кроме ру ип ты лишаешся любых обновлений системы, пакетов и т.д с т.п

Короче бесполезное занятие как по мне

Я бы выбрал или 1 или 2, 2 лучше, но стоит того

3

“Reality такого не происходит.” Вы путаете rprx-vision и reality.

4

Благодарю за ответ.

Для крупного сайта можно же проверить, что IP сервера входит в выделенные диапазоны IP автономных систем компании, или нет?

Так я же написал про VISION. Его можно и без REALITY использовать.

Чем второй вариант лучше, кроме независимости от доступности чужого сайта и от задержи до него? В случае белых списков доменов первый вариант хотя бы можно будет заставить работать.

5

Можно добавить вариант VLESS + HTTP2 + REALITY + MULTIPLEX.
Это будет эффективнее, я считаю. С использованием sing-box к тому-же. Хоть свой сайт, хоть чужой. TLS-IN-TLS нету, из-за мультиплексации ( с паддингом). Мультиплексация в принципе дело православное

6

Для крупного да, не спорю. Но если так сделают то люди моментально просекут и не будут маскироваться под этих крупные домены. Не целесобразно банить

И я про vision, я возможно неправильно сформилировал свою мысль. Vision имеет проблемы с TLS-in-TLS, а Reality - нет. Если возвращаться к Вашему изначальному вопросу, что нету разницы, то получается это не так. Крайне извиняюсь, в xtls-rprx-vision решена данная проблема на 99%.
Reality может устранить характеристики отпечатков пальцев сервера tls.
xtls-rprx-vision может устранить характеристики tls-in-tls.
utls может устранить характеристики отпечатков клиентских tls.

Подробнее (много букв)

TLS in TLS

Почему 99% пакетов представляют собой необработанные данные? Что такое 1%?

Нам необходимо продолжить изучение того, что делает типичный прокси-сервер, когда он встречает внутренний трафик TLS 1.3 в первых нескольких пакетах.

Визуально, когда зашифрованный канал установлен:

Первый прокси-клиент пакета -> прокси-сервер «Здравствуйте, целевой адрес этого посещения прокси — Google, вот мой UUID»
Второй пакет прокси-клиент <- прокси-сервер «Здравствуйте, получен ваш запрос на прокси, начните отправку данных»
Третий пакет Браузер -> Прокси-клиент -> Прокси-сервер -> Google «Привет, Google, я сделаю с вами зашифрованный звонок. Я поддерживаю методы шифрования». (Этот пакет также называется TLS Client Hello)
Четвертый пакет браузер <- прокси-клиент <- прокси-сервер <- Google «Привет, пользователь, это сертификат Google, на этот раз он будет зашифрован с помощью TLS_AES_128_GCM_SHA256. Давайте начнем шифровать вызовы!» (этот пакет также называется TLS Server Hello)
Пятый пакет Браузер -> Прокси-клиент -> Прокси-сервер -> Google «Получено Начнем шифровать звонки!»

Известный вам протокол прокси-сервера тот же, пока пользователь использует какое-либо соединение TLS, требуется вышеупомянутый процесс установления связи. Как упоминалось ранее, внешнее шифрование TLS можно считать абсолютно безопасным, но для проверяющего, помимо информации о взломе, также может быть использована некоторая дополнительная информация для идентификации этих 5 пакетов.

В этом суть так называемого TLS при обнаружении TLS.

Если интересно можете почитать на github полную статью (Английский язык): examples/xtls-vision/README.md at main · seakfind/examples · GitHub

а если в кратце, то размеры этих пакетов что-то около статичны и разработчики xtls-vision добавляют туда информации чтобы осложнить индификацию, но насчёт таймингов?

"Наиболее очевидной особенностью являются длины этих 5 пакетов.

    Первый пакет очень короткий, и единственная переменная — это адрес назначения.
    Второй пакет также очень короткий и практически фиксированный.
    Третий пакет короткий, имеет очень мало изменений, почти единственная переменная — это целевой SNI.
    Длина четвертого пакета сильно варьируется.
    Пятый пакет очень короткий, с небольшими изменениями.

Можно интуитивно почувствовать, что характеристики длины этих пакетов на самом деле очень очевидны. В Vision наш подход к этому также весьма прост: мы заполняем длину каждого короткого пакета до интервала 900–1400 байт. Обратите внимание, что этот метод отличается от традиционного случайного добавления заполнения. Мы не слепо добавляем данные ко всем пакетам, а основываемся на нашем анализе внутреннего трафика, целенаправленно добавляя данные к характерным пакетам процесса TLS-рукопожатия."

Если пользователь отправляет пакет на сервер, это называется C, а противоположное направление называется S. Может ли рецензент определить, что это соединение TLS в TLS, основываясь на данных о временной последовательности, например, CSCSC, и их характеристиках временных интервалов?

Мы считаем, что этого недостаточно для вывода, и Vision не рассматривает этот аспект.

Многие разработчики упоминают MUX-мультиплексирование как способ противодействия обнаружению TLS в TLS. Это действительно оказывает маскирующий эффект в данном контексте. Если в туннеле мультиплексируются два разных TLS-соединения, существует вероятность формирования различных временных характеристик, таких как CCSSCC.

По факту Вы назвали основные причины почему steal oneself используют с Reality. В теории владелец сайта, под которого Вы маскируетесь может забанить Ваш ip за “большую назойливость” мягко говоря.

Но Вы можете быть легитимнее для РКН в случае если он захочет своими шаловливыми ручками в ручную заходить на Ваш домен. Чисто в теории можно на домен повесить, хммм, условно nextcloud или owncloud, а может что-то похожое для того что-бы думали что это Ваша “файловая помойка” и Вы туда сюда гоняете инфу, получается в несколько раз менее подозрительней чем качать террабайты инфы с новостного сайта или условной стоматологической клиники. Надеюсь Вы мою мысль поймали.

Шанс того что РКН будет ручками довольно мал. Возможно будет проверять те хостинги и домены где в месяц по 10+ ТБ бегают, таких мало будет, зато скорее всего это либо публичный бесплатный либо публичный платный VPN. Улов будет больше чем искать vps’ку где 200gb трафика в месяц и 2 человека сидят.

7

С MUX становиться всё более радужней, если так назвать можно

Многие разработчики упоминали мультиплексирование MUX против TLS при обнаружении TLS. В этом отношении это действительно сбивает с толку. Если в туннеле мультиплексируются два разных соединения TLS, существует вероятность формирования различных временных характеристик, таких как CCSSCC.

Вот оригинальные статьи если интересно: examples/xtls-vision/README.md at main · seakfind/examples · GitHub (перевод на английский)
XTLS Vision, fixes TLS in TLS, to the star and beyond · XTLS/Xray-core · Discussion #1295 · GitHub (Китайский)

8

HTTP2 это и так мультиплексное соединение, второй там не нужен

9

с insecure tls или самоподпис сертификатом все можно

10

Вы абсолютно правы, я xtls с rprx перепутал, крайне извиняюсь

И ниже более подробно описано. По факту проблемы нету, но в теории в техническом плане по временным интервалом могут.

11

Можно по конкретнее пожалуйста, я не понял что вы имели ввиду.

Гуглинг превёл меня к слудующему:

Использование небезопасных и устаревших протоколов может сделать соединения уязвимыми для таких эксплойтов, как DROWN (расшифровка RSA с использованием устаревшего и ослабленного шифрования eNcryption), нацеленная на конкретную уязвимость в реализации OpenSSL протокола SSLv2, и POODLE (заполнение Oracle при понижении устаревшего шифрования). Эта уязвимость позволяет злоумышленнику читать информацию, зашифрованную с помощью протокола SSLv3, в виде обычного текста, используя атаку «человек посередине» или подслушивание.

Это же по факту рай для цензоров или я не понял что-то

А с таким сертом будет ли вообще адекватно работать прокси? Мне теперь стало интересно, если такое можно реализовать + прикрутить список доменов и рандомить их до одного места)

12

Что-то вы все напутали. Vision как раз транспорт, который RPRX придумал, чтобы бороться с проблемой TLS-in-TLS. А Reality это система безапастности, ворующая TLS хендшейк, придумана, чтобы бороться с зондированием серверов. С безопасностью Reality могут использоваться и другие транспорты, например HTTP2 или gRPC, которые не лишены проблемы TLS-in-TLS.

А касательно вопроса топикстартера. На сегодня работает любая схема. Выбирайте, что нравится. Как раз китайцы все эти уловки придумывали, отвечая на реальные вызовы. Стал GFW мониторить ИИ дважды завернутый TLS - вот вам Vision как решения проблемы. Стали зондировать VPS - вот вам Реалити, чтобы маскировать сервер и uTLS, чтобы маскировать юзера. А пытаться угадать идеальную комбинацию решений безопасности “на будущее”, когда РКН ни с чем пока из этого не борется - бессмысленно. Вы не знаете, какой будет следующий ход цензора и что он изберет мишенью. И вы жонглируете протоколами “обезопасивая” себя от будущего, которое, возможно, никогда не настанет. А вместо этого, скажем, решат забанить скопом все IP вашего хостера, потому что решат, что какая-нибудь Aeza, например, слишком обнаглела, массово продавая решения для обхода блокировок. И что? Какая комбинация протоколов вам поможет?

13

Я же перечекнул своё же сообщение и ниже дополнил:

xtls-rprx-vision может устранить характеристики tls-in-tls.
Reality может устранить характеристики отпечатков пальцев сервера tls.

я перепутал xtls с rprx, а самое верхнее сообщение к сожалению уже изменить не могу, увы

Иностранная симка в роуминге :slight_smile:

Открой меня

Источник: Как перелезть через великую китайскую стену? — Talks — Форум

Я создал сервер в vultr в Нидерландах. Нашел в подсети какой-то непримечательный нидерландский сайт и настроил Xray Reality с маскировкой под этот домен. Думаю, что настроил правильно.

Прокси проработал несколько часов, я через него скачал андроид-студию и подобный хлам, потом начало всё тормозить и заглохло. Пару дней я был занят, сейчас проверяю - IP забанен. Причём я делал всё, чтобы не возбудить подозрения, на ssh заходил из другой сети, по сути через GFW мои запросы шли только на 443 порт с этим непримечательным доменом.

На текущий момент полу-легальный способ использования нормального интернета для меня это купленная в каком-то левом сервисе ESIM которая роутит трафик через Гонконг. С ней всё работает без лишних телодвижений, но стоит денег - за 50 GB я отдал примерно 55 евро. Для бытовых нужд, думаю, это оптимальный вариант, всё просто работает без лишних телодвижений.

14

не поняли, но и не важно, insecure tls это пропуск проверки валидности сертификата, это позволяет делать MITM так что в обсуждении не нуждается

мы не в северной корее, для установки tls соединения не обязательно иметь сертификат яндекса или гос услуг, но даже с ними можно иметь несколько на 1 порте (через iptables пробросить порт 443 на два локальных с рандом распределением и пользоваться vless+h2)

15

я не в этом корне мыслю, как сервера будет относится к самописным сертификатам, любые сервера. Неужели нету никаких защит от такого?

Если это так то я всё правильно понял.

16

Если так можно и сайты серт съедят то получается что можно

17

Скоро актуальным станет xhttp

18

Если использовать софт, по типу noisy, вместе с мультиплексацией, причем несколько разных процессов нойзи, которые проксируются ещё сверху вашего реалити другим vless или vmess, и выходит интересная схемка

19

Почему не нужен? ещё как нужен! Нам все нужно!

20

vmess уже не актуальный и не устойчивый к блокировкам
GFW.report (Английский): Summary on Recently Discovered V2Ray Weaknesses
подкрепляю словами rprx (Китайский): 关于 23 3 3 判断部分的 代码特征的利用漏洞 · Issue #17 · XTLS/Go · GitHub

А зачем проксировать поверх? Наоборот от этого избавляться хотят.

Можно ссылку? Я не нашёл просто