Настройка VLESS + TCP + REALITY + VISION + uTLS #3518
Replies: 18 comments 18 replies
-
|
Спасибо за статью. У меня есть вопрос по поводу shortIds. Вы сообщили, что он используется для различения клиентов, но почему xray не использует uuid для этого? Также если имеется несколько клиентов в конфиге, то для каждого клиента нужно делать свой shortId или разрешается один на всех? |
Beta Was this translation helpful? Give feedback.
-
|
по дефолту используется один на всех(по аналогии с реализацией в других проектах), по логике у каждого клиента должен быть свой, уникальный |
Beta Was this translation helpful? Give feedback.
-
|
希望俄罗斯有大牛给 REALITY 写个分析 |
Beta Was this translation helpful? Give feedback.
-
|
I have few questions regarding what domain should be used. So in the article the author said no large company site should be used. But the reality tutorial in the x-ray official GitHub is recommending the use of www.microsoft.com; and since I've tried using it in mainland and didn't encounter any problems, does that mean I'm already good to go, or should I still search for another domain and replace it? Another related question is the author says if we have our own domain, just use that. But wouldn't it look more suspicious if someone just suddenly start connecting to a new small site randomly? (Even assuming it's just for personal use? Like for example me watching YouTube which uses quite some large bandwidth and sustainably?) |
Beta Was this translation helpful? Give feedback.
-
|
For the censor, it's not hard to see that your IP address is not from Microsoft of Google or Cloudflare and others IP range, so it's not the best way to configure yours Reality. Better to use selfsteal or noname website that doesn't have own IP range. |
Beta Was this translation helpful? Give feedback.
-
|
Отличная статья - большое спасибо! У меня возник вопрос : правильно ли я понимаю, что при заходе на IP моего VPN шлюза при включенном протоколе VLESS + VISION прохожий должен увидеть сайт, под который я маскируюсь? Что бы я ни делал - вижу отлуп браузера так как мой IP не совпадает с сертификатом который прилетает от того сервера, под который я маскируюсь. Что я не так делаю ? |
Beta Was this translation helpful? Give feedback.
-
Как было сказано выше, для режима прокси, клиент должен получить временный доверенный сертификат, подписанный временным ключом аутентификации, во всех иных случаях это будет просто port forward на dest. Если Вы обращаетесь к айпи напрямую, сообщение TLS Client Hello, отправленное браузером, не содержит SNI, а хост в заголовке HTTP неверен. curl -v --resolve www.microsoft.com:443:151.101.65.69 https://www.microsoft.comвместо 151.101.xx.xx должен быть IP вашего сервера |
Beta Was this translation helpful? Give feedback.
-
|
Добрый день, Большое спасибо за статью! У меня аналогичный вопрос. Попытался использовать несколько разных маскировочных вебсайтов, однако когда пытаюсь зайти на свой сервер из браузера, то получаю разные ошибки, обычно связанные с невалидным сертификатом - Сафари выдает, что не может установить безопасное соединение в одном случае, в другом - пишет что проблема с сертификатом. Хром пишет, что сайт uses an unsupported protocol и выдает ошибку ERR_SSL_VERSION_OR_CIPHER_MISMATCH). Однако проверка через curl во всех случаях выдает, что все хорошо. Так как все-таки сделать так, что заходя из любого браузера на мой VPS загружался маскировочный сайт? |
Beta Was this translation helpful? Give feedback.
-
Добавить соответствующую запись в hosts. :) |
Beta Was this translation helpful? Give feedback.
-
|
То же самое чуть более подробно:
(отсюда) |
Beta Was this translation helpful? Give feedback.
-
|
Спасибо за отличный урок по использованию протокола Reality. Но у меня есть несколько вопросов относительно того, какой домен следует использовать. Итак, в статье вы сказали, что не следует использовать сайт крупной компании. Но в практическом руководстве в официальном репозитории Xray на GitHub рекомендуется использовать www.microsoft.com; и поскольку я пробовал использовать его в материковом Китае и не столкнулся с какими-либо проблемами (например, я могу пройти через gfw), означает ли это, что я уже готов к работе, или мне все равно следует искать другой домен и заменять его из-за из соображений безопасности? Еще один связанный с этим вопрос: вы сказали, что если у нас есть собственный домен, просто используйте его. Но не будет ли это выглядеть более подозрительно, если кто-то вдруг начнет случайным образом подключаться к новому небольшому сайту? (Даже если предположить, что это только для личного использования? Как, например, я смотрю YouTube, который выглядит как устойчивое соединение с высокой пропускной способностью? Разве это не выглядит подозрительно?) извините за мой русский, если мои слова не имеют смысла. поскольку я действительно хочу узнать об этом больше, но я не говорю по-русски. |
Beta Was this translation helpful? Give feedback.
-
|
Подробно и доступно |
Beta Was this translation helpful? Give feedback.
-
|
up |
Beta Was this translation helpful? Give feedback.
-
|
спасибо за труд! |
Beta Was this translation helpful? Give feedback.
-
|
Приветствую, а нет ли у Вас гайда по настройке vless с mkcp? Пробовал настраивать по гайдам из интернета, не подключается нормально ни к впс, ни даже к домашнему серверу в пределах локальной сети. |
Beta Was this translation helpful? Give feedback.
-
|
у меня не создаётся ключ приватный на сервере marzban docker exec marzban-marzban-1 xray x25519 ввожу и ничего Error response from daemon: No such container: marzban-marzban-1 |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Спасибо за статью, в ней многие вопросы для конфигурации соединения и клиента были раскрыты. |
Beta Was this translation helpful? Give feedback.
-
|
никак, это не реализовано в xray сейчас, но вроде как коммьюнити хотят это сделать. пока можно поставить fali2ban + limit ip |
Beta Was this translation helpful? Give feedback.
-
|
Лимит по IP не вариант, на одном IP могут быть 2 разных конфига, или один конфиг может быть на разных IP. |
Beta Was this translation helpful? Give feedback.
-
|
получается только множить инстансы (контейнеры), или руками добавлять\удалять уникальные shortIds (массив на сервере, вопрос на сколько хватит, и по одному уникальному в кфг клиента). |
Beta Was this translation helpful? Give feedback.
-
|
Если какая известная проблема в REALITY что он путает сертификаты при большом потоке данных? |
Beta Was this translation helpful? Give feedback.
-
|
Be careful. |
Beta Was this translation helpful? Give feedback.
-
|
Важное дополнение, спасибо. |
Beta Was this translation helpful? Give feedback.
-
|
Здравствуйте. С удовольствием пользуюсь данным впн уже не первый год. Но недавно столкнулся с проблемой: сайты, которые заблокированы иностранцами не открываются. И в сервисе проверки ip отображается реальное местоположение ip, а не сервера, на котором установлен vpn. Как это можно исправить? |
Beta Was this translation helpful? Give feedback.
-
|
Сбросить конфиг до дефолтных настроек |
Beta Was this translation helpful? Give feedback.
-
Дык там и так дефолтные настройки. После первоначальной настройки я ничего не менял. Или я что-то неправильно понял? |
Beta Was this translation helpful? Give feedback.
-
|
Есть несколько возможных причин:
"dns": {
"servers": [
{
"address": "77.88.8.8",
"port": 53,
"domains": [
"geosite:category-ru"
]
},
"77.88.8.1",
"8.8.8.8",
"1.1.1.1"
]
},
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"domain": [
"geosite:category-ru",
"domain:localhost"
],
"outboundTag": "direct"
},
{
"type": "field",
"ip": [
"geoip:private"
],
"outboundTag": "direct"
},
{
"type": "field",
"ip": [
"0.0.0.0/0",
"::/0"
],
"outboundTag": "proxy"
}
]
} |
Beta Was this translation helpful? Give feedback.
-
|
Ok |
Beta Was this translation helpful? Give feedback.
-
|
Связанный тред https://gist.github.com/kksudo/9e2072b3c60a72040f4e9d6fb9da7e9c |
Beta Was this translation helpful? Give feedback.
-
VLESS TCP REALITY + FLOW + uTLS 配置指南本指南将详细介绍如何配置 VLESS TCP REALITY + FLOW + uTLS，并深入探讨其工作机制。 建议您完整阅读本指南。本指南将从基础知识到各种机制的实现和配置细节逐步深入，帮助您不仅理解产品的各个方面，还能形成对其工作原理和功能的全面认识。 通过按顺序仔细学习所有章节，您将全面掌握并能够高效地在工作中使用该产品。 VLESS定义VLESS 是一种轻量级无状态传输协议，分为 inbound 和 outbound 两部分，可作为 Xray 客户端与服务器之间的桥梁。其认证方法基于 UUID（通用唯一标识符）。 请求与响应结构VLESS 的请求结构如下：
VLESS 的响应结构如下：
传输模式VLESS 支持多种传输模式，包括 TCP、gRPC、H2、QUIC、WebSocket、mKCP。 但由于多种因素（稍后说明），建议在 REALITY 中仅使用 TCP 作为可靠的传输模式。 VLESS 本身不提供加密，因此必须通过可靠的加密通道（如 TLS 或 REALITY）使用。 REALITY简介REALITY 是对现有 TLS 技术的改进，实现了完整的 TLS 1.3，通过指定某个网站的 SNI（服务器名称指示） 进行伪装，使流量外观与普通 TLS 1.3 流量无异。 重要提示：REALITY 是基于 Go 语言 TLS 包的分支（fork）。 核心任务REALITY 的开发解决了以下关键问题：
REALITY 设计哲学REALITY 的设计遵循以下原则：
伪装网站的最低要求伪装网站需满足以下条件：
附加条件：
工作原理误解澄清：REALITY 并不“窃取证书”。它实现完整的 TLS 1.3，证书在 TLS 1.3 中是加密的，第三方无法查看。 REALITY 的工作流程：
交互流程：
数据流REALITY 的核心逻辑是将代理流量伪装为普通 TLS 流量，做到“在 如同在森林中隐藏一棵树”。在普通 TLS 代理（如 Trojan）中：
数据流示意图：
理想代理逻辑：
此模式称为 xtls-rprx-vision。 关键点：
流量分析：
注意：Vision 不支持 mux（多路复用），因为 Vision 仅复制数据，无法区分多路连接。 REALITY 参数配置以下是 REALITY 的完整参数说明： {
"dest": "example.com:443",
"serverNames": ["example.com", "www.example.com"],
"privateKey": "MMX7m0Mj3faUstoEm5NBdegeXkHG6ZB78xzBv2n3ZUA",
"publicKey": "7xUz-xONEFhoGAb7XdmzhIUYybAlCnRvd1L0Ax_7yk4",
"shortIds": ["", "0123456789abcdef"],
"spiderX": "/blog",
"maxTimeDiff": 0,
"show": false,
"minClientVer": "1.8.6",
"maxClientVer": "1.8.15",
"fingerprint": "chrome",
"xver": 0
}DEST/SNI
注意：
私钥/公钥
为何使用公钥/私钥而非 UUID：
ShortID
SpiderX
MaxTimeDiff
SHOW
minClientVer/maxClientVer
fingerprint
xver
服务器配置以下是 Xray-core 的最小服务器配置： {
"log": {
"loglevel": "warning"
},
"inbounds": [
{
"listen": "0.0.0.0",
"port": 443,
"protocol": "vless",
"settings": {
"clients": [
{
"id": "dfccaec7-6bed-499b-af77-0275d55d573c",
"flow": "xtls-rprx-vision"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
"dest": "pupalupa.com",
"serverNames": [
"www.pupalupa.com",
"pupalupa.com"
],
"privateKey": "2KZ4uouMKgI8nR-LDJNP1_MHisCJOmKGj9jUjZLncVU",
"shortIds": [
"6ba85179e30d4fc2"
]
}
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
]
}
}
],
"outbounds": [
{
"protocol": "freedom",
"tag": "direct"
},
{
"protocol": "blackhole",
"tag": "block"
}
]
}客户端配置以下是客户端的最小配置： {
"log": {
"loglevel": "warning"
},
"routing": {
"rules": [
{
"ip": [
"geoip:private"
],
"outboundTag": "direct"
}
]
},
"inbounds": [
{
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks"
},
{
"listen": "127.0.0.1",
"port": 10809,
"protocol": "http"
}
],
"outbounds": [
{
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "",
"port": 443,
"users": [
{
"id": "dfccaec7-6bed-499b-af77-0275d55d573c",
"encryption": "none",
"flow": "xtls-rprx-vision"
}
]
}
]
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
"fingerprint": "chrome",
"serverName": "www.pupalupa.com",
"publicKey": "Z84J2IelR9ch3k8VtlVhhs5ycBUlXA7wHBWcBrjqnAw",
"shortId": "6ba85179e30d4fc2"
}
},
"tag": "proxy"
},
{
"protocol": "freedom",
"tag": "direct"
}
]
} |
Beta Was this translation helpful? Give feedback.
-
|
Добрый день! Подскажите пожалуйста, пытался нахрапом найти инфу - не вышло. Можно ли поднять клиент Vless reality в контейнере на proxmox или на виртуалке и пустить через него трафик из нескольких подстей , не совсем понимаю как это должно быть реализовано. Примерно схема такая, может быть вы знаете уже успешные реализации? Небольшое пояснение, это домашняя лаба. |
Beta Was this translation helpful? Give feedback.
-
|
Вы имеете в виду распределение трафика, один и тот же сервер, разные порты соответствуют разным экспортам? |
Beta Was this translation helpful? Give feedback.
-
|
У меня большинство конфигураций из сети не работает, в т.ч. которую я сделал по этому гайду. Xray 25.6.8. |
Beta Was this translation helpful? Give feedback.
-
|
Какой у вас сетевой провайдер? |
Beta Was this translation helpful? Give feedback.
-
|
Я это делал без провайдера - просто локально с 2 процессами в консоли. |
Beta Was this translation helpful? Give feedback.
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
В данном руководстве мы с Вами подробно рассмотрим настройку VLESS TCP REALITY + FLOW + uTLS, а так же рассмотрим детально механизмы их работы.
Необходимо внимательно изучить это руководство полностью. На каждом этапе, от изучения основ до рассмотрения реализации различных механизмов и тонкостей настройки, мы будем углубляться в детали каждого предыдущего пункта. Такой подход позволит вам не только понять отдельные аспекты продукта, но и сформировать комплексное и целостное представление о его работе и возможностях.
В конечном итоге, последовательное и подробное изучение всех разделов обеспечит всестороннее понимание и позволит эффективно использовать продукт в вашей работе.
VLESS
Определение
VLESS — это легкий транспортный протокол, не сохраняющий состояние, который разделен на inbound и outbound части и может использоваться в качестве моста между клиентом и сервером Xray. Метод аутентификации протокола основан на UUID (Universally Unique Identifier).
Запрос и ответ
VLESS имеет следующую структуру запроса:
VLESS имеет следующую структуру ответа:
Режим передачи
VLESS поддерживает множество режимов передачи: RAW (TCP), xHTTP, gRPC, H2, QUIC, WebSocket , mKCP.
Однако, из-за совокупности факторов, о которых будет сказано немногим позже, для REALITY рекомендуется использовать TCP как единственный надежный режим передачи данных.
VLESS, на данный момент, не имеет встроенного шифрования,
хотя в ближайших релизах такая возможность появится, поэтому обязательным условием для его использования является наличие надежного канала, такого как TLS или REALITY.REALITY
Введение
REALITY представляет собой усовершенствование существующих технологий TLS, реализуя полный TLS 1.3 с определенным SNI веб-сайта для маскировки, при этом сохраняя внешний вид трафика, аналогичный обычному TLS 1.3 и при этом квантово-безопасный.
Reality лишь модифицирует TLS, и для реализации на стороне клиента достаточно незначительных изменений — полностью случайного session id и кастомной проверки сертификатов. Теоретически это полностью совместимо с большинством TLS-реализаций.
Однако это не работает с QUIC, так как поле session id, которое требуется изменить в Reality, в практически всех реализациях TCP TLS заполняется случайными значениями для совместимости, но в QUIC TLS это поле имеет нулевую длину и не может быть модифицировано.
Задачи
Ключевые задачи, решенные при разработке REALITY:
Устойчивость к атакам на цепочку сертификатов
REALITY улучшает устойчивость к атакам, связанным с цепочкой сертификатов. В традиционном TLS безопасность соединения зависит от доверия к центрам сертификации (CA). Атаки на цепочку сертификатов возможны, если злоумышленник скомпрометирует или подделает сертификат, выданный CA. REALITY уменьшает эту уязвимость, предоставляя дополнительные механизмы безопасности.
Сокрытие отпечатков TLS
Отпечатки TLS — это уникальные характеристики, которые могут использоваться для идентификации и блокировки определенных типов зашифрованного трафика. В странах с жесткой интернет-цензурой правительства могут использовать отпечатки TLS для обнаружения и блокировки трафика. REALITY минимизирует эти отпечатки, делая трафик менее узнаваемым и более устойчивым к цензуре и блокировкам.
Прямая секретность
Этот принцип безопасности гарантирует, что даже в случае компрометации ключей шифрования в будущем злоумышленники не смогут расшифровать прошлые сессии. REALITY поддерживает прямую секретность, обеспечивая, что каждая сессия зашифрована уникальным сеансовым ключом.
Отсутствие зависимости от домена
REALITY позволяет указывать чужие сайты без необходимости покупки собственного домена или настройки TLS-сервера, что делает его более удобным для использования и позволяет представлять полностью реальный TLS с определенным SNI посреднику.
Совместимость с существующими протоколами
REALITY разработан для совместимости с существующими протоколами, что позволяет интегрировать его в существующие системы без кардинальных изменений. Однако это не рекомендуется из-за существующих и легко распознаваемых особенностей TLS.
Прозрачность для пользователей и серверов
Протокол предназначен для работы таким образом, чтобы быть прозрачным как для клиентов, так и для серверов, что облегчает его внедрение и использование.
Поддержка современных стандартов
REALITY поддерживает современные стандарты безопасности и шифрования, обеспечивая высокий уровень защиты данных.
Гибкость и настройка
Протокол предлагает различные опции настройки для удовлетворения специфических требований безопасности и производительности.
Философия дизайна REALITY
При разработке REALITY, придерживались трех основных принципов:
Все процессы протокола автоматизированы для минимизации человеческого вмешательства, что снижает риск ошибок.
Серверные данные и ключи тщательно защищены, контроль доступа строго осуществляется сервером, а критически важные данные хранятся только на сервере, исключая их компрометацию.
Например, сервер может отказать в подключении устаревших версий Xray-core для предотвращения уязвимостей и ошибок.
Минимальные требования
Минимальные требования к камуфляжному веб-сайту:
Дополнительные критерии:
IP-адрес камуфляжного веб-сайта близок к IP-адресу вашего сервера.
Наличие IP-адреса, близкого к вашему серверу, означает, что камуфляжный веб-сайт имеет IP-адрес, который близок к IP-адресу вашего сервера с точки зрения сетевого расстояния или географического местоположения.
Это может сделать соединение более эффективным и менее подозрительным.
Сообщения о рукопожатии после «Server Hello» шифруются вместе.
Некоторые веб-сайты могут не шифровать сообщения рукопожатия после «Server Hello» вместе, а вместо этого отправлять их отдельно в виде открытого текста. Это может предоставить информацию о сервере и клиенте, например, поддерживаемые ими наборы шифров, расширения и сертификаты. Злоумышленники могут использовать это для идентификации сервера и клиента.
Поэтому сервер и клиент должны обменяться зашифрованными данными после первоначального подтверждения TLS, предотвращая подслушивание или вмешательство третьих лиц.
Сервер поддерживает OCSP.
Сервер поддерживает сшивание OCSP, что означает, что сервер может предоставить подтверждение действительности своего сертификата, не требуя от клиента обращения в центр сертификации.
Это может улучшить производительность и конфиденциальность соединения.
Пост-квантовая эра
В ближайшем будущем, с добавлением защиты от квантовых компьютеров, необходимо выбирать целевой сайт с RSA-сертификатом, а не с ECDSA (так как у ECDSA меньше допустимая длина), с X25519MLKEM768 в качестве алгоритма обмена ключами и общей длиной цепочки сертификатов 3500+ байт.
Принцип работы
Существует ошибочное мнение, что REALITY использует метод "воровства сертификатов". REALITY реализует полный TLS 1.3, который не требует и не осуществляет подмены сертификатов, так как в TLS 1.3 сертификаты зашифрованы и недоступны для просмотра посредником.
После Server Hello все сообщения зашифрованы, поэтому сервер REALITY перехватывает только сообщения рукопожатия сервера (Server Hello) от камуфляжного сайта включая их длину и временные характеристики, заменяя key_share
Из чего следует, что клиент REALITY получает временный доверенный сертификат, выданный временным аутентификационным ключом, и в нормальных условиях никогда не получает настоящий сертификат камуфляжного сайта.
Общая схема взаимодействия выглядит следующим образом:
Клиент отправляет запрос TLS Client-Hello на сервер Reality. Сервер Reality перенаправляет этот запрос на адрес камуфляжного сайта. Камуфляжный сайт отвечает с TLS Server-Hello, сервер получает его и характеристики длины последующих сообщений рукопожатия, а затем пересылает обратно клиенту. Если специальные поля в запросе TLS Client-Hello клиента были корректными, сервер Reality переключается в режим прокси. Далее начинается передача данных через VLESS, включая авторизацию по UUID и другие связанные процессы.
Поток данных
Вообще, основная наша логика заключается в использовании TLS для маскировки прокси-трафика среди самого обычного интернет-трафика.
Как говорят: «Спрятать дерево в лесу».
Для обычного TLS прокси-протокола (например, Trojan), клиент прокси пользователя устанавливает настоящее TLS-соединение с прокси-сервером, и через этот зашифрованный туннель приложение (например, браузер) устанавливает еще одно TLS-соединение с целевым сервером (например, Google). В этот момент браузер и сервер Google обеспечивают end-to-end шифрование, и никто (включая наш прокси) не может расшифровать или подделать отправляемую информацию.
Вот краткая схема:
И тут мы понимаем, что когда прокси-данные проходят через цензора, они фактически шифруются дважды. Однако, в этом процессе, 99% трафика на самом деле не требует дополнительного шифрования. Поскольку данные, зашифрованные с помощью TLS 1.3 (а мы с вами помним, что REALITY = TLS 1.3), внешне выглядят абсолютно одинаково, цензор не может их различить.
Таким образом, логика идеального прокси должна быть следующей:
Поздравляю! Мы изобрели xtls-rprx-vision.
Мы можем заметить, что:
Одним из важных недостатков обычного TLS-прокси является "шифрование в шифровании". Как обсуждалось выше, хотя внешний вид зашифрованных пакетов неотличим для цензора, неизбежным является увеличение заголовка каждого пакета с каждым уровнем шифрования. Это увеличение может быть незначительным, но для маленьких данных (например, пакетов ответов) оно может быть более заметным, и некоторые пакеты могут превышать ограничения MTU сетевого уровня. Самое важное - каждый пакет увеличивается на одинаковую длину, что создает определенные статистические характеристики.
Можно сказать, что когда передаются данные TLS 1.3, 99% наших пакетов имеют почти идеальные характеристики трафика, потому что это оригинальные данные, не обработанные прокси.
Наверное, у вас возник вопрос: почему мы говорим, что 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-шифрование можно считать абсолютно безопасным, но для цензора, помимо взлома информации, есть возможность использовать некоторые дополнительные данные для идентификации этих пяти пакетов.
Самой очевидной характеристикой этих пяти пакетов является их длина. В частности:
Можно интуитивно почувствовать, что характеристики длины этих пакетов довольно очевидны. В Vision подход к решению этой проблемы также прост: мы увеличиваем длину каждого короткого пакета до диапазона от 900 до 1400. Обратите внимание, что этот метод отличается от традиционного случайного заполнения; мы не просто добавляем заполнение ко всем пакетам, а основываясь на нашем анализе внутреннего трафика, целенаправленно заполняем характерные пакеты TLS-рукопожатия.
Важное момент состоит в том, что при использовании vision, использовать mux не представляется возможным.
Как мы обсуждали выше, использование vision означает, что прокси не выполняет никаких операций, кроме копирования 1-в-1 от клиентского соединения к целевому соединению.
Mux означает, что прокси использует одно соединение для передачи нескольких клиентских соединений.
В пределах одного mux-соединения нельзя использовать vision, так как нет способа определить, куда отправлять данные.
Seed
Информация будет добавлена после релизаПараметры REALITY
После того, как мы поняли базовые механизмы нашего прокси, мы можем перейти к его настройке.
Ниже приведено полное описание всех параметров Reality, которыми Вы можете оперировать при настройке.
{ "target": "example.com:443", "serverNames": ["example.com", "www.example.com"], "serverName": "example.com", "privateKey": "MMX7m0Mj3faUstoEm5NBdegeXkHG6ZB78xzBv2n3ZUA", "password": "7xUz-xONEFhoGAb7XdmzhIUYybAlCnRvd1L0Ax_7yk4", "shortIds": ["", "0123456789abcdef"], "mldsa65Seed": "", "mldsa65Verify": "", "limitFallbackUpload": { "afterBytes": 0, "bytesPerSec": 0, "burstBytesPerSec": 0 }, "limitFallbackDownload": { "afterBytes": 0, "bytesPerSec": 0, "burstBytesPerSec": 0 }, "spiderX": "/blog", "maxTimeDiff": 0, "show": false, "minClientVer": "1.8.6", "maxClientVer": "1.8.15", "fingerprint": "chrome", "xver": 0 }TARGET/SNI
Выше по тексту, мы постоянно говорили о камуфляжном веб-сайте.
Настройка данных полей, будет играть ключевую роль в вашем прокси сервисе, поэтому выбору TARGET/SNI требует уделить особенно много времени.
Обязательное поле.
Заполняется на сервере.
Пример:
example.com:443Пример:
228.008.114.881:443Пример:
/var/lib/my.socketПример:
8443"target"здесь означает "цель", которую REALITY имитирует в реальном времени, и она (цель) взаимодействует с REALITY."target"должен соответствовать минимальным, выдвигаемым требованиям.Как мы с Вами обсуждали выше, по принципу своей работы, по крайней мере на данный момент, REALITY каждый раз должен получать пакет рукопожатия, поэтому важно учитывать, насколько близок и стабилен целевой сайт, так как выбор этого самого целевого сайта/домена существенно влияет на задержку, скорость и его стабильность.
Выше, мы с Вами ввели термин, что REALITY имитирует цель, в связи с чем мы можем раскрыть несколько несколько нюансов, которые люди записывают в минусы, хотя это и не так:
Считаю большим плюсом данный нюанс, ведь как мы рассмотрели выше, для режима прокси клиент должен получить временный доверенный сертификат, подписанный временным ключом аутентификации, во всех иных случаях это будет просто port forward на dest, соответственно, было бы странно, при «лежащем» dest отправлять цензора в пустоту и тем самым раскрывая свой прокси.
Если целевой сервер поддерживает пост-квантовый алгоритм обмена ключами X25519MLKEM768, то клиент reality автоматически применит этот алгоритм для согласования ключей. Чтобы проверить поддержку, выполните команду
xray tls ping cloudflare.com(замените адрес на target, при необходимости добавьте номер порта).Так же, в случае, если Вы хотите использовать опциональный механизм подписи и проверки подписи ML-DSA-65, устойчивый к квантовым компьютерам, необходимо выбирать целевой сайт с RSA-сертификатом, а не с ECDSA (так как у ECDSA меньше допустимая длина), с X25519MLKEM768 в качестве алгоритма обмена ключами и общей длиной цепочки сертификатов 3500+ байт.
Обязательное поле.
Заполняется на сервере и на клиенте.
Пример:
["example.com", "www.example.com"]Пример:
[" "]Список разрешенных SNI.
На данный момент, wildcard не поддерживается.
При настройке этих параметров, важно помнить следующее:
На самом деле, если у dest есть действительный сертификат по умолчанию, клиент может использовать другие SNI для подключения, так как сервер будет отвечать с характеристиками, соответствующими ответу dest с сертификатом по умолчанию.
Поэтому сервер обязан ограничивать диапазон допустимых значений для serverNames, чтобы предотвратить случайное использование SNI клиентами, если только это не сделано нарочно, и хотя REALITY поддерживает такую возможность, но если указанный dest фактически не имеет того serverName, это может стать явным признаком, поэтому не следует злоупотреблять этим (так же как и пустым serverName).
В совокупности:
Обычно параметр servername заполняется, при необходимости, соответствующими SANs, перечисленным в SSL-сертификате для веб-сайта в dest.
Как было сказано выше, есть нюанс в том, что для обеспечения эффекта маскировки, Xray будет напрямую перенаправлять трафик с недействительной аутентификацией (незаконные запросы reality) на указанный dest. Если IP-адрес сайта, указанного в dest, особенный (например, сайт использует CDN CloudFlare), это может привести к тому, что ваш сервер будет выступать в роли port forward CloudFlare, что может вызвать превратить ваш сервер в узел для других.
Чтобы этого избежать, можно рассмотреть возможность использования Nginx и других методов для фильтрации нежелательных SNI. Или вы также можете рассмотреть настройку соответствующих параметров limitFallbackUpload и limitFallbackDownload, чтобы ограничить скорость.
Включение ограничения скорости может ввести новые характеристики, обнаруживаемые цензором! Если вы разработчик GUI/панели/скрипта установки в один клик, обязательно рандомизируйте эти параметры!
Очень важно, не использовать крупные сайты в качестве DEST/SNI*
Множество крупных сайтов имеют CDN в стране, поэтому их использование не рекомендуется (это например касается Google и других крупных игроков, хотя Microsoft в 22 году отключила CDN в РФ).
Ведь если у сайта есть сервера в стране, то с точки зрения наблюдателя (цензора) в нормальных условиях, вы должны обращаться к локальным адресам внутри страны, а не выходить за ее пределы.
Так же, например, в случае с официальным репозиторием REALITY, dl.google.com приводится только для иллюстрации.
Никто и никогда, в здравом уме, не станет использовать Google в качестве dest.
Для очень немногих сайтов, например, для того же dl.google.com, Chrome добавляет дополнительную информацию в Client Finished, но из-за недостатков библиотеки uTLS мы этого не делаем.
Дак что же делать?
Если у Вас нет своего домена, и если Вы не находитесь в регионе, где необходимо использовать домены из белого списка, то рекомендуется использовать отличный инструмент https://github.com/XTLS/RealiTLScanner для сканирования соседних доменов
Если у вас есть собственный домен - используйте его.
Приватные/публичные ключи
На этом пункте хотелось бы остановиться подробнее, для лучшего понимания внутренних механизмов.
Как мы обсуждали ранее, REALITY это tls 1.3, соответственно, все механизмы для него идентичны.
В данном случае, алгоритмом обмена ключами по умолчанию будет являться ECDHE с кривой X25519.
Быть может Вы задаетесь вопросом, почему в REALITY для аутентификации не используется напрямую UUID, а добавлен механизм публичных и приватных ключей?
На самом деле, если использовать симметричные ключи, то при получении конфигурации клиента, цензор сможет провести атаку MITM, но если использовать публичные и приватные ключи X25519 в сочетании с key_share TLSv1.3, то даже при получении публичного ключа клиента цензор не сможет использовать его для проверки соединения как REALITY, не говоря уже о проведении эффективной атаки.
Как мы обсуждали выше, REALITY разработан с учетом того, что конфигурация клиента может быть раскрыта, поэтому безопасность здесь на высшем уровне: защитите приватный ключ сервера REALITY, и ваш трафик будет в безопасности.
Конечно, регулярная смена публичных и приватных ключей еще лучше.
Почему это очень важно и почему мы уделили с Вами столько времени этому разделу?
Простой пример: если вы случайно раскроете пароль SS или UUID VMess, цензор сможет расшифровать весь ваш прошлый и будущий зашифрованный трафик, а также провести идеальную атаку MITM.
Вы можете спросить, как же может произойти утечка? Облачное резервное копирование телефона, загрузка через клавиатуру, буфер обмена, отечественное программное обеспечение и другие неизвестные нам способы.
Обязательное значение
Задается
толькона сервереПример:
MMX7m0Mj3faUstoEm5NBdegeXkHG6ZB78xzBv2n3ZUAСгенерировать ключи можно путем выполнения команды в консоли
./xray x25519Сервер использует privateKey из конфигурации и key_share из Client Hello для вычисления общего секретного ключа, затем с помощью HKDF генерирует "временный ключ аутентификации", используемый для дешифрования и проверки запроса клиента, после чего генерирует временный доверенный сертификат Ed25519, подпись которого является HMAC "временного ключа аутентификации" для его публичного ключа.
Заполняется только на клиенте.
Пример :
7xUz-xONEFhoGAb7XdmzhIUYybAlCnRvd1L0Ax_7yk4клиент использует приватный ключ, соответствующий key_share в Client Hello, и publicKey из конфигурации для вычисления общего секретного ключа, затем с помощью HKDF генерирует "временный ключ аутентификации", использующийся для AEAD аутентификации и шифрования номера версии, временной метки и Short ID, с приложенными данными всего процесса рукопожатия, результат заполняется в session ID для проверки сервером запроса.
Таким образом, password и privateKey в конфигурации используются для установки общего секрета между клиентом и сервером, и для генерации временных аутентификационных ключей и временных доверенных сертификатов, необходимых для безопасного и аутентифицированного обмена данными в рамках REALITY.
Многих ошибочно считают, что ключи, состоящие из 256 бит хуже, чем ключи 2048 бит, не беря в расчет того, что RSA и DHE требуют больших ключей для обеспечения аналогичной безопасности по сравнению с алгоритмами, основанными на эллиптических кривых.
Для простоты понимания, например в RSA, идет разложении числа на простые множители.
Раньше это была сложная задача, но она становится все легче с ростом мощности компьютеров и для того что бы защититься от них(взлома с помощью их), нужно использовать большие ключи, 2048 или 3072 бит или еще больше.
В тот же момент x25519, основан на более сложной математической задаче, которая труднее решается даже при наличии супер мощных компьютеров, и из за сложности, разложение логарифма на эллиптических кривых, обеспечивает высокую безопасность при меньших размерах ключей.
Как мы обсуждали выше, ключ длиной 256 бит для X25519 дает уровень безопасности, эквивалентный ключу длиной 3072 бит для RSA.
mldsa65Seed
Только для сервера. Приватный ключ, применяемый для добавления к сертификату, выдаваемому клиенту Reality, дополнительной пост-квантовой подписи по схеме ML-DSA-65. Назначение — защитить соединение на случай появления квантового компьютера, способного взломать X25519: даже если пароль будет скомпрометирован, MITM-атака останется невозможной.
Сгенерировать пару ключей можно командой
xray mldsa65. После того как приватный ключ внесён в конфигурацию сервера, подпись добавляется в расширение сертификата; на старые клиенты или клиенты без поддержки этой функции это не влияет.После включения этой функции длина сертификата, возвращаемого целевым сервером (target), обязательно должна превышать 3500 байт. Пост-квантовая подпись увеличивает размер временного сертификата Reality; чтобы не создавать отличительную особенность, сертификат target тоже должен быть крупным. Проверить размер можно командой
xray tls ping example.com.Для полной пост-квантовой защиты сам target также должен поддерживать ключевой обмен X25519MLKEM768. Поддержку можно проверить той же командой, указанной выше.
mldsa65Verify
Необязательный параметр. Публичный ключ для проверки подписи ML-DSA-65.
Если поле не пустое, клиент будет использовать указанный ключ для валидации сертификата, возвращённого сервером. Подробности см. в описании параметра
"mldsa65Seed".limitFallbackUpload/limitFallbackDownload
:::danger
Предупреждение: Лучшей практикой для REALITY всегда является использование сертификата из той же ASN, или собственного домена, поэтому, скорее всего, вам эта функция не понадобится; только если вы вынуждены использовать сертификат CDN, можно рассмотреть включение этой функции, чтобы избежать превращения вашего сервера в узел для других.
Включение ограничения скорости может ввести новые характеристики, обнаруживаемые GFW! Если вы разработчик GUI/панели/скрипта установки в один клик, обязательно рандомизируйте эти параметры!
:::
:::tip
limitFallbackUploadиlimitFallbackDownloadявляются необязательными параметрами. Они позволяют ограничить скорость передачи данных для резервных (fallback) соединений, не прошедших проверку. ПараметрbytesPerSecпо умолчанию равен 0, что означает, что ограничение скорости не включено.Принцип работы: Для каждого соединения алгоритм ограничения скорости включается после передачи
afterBytesбайтов.Ограничение скорости реализовано с помощью алгоритма "маркерная корзина" (token bucket). Вместимость корзины равна
burstBytesPerSec. Каждый переданный байт потребляет один маркер, и изначально корзина заполнена доburstBytesPerSec.Каждую секунду корзина пополняется на
bytesPerSecмаркеров, пока не достигнет своей максимальной вместимости.Пример:
afterBytes=10485760,burstBytesPerSec=5242880,bytesPerSec=1048576означают, что после передачи 10 МB скорость будет ограничена до 1 МB/с. Если передача приостановится, через 5 секунд скорость может временно вырасти до 5 МB/с (burst), а затем снова вернется к 1 МB/с.Рекомендации: Слишком большие значения
afterBytesиburstBytesPerSecне приведут к желаемому эффекту ограничения скорости. Слишком маленькие значенияbytesPerSecиburstBytesPerSecмогут быть легко обнаружены.Следует разумно подбирать параметры в зависимости от размера ресурсов веб-сайта-источника. Если внезапные скачки скорости нежелательны, установите для
burstBytesPerSecзначение 0. :::Необязательный параметр. Ограничение скорости для резервных соединений REALITY. Ограничение вступает в силу после передачи указанного количества байт. По умолчанию 0.
Необязательный параметр. Ограничение скорости для резервных соединений REALITY. Задаёт базовую скорость (байт/секунду). По умолчанию 0, что означает отключение функции ограничения скорости.
Необязательный параметр. Ограничение скорости для резервных соединений REALITY. Задаёт пиковую (burst) скорость (байт/секунду). Действует, когда значение больше
bytesPerSec.ShortID
Обязательное поле.
Список shortId, доступных клиенту используется для различения разных клиентов.
Диапазон от 0 до f, длина должна быть кратна 2 и не превышать 16 символов.
Можно сгенерировать путем выполнения в консоли команды
openssl rand -hex 8Если включены пустые значения, shortId клиента может быть пустым.
Пример:
[" ", "e13c3f07bcffd6e9"]Пример:
[" "]Пример:
["c28e3p08uiqqh6e5", "e13c3f07bcffd6e9"]Разделом выше, мы с Вами рассмотрели где и когда принимает участие данные параметр.
SpiderX
Необязательное поле.
Заполняется на клиенте.
Пример:
/Пример:
/blogРекомендуется, чтобы начальный путь и параметры сканера были разными для каждого клиента.
Для того, что бы понять, что такое «паук», или режим сканирования, нам нужно еще немного окунуться в REALITY.
Ранее мы все время рассматривали только один вариант, когда REALITY получал временный доверенный сертификат и устанавливал прокси соединения, но на самом деле, REALITY, может различать несколько типов сертификатов:
при получении различных типов сертификатов, клиент reality выполняет соотвествующие действия:
Соотвественно, для каждого из случаев, когда клиент reality получает настоящий сертификат, а именно:
То он (клиент), переходит в режим сканирования (crawler):
Запускаем
Запускаем одно соединение HTTP/2 с dest , и отправляются параллельно по одному и тому же соединению, GET-запросы к различным URL-адресам на целевом сервере (target/dest), по схеме Целевой сайт + path, где изначальный path определяется параметром SpiderX.
по факту получения ответов на наши запросы они анализируются, и все найденные ссылки добавляются в список путей (path) и это продолжается.
На самом деле механизм немного сложнее (с установкой UA, Referrer, рандомизацией запросов, времени ожидания и так далее, но мы это опустим)
Соотвественно, этим механизмом, мы (клиент reality) имитируем поведение реального пользователя в выше перечисленных, экстренных случаях.
MaxTimeDiff
Необязательное поле.
Заполняется на сервере.
Максимальная разрешенная разница во времени в миллисекундах.
Пример:
0Пример:
60000MaxTimeDiff является страховкой для того, что бы предотвратить возможные, недоброжелательные манипуляции посредника.
В Client Hello протокола REALITY все элементы максимально задействованы, а дополнительные данные AEAD включают весь Client Hello.
Посредник не может изменить ни один бит, и все что ему остаётся, это только повторная отправка и хоть она и бесполезна (поскольку у посредника нет временного приватного ключа, соответствующего key_share, он не сможет расшифровать сообщение сервера), тем не менее, это все еще может вызвать ненужные ответы сервера.
А вдруг, если данных много, и у него случайно есть соответствующий приватный ключ?
Поэтому в REALITY есть зашифрованный таймстамп.
На самом деле, таймстамп, отправляемый клиентом, точен только до секунды. Единица измерения maxTimeDiff – миллисекунды,
Если нужно установить maxTimeDiff, то рекомендуется начать со значения 60000+, если не хотите синхронизироваться, можно даже с одного дня.
SHOW
Вывод отладочной информации
Заполняется на сервере.
Пример:
trueminClientVer
Необязательное значение.
Заполняется на сервере.
Минимально разрешенная версия клиента, от которого будет принято подключение
Пример:
1.8.6maxClientVer
Необязательное значение.
Заполняется на сервере.
Максимально разрешенная версия клиента, от которого будет принято подключение
Пример:
1.8.6fingerprint
fingerprint: строкаОбязательное поле.
Заполняется на клиенте.
При включении Xray будет имитировать отпечаток TLS через библиотеку uTLS или сгенерирует его случайным образом.
Этот параметр используется для настройки указанного отпечатка
TLS Client Hello.Значение по умолчанию
chrome.При включении Xray будет эмулировать отпечаток
TLSчерез библиотеку uTLS или генерировать его случайным образом.Поддерживаются четыре режима настройки:
"chrome""firefox""safari""ios""android""edge""360""qq""random": случайный выбор из новых версий браузеров."randomized": полная случайная генерация уникального отпечатка (100% поддержка TLS 1.3 с использованием X25519)Использование имени переменной отпечатка uTLS, например,
"HelloRandomizedNoALPN""HelloChrome_106_Shuffle". Полный список см. в библиотеке uTLS.Отключение эмуляции отпечатка
TLS Client Hello:::danger
Из соображений безопасности этот параметр не следует устанавливать в значение
unsafe.:::
"unsafe": отпечаток go/tlsxver
Необязательное значение
Заполняется на сервере.
Пример:
0Протокол PROXY используется для передачи реального исходного IP-адреса и порта запроса.
Версия может быть установлена на 1 или 2, со значением по умолчанию 0, что означает отсутствие использования протокола PROXY. Рекомендуется использовать версию 1, если это необходимо.
На данный момент версии 1 и 2 имеют одинаковую функциональность, но различную структуру: версия 1 представляет собой текстовый формат, а версия 2 — бинарный.
Настройка сервера
Выше, мы с Вами разобрали основные параметры доступные для конфигурирования.
Теперь же давайте настроим сервер xray-core для работы с REALITY.
Минимальная конфигурация Вашего сервера будет выглядеть так.
При желании, Вы можете настроить его исходя из ранее полученных знаний.
{ "log": { "loglevel": "warning" }, "inbounds": [ { "listen": "0.0.0.0", "port": 443, "protocol": "vless", "settings": { "clients": [ { "id": "dfccaec7-6bed-499b-af77-0275d55d573c", "flow": "xtls-rprx-vision" } ], "decryption": "none" }, "streamSettings": { "network": "raw", "security": "reality", "realitySettings": { "target": "pupalupa.com", "serverNames": [ "www.pupalupa.com", "pupalupa.com" ], "privateKey": "2KZ4uouMKgI8nR-LDJNP1_MHisCJOmKGj9jUjZLncVU", "shortIds": [ "6ba85179e30d4fc2" ] } }, "sniffing": { "enabled": true, "destOverride": [ "http", "tls" ] } } ], "outbounds": [ { "protocol": "freedom", "tag": "direct" }, { "protocol": "blackhole", "tag": "block" } ] }Настройка клиента
Минимальная конфигурация Вашего клиента будет выглядеть так.
При желании, Вы можете настроить его исходя из ранее полученных знаний.
{ "log": { "loglevel": "warning" }, "routing": { "rules": [ { "ip": [ "geoip:private" ], "outboundTag": "direct" } ] }, "inbounds": [ { "listen": "127.0.0.1", "port": 10808, "protocol": "socks" } ], "outbounds": [ { "protocol": "vless", "settings": { "vnext": [ { "address": "", "port": 443, "users": [ { "id": "dfccaec7-6bed-499b-af77-0275d55d573c", "encryption": "none", "flow": "xtls-rprx-vision" } ] } ] }, "streamSettings": { "network": "tcp", "security": "reality", "realitySettings": { "fingerprint": "chrome", "serverName": "www.pupalupa.com", "password": "Z84J2IelR9ch3k8VtlVhhs5ycBUlXA7wHBWcBrjqnAw", "shortId": "6ba85179e30d4fc2" } }, "tag": "proxy" }, { "protocol": "freedom", "tag": "direct" } ] }Beta Was this translation helpful? Give feedback.
All reactions