Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 62
>Но в 2025 году в Санкт-Петербургском политехническом университете была защищена работа именно по детекции XTLS-Reality.
это не ее на хабре недавно разбирали что там треш?
> нейросеть на стороне РКН
откуда вы это все берете? =)
Авторы детектировали Reality в лабораторных условиях на собственном трафике, с заранее известными параметрами. В реальных условиях с правильно настроенным Reality и нормальным SNI-донором их метод не работает так как заявлено. Работа скорее академическая аля мы попробовали, чем «вот боевой детектор»
Я использовал её как подтверждение что такие исследования ведутся это правда, статья не открыта в общий доступ - шарить не могу, но имеются и по shadowsocks.
https://elib.spbstu.ru/dl/3/2025/vr/vr25-3961.pdf/en/infoПо нейросетям в ТСПУ тут не конкретный факт а общий фон. РКН публично заявлял о планах использовать ML для детекции VPN это есть в СМИ. Плюс есть целый класс коммерческих DPI-движков которые ML используют прямо сейчас тот же R&S PACE 2 от ipoque, который комбинирует kNN, decision tree, CNN и LSTM для классификации зашифрованного трафика в реальном времени, с еженедельными обновлениями сигнатур. Это не гипотеза это продукт который реально продаётся телеком-операторам и встраивается в их инфраструктуру. Использует ли его ТСПУ конкретно не знаю, документов очевидно - нет.
“Авторы детектировали”. Интересно, эти «авторы», считают что делают что-то хорошее или им просто плевать?
но имеются и по shadowsocks.
не подскажете, как shadowsocks детектится? Там весь траффик с самого первого байта - рандом (первые 32 байта - реальный рандом, а дальше от рандома визуально мало чем отличается). Моё предположение - считают энтропию и если видят рандом - в блок. А может и тупо - неизвестная сигнатура на непойми каком порту за границу - блок.
Авторы детектировали Reality в лабораторных условиях на собственном трафике, с заранее известными параметрами. В реальных условиях с правильно настроенным Reality и нормальным SNI-донором их метод не работает так как заявлено. Работа скорее академическая аля мы попробовали, чем «вот боевой детектор»
Я прочитал уже множество таких работ, часть даже подробно комментировал тут и на NTC форуме. Все они сводятся к тому, что автор берет древнюю версию xray с известной уязвимостью, пишет заведомо ошибочную конфигурацию (к примеру VLESS без VISION/XHTTP) с самыми наивными настройками (без мусора, паддингов, мултиплексирования и тд) и что-то там "детектирует" вероятностью процентов в 60-70. Ну то есть запустив такое получится положить весь интернет из-за ложноположительных срабатываний, но не туннели.
Как-то очень наивно думать, что в Китае с их бюджетами не смогли задетектировать, в Иране не смогли задетектировать, а студент магистратуры скриптом на питоне раз и задетектировал.
РКН публично заявлял о планах использовать ML для детекции VPN это есть в СМИ
По планам мы уже начинаем освоение Венеры, ну сразу после Луны
А в реальность сфера ML и тем более AI в стране находится мягко говоря не в лучшем состоянии. Мы заметно отстаем тут, к сожалению. Учитывая смешные по меркам этой индустрии бюджеты и отсутствие базы для этого, рассказы про ML в ТСПУ заставляют только усмехнуться.
Это не говоря о том, что исходя из слитой документации ТСПУ, у модуля фильтрации (EcoFilter) не хватает вычислительных ресурсов даже на анализ QUIC, удачи им запустить там ML модель.
Вообще, чем распространять откровенную дезинформацию, лучше бы рассказали о реальных угрозах вроде 16КБ блокировках, триггер блоках отдельных хостеров и прочие ковровые бомбардировки интернета.
Ещё немного - и получится Openconnect с камуфляжем.
Все эти ухищрения либо уже, либо в ближайшем будущем будут побеждены тупым зарезанием всех европейских хостингов. Берите VPS в ближневосточных странах.
А в итоге всё сводится к тупому блокированию TLS в сторону крупных хостингов, если домен не в белом списке.
ИИ содержащий продукт
Формулировки очень странные
Формулировки очень странные
Будьте конкретнее, пожалуйста. Просто вкинуть — не лучшее.
Нейросетевые картинки, которые выглядят вроде прилично, но если начинаешь всматриваться, то понимаешь, что там местами явный треш. Например, правый нижний угол третьей картинки имеет надпись "Scale: 1 unit = 10 mm". К чему это? Почему год 2024? К чему там символ компаса? И таких пустых "деталей" полным полно.
Заголовки для каждого абзаца, так люди не пишут!
Пример из текста
XHTTP: архитектура, которая решает эту проблему
XHTTP — транспортный протокол в Xray-core, построенный поверх HTTP/2 или HTTP/3. На первый взгляд похоже на старый WebSocket+TLS. Архитектурно — принципиально другое.
Почему WebSocket умер.
WebSocket-соединение начинается с HTTP Upgrade запроса, после которого переходит в постоянный двунаправленный поток. Этот паттерн (HTTP Upgrade + бесконечный поток без характерных HTTP запрос-ответных пар) детектируется давно и надёжно.
Что делает XHTTP иначе.
XHTTP разделяет восходящий и нисходящий трафик на отдельные HTTP-транзакции. Каждая транзакция — это обычная HTTP-пара запрос-ответ с нормальными заголовками, нормальным временем жизни. Статистически это неотличимо от браузера, загружающего контент с веб-сервера.
3. Абсолютно бесполезные комментарии в фрагментах с кодом.
Да и в целом вся статья читается неестественно, в ней будто отсутствует жизнь.
А противнее всего, когда "авторы" подобных статей начинают в комментариях мазаться.
Жаль минус влепить не могу...
Будьте конкретнее, пожалуйста.
Зря вы это сказали.
Поскольку никто нормально комментарии не читает, придётся сразу оговориться: мне всё равно, кто и как писал текст. Мне не нравится исключительно сам машинный стиль, а не факт, насколько автоматизированным был процесс написания.
Если кому-то удаcтся добиться на выходе из ChatGPT красивого текста, то я за этого человека буду искренне счастлив и не буду возражать читать подобное. К сожалению, писанина у машин всегда максимально отвратительная.
Это не предупреждение из разряда «желательно» - это обязательное условие.
это не опция, это необходимость
Это не «похоже на Chrome» — это Chrome.
они не конкурируют, они комбинируются
Противопоставление вида «это не X, это Y».
А вот тут просто каша из нескольких приёмов, характерных для языковых моделей. Темп, повторы, тире — всё машинное:
Рукопожатие идеальное. Детекция идёт не по нему. Детекция идёт по поведению соединения после него — и здесь Reality ничего не делает.
Большие языковые модели считают, что повторы — это очень красиво. Вообще, переиспользование структур языка — частая проблема БЯМ. В одной из прошлогодних работ (arXiv:2504.09373) был такой вывод: «we find that LLMs often reuse discourse structures (more so than humans) across samples, even when content differs». Там речь шла про повторы в повествовании вообще, не про слова, но мне кажется это связанным.
Больше повторов слов:
Реальное iCloud-соединение от реального iPhone или Mac имеет характерный паттерн запросов: конкретные API-эндпоинты, конкретные заголовки, конкретные тайминги.
Каждая транзакция — это обычная HTTP-пара запрос-ответ с нормальными заголовками, нормальным временем жизни.
Повторы и противопоставления в одном флаконе:
Reality закрывает детекцию на уровне TLS-рукопожатия и активного зондирования. XHTTP закрывает детекцию на уровне поведения соединения после рукопожатия.
Она маскирует установку соединения, но не маскирует то, что по этому соединению передаётся.
Детекция идёт не по нему. Детекция идёт по поведению соединения после него
Другая проблема — ненужные тире, которые вставляются абсолютно без повода:
Что конкретно изменилось, как это устроено на уровне алгоритмов — и почему XHTTP сейчас выглядит как правильный следующий шаг.
DPI-система делает активное зондирование, получает сертификат, смотрит на ASN и IP-адрес сертификата — и видит что это не iCloud и не Spotify.
Но для детекции «это не браузер вообще» — JA3 по-прежнему работает отлично.
Иногда куда лучше бы смотрелась запятая вместо тире:
Именно здесь Reality начинает проигрывать — и к этому мы вернёмся.
JA3-хэш Go-клиента хорошо известен — он встречается в базах детекции.
Не потому что их «нашли» — а потому что их трафик-профиль слишком аномальный.
Из-за подобных тире текст читается с каким-то придыханием, будто от избытка чувств перевести дух не удаётся. Но откуда здесь взяться эмоциям? Хотя тема животрепещущая, текст технический.
Не знаю, как называются вот такие конструкции в кавычках, но в машинной писанине они везде:
Это не «похоже на Chrome» — это Chrome.
Но для детекции «это не браузер вообще» — JA3 по-прежнему работает отлично.
Не «похожим на нехороший» — просто другим, и это уже аномалия.
Также БЯМ используют кавычки при малейшем оттенке переносного смысла. Видимо, их обучали на образцах литературного русского, но тонкости языка они уловить не в состоянии:
Реальный Chrome вставляет случайные «мусорные» расширения в ClientHello.
видит «нормальный» HTTP-трафик.
Наконец, приём, который меня выбешивает: два–три однотипных односложных предложения, рублёный ритм. Почему это случается, понять легко: дробим фразу, и сказанное будет выглядеть мощнее — дёшево и сердито.
Выбор очевидный. Конфиги выше. Удачи.
Работает. Пока. Где-то. У некоторых. Иногда. Если сервер не под нагрузкой. И донор выбран правильно. И луна в правильной фазе.
Рукопожатие идеальное. Детекция идёт не по нему. Детекция идёт по поведению соединения после него — и здесь Reality ничего не делает.
А вот заголовки в разумных пределах мне наоборот нравятся. Не вижу ничего дурного в том, что есть выделение полужирным. Разве что здесь не так много написано, чтобы была необходимость разбавить простыню текста форматированием.
Отредактировано: Вижу, что пока писал этот комментарий, вы уже убрали многие из этих примеров из текста.
apple.com— Apple держит IP в своих ASN, несоответствие сразу заметно
Не совсем так. У Apple есть кеши (https://cache.edge.apple/), типа как Google Global Cache, ставятся на сети операторов, работают на IP операторов.
Не осуждаю, статья годная, но нейросети подводят. Текст предполагаю что chatgpt писал (он любит эппл и спотифай, это палит). Ну и картинки. Автор, не ленись делать схемы, если будет твоя, на русском, без косяков ии, будет сильно лучше.
Хорошая статья, спасибо за ликбез!
По существу есть вопросы:
Что по самоворовству (self-steal/steal from yourself/steal oneself)? Зачем притворяться крупным сайтом, если можно просто накатить сгенеренную нейронкой статику на свой домен? Не понял смысла. В 2022-2023 самоворовство своего домена было рекомендуемым способом работы;
Получу ли я мгновенный профит, честно и качественно мигрировав на xHTTP, если я нахожусь в "расстрельном списке" AS? Я ведь не могу поручиться, что все клиенты в пределах /24 будут соблюдать все гайдлайны по настройке решений... А пока ДВ сильно не жалуется, так что мотивации бежать впереди порновоза нет...
Что по скорости? Где-то слышал, что xHTTP предлагает в два раза ниже пропускную способность по сравнению с VLESS/XTLS-Reality/TCP.
ходят слухи, что есть "белые списки" sni, которые не попадают под 16-24 кб блоки европейских хостингов (не путать с БС на мобильном интернете, где только рф сайты). То есть профит возможен.
если на вашей AS 16-24 кб блок - нет, не поможет. разве что слухи про БС sni правдивы.
В использовании разницы не замечаю, по цифрам VLESS/xhttp/packet-up тоже не сильно отличается от Raw-Reality
А все началось с того что ..."она утонула" (ц)
Xray очень радует) Настроил на vps, клиент на своё пк и тут же MTProto для телеги, чтобы с других устройств пользоваться) Всё летает, всё замечательно... Но какого чёрта я этим должен заниматься вообще?
Но какого чёрта я этим должен заниматься вообще?
очевидно-же - государство заботится о развитии компьютерной и политической граммотности населения. Раньше население приходило с работы и под пивас просто играло в игрушки общаясь по дискорду, теперь вот надо сначала прокинуть тоннель чтобы дискорд заработал (а то и сама игрушка запустилась) опять-же переодически изучать что нового в мире блокировок случилось, тоннель перенастроить, как работает ТСПУ почитать, ркн поругать, свое мнение о политиках высказать, а там уже и снова на работу пора :-)
А а почему никто не упоминает про протокол OUTLINE, он вроде как работает.
У меня один сервер с чистым зарубежным IP уже почти год живет с развернутым outline, больше 1 TB траффика в месяц, больше 10 человек - все стабильно. Мб протокол плохой не знаю точно.
Если что, в основном подключения из Москвы.
имхо запусти grok и задай ему такой промп - дай сравнение протокол OUTLINE с reality + tcp и reality + xhttp
Там протокол shadowsocks
У меня он наглухо умер года два назад, с тех пор не проверял, мог и заработать. Так например раньше носки жестко блочились, а теперь vless не але, а носки идеально работают.
Вариант В: ничего не делать.
Лучший вариант. Решать проблемы надо по мере возникновения, так как условия меняются.
Ждем полноценной работы смартфонов со Starlinkами.
старлинк бесплатным не будет, а вариантов проводить оплаты зарубежных сервисов не так уж и много.
Да и законодательно запретять как его использование так и смартфоны его поддерживающие еще до того как он заработает.
Устройство размером со смартфон ещё нужно идентифицировать как поддерживающее старлинк
Или придётся запрещать в страну ввоз вообще всех устройств размером с ладонь
Можно сразу сказать, что старлинк не работает в РФ
Ну так в глубине страны не работает, а на границе работает
Граница Казахстана и Финляндии - тысячи километров
Удачи отследить каждое
Подскажите кто использовал какие программы для VLESS + XHTTP + REALITY на сервере, на Android и на iPhone? Какие серверные части и клиентские наиболее стабильные и надежные?
Это тянет на серию статей, так как есть ядра, спектр ими решаемых задач, обертки на них, клиентов так вообще десятки... Есть панели, каждая под свои задачи созданная, у каждой своя экосистема и т. д. Всё это ставится скриптами, вручную, Docker, не Docker, из GitHub, из магазина... Без пол-литра так и не расскажешь хотя бы 20% из них.
Сервер - родной xray-core базированная база. Минус - нужны базовые навыки linux консоли для настройки, и надо редактировать текстовые конфиги, где потерял запятую/скобочку и все, ничего не работает. Еще есть панели вроде 3x-ui, устанавливается скриптом, всё визуально красиво. Удобная вещь для личного использования. Тяжелая артиллерия - Remnawave, куча настроек, визуальный редактор конфигов, исправляющий за тобой опечатки, много много всего еще. Но это решение скорее для заработка на vpn/proxy. Много ресурсов жрет, сложна в настройке. По клиентам - смотрите кто регулярно обновляется, список рекомендованных в репозитории xray-core
По факту есть 3 комбайна (с поддержкой разных протоколов): xray, sing-box, mihomo. Они же используются внутри клиентов. Самый популярный сейчас - xray (так сложилось). VLESS + XHTTP + REALITY - вот это родное именно для xray, все остальные переносят реализацию к себе. Поэтому для vless лучше всего использовать xray (поэтому и самый популярный). Для iOS самый лучший клиент - Shadowrocket (поддерживает почти все популярные протоколы). На Android можно использовать оригинальный клиент sing-box с нативным json-конфигом (или же что-то из мира xray).
Но на самом деле и кроме самого модного vless протоколов хватает. Например, NaïveProxy.
Тут была статья как установить x-ray на сервер и настроить. Там же и приложение указано. v2Raytun вроде (но это не точно). Надо поискать просто.
Регулярно появляются такие сгенерированные статьи про vless, которые собирают кучу плюсов. При чем половина текст - бред.
Подключись через свой прокси и зайди на scrapfly.io/web-scraping-tools/ja3-fingerprint. Отпечаток должен совпадать с обычным Chrome без прокси.
С чего вдруг этот сайт что-то напишет про мой прокси, если вся магия будет между мной и прокси, а между прокси и конечным сайтом будет обычный трафик моего браузера.
Или раздел про хорошие доноры или плохие доноры:
microsoft.com на Hetzner - "хороший", "любой мелкий сайт icloud.com" на Hetzner - "плохой". Где в этом тексте логика?
Но плюсов будет много...
Вот действительно. То "всёпропало, VLESS уже зарезали, ставьте Макс", то более тонко, с парочкой вредных советов. Невольно задашься вопросом, а не засланный ли казачок?
А "Реальное iCloud-соединение от реального iPhone или Mac имеет характерный паттерн запросов: конкретные API-эндпоинты, конкретные заголовки, конкретные тайминги"? Какие endpoints и заголовки, если все данные зашифрованы? Какие тайминги на мобильной сети?
Аналогично про "XHTTP разделяет восходящий и нисходящий трафик на отдельные HTTP-транзакции. Каждая транзакция — это обычная HTTP-пара запрос-ответ" и далее везде...
Нет, я, наверное, могу предположить, что придумали авторы XHTTP, прочитав нейрослоповский пересказ, скомбинированный с таким же переводом, но, читая подобные статьи, хочется прояснения темы от того, кто в ней реально разобрался, вместо ещё большего запутывания...
С чего вдруг этот сайт что-то напишет про мой прокси, если вся магия будет между мной и прокси, а между прокси и конечным сайтом будет обычный трафик моего браузера.
Вот с этого момента в статье тоже кекнул. Автор либо вообще ничего не понимает в том что пишет, либо решил что нормально кормить читателей нейроблевом выхлопом нейронки даже без элементарной проверки того, что она написала.
>«Reality решила это радикально: TLS-сессия буквально завершается на реальном сервере Apple или Microsoft. Клиент делает настоящее рукопожатие с настоящим icloud.com. Получает настоящий сертификат Apple, верифицированный через реальную цепочку CA. После завершения рукопожатия данные туннеля вшиваются в уже установленную сессию.»
Это же технически просто невозможно нет? TLS 1.3 не так работает же
Когда клиент и настоящий icloud.com делают полноценный handshake, они генерируют симметричные ключи шифрования (AEAD — AES-GCM или ChaCha). Эти ключи знает только клиент и Apple. Xray-сервер в этот момент — просто труба, он ничего не видит и не может расшифровать ни байта.
если ты попытаешься «вшить» свои VLESS-пакеты в уже зашифрованный поток то любая такая правка сразу ломает MAC или AEAD-тег.
На деле с риалити там как я помню не так работает.
Клиент шлёт ClientHello с правильным shortId. В поле Session ID (которое в TLS 1.3 почти не используется, но Xray его хитро переиспользует) он запихивает версию + timestamp + короткий id. Сервер смотрит: — shortId совпадает с тем, что в конфиге? — версия нормальная? — время не просрочено? Если да — сервер сам завершает handshake, генерирует свой временный сертификат на лету (подписанный твоим x25519 ключом). Клиент проверяет его только по pinned publicKey, а не по цепочке Apple. И дальше весь трафик уже между клиентом и твоим сервером. Если shortId кривой (то есть это пробер от ТСПУ или обычный curl) — сервер вообще не отвечает сам.
Он просто прозрачно прокидывает весь TCP-поток на настоящий microsoft.com:443. Пробер получает реальный сертификат, реальный ответ и спокойно уходит. Вот почему Reality так хорошо держит активное зондирование.
Ещё пару моментов по статье, которые уже устарели:
Конфиги с Vision теперь не работают как в статье. С января 2026 VLESS без flow считается deprecated. Если использовать Vision + XHTTP — обязательно нужно включить VLESS Encryption. Делаешь ./xray vlessenc, получаешь ключи: decryption на сервер (вместо "none"), encryption на клиент. Без этого будет предупреждение, а скоро возможно вообще перестанет работать.
поправьте ели что-то не так написал)
как теория - сойдёт
на практике трата хоть 1 рубля в добавок к тарифу провайдера неприемлема из корыстных побуждений а главное оставляет куда более явственный след - случись что, и скорее не если а когда плешивый режим дойдёт до физического отлова
поэтому ирл ещё не исчерпаны бесплатные методы. т.е. vless это попытка гвозди забивать микроскопом. банальный wg при достаточно простой обфускации продолжает работать даже с казалось бы наперечёт известными endpoint протона
Как ТСПУ реагирует на ssh соединения? Там есть одновременно всё, и постоянно висящие сессии с мониторингом итп, и взрывные нагрузки с передачей файлов, причем разных, отдельных дампов баз и архивов, бекапов от рестика, рклона и рсинка, удаленный рабочий стол итп. Они что реально всё это наглухо перекроют из за возможности пустить там еще и сокс прокси?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как ТСПУ ловит VLESS в 2026 и почему XHTTP — следующий шаг