Можно сделать так ничего не трогая?
Я такое на Reality сделал. Первый инбаунд, например, XHTTP слушает 443, в поле Dest пишем ему какой-нибудь внутренний порт или юникс-сокет. Этот порт/сокет слушает следующий инбаунд, например, на gRPC, в Dest новый порт, который слушает третий инбаунд, пусть на TCP. Если надоело в эти цепочки играть, терминируем последний через тот же Dest на воруемый сайт или свой домен, как обычно. Т.е. мы по очереди перебираем протоколы, если какой-то подошел ключом, устанавливаем туннель, а если ни один не подцепил, с последнего перебрасываем на сайт. В результате по всем протоколам можно ходить через 443. TLS c fallback, как я понимаю, так же должен работать. Попробуйте такую цепочку через поле Dest в fallback построить, оно ту же функцию по идеее выполняет.
Настроил. Оказалось очень просто, при уже имеющемся инбаунде для “классического” vless-reality на 443 порте нужно добавить новый инбаунд:
{
"listen": "@xhttp",
"protocol": "vless",
"settings": {
"decryption": "none",
"clients": [
{
"id": "ваш_id",
"email": "12345"
}
]
},
"streamSettings": {
"network": "xhttp",
"xhttpSettings": {
"path": "/ваш_path"
}
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
]
}
}
И добавить его в фоллбеки у vless-reality:
"settings": {
"fallbacks": [
{
"dest": "@xhttp"
}
]
},
И теперь клиенты могут подключаться к reality серверу как c транспортом tcp (raw), так и с xhttp
Типа такого?
Спойлер
{
"inbounds": [
{
"port": 443,
"protocol": "vless",
"settings": {
"clients": [
{
"id": "12345",
"flow": "xtls-rprx-vision",
"level": 0,
"email": "555@555.com"
}
],
"decryption": "none",
"fallbacks": [
{
"dest": "1111"
},
{
"dest": "@xhttp"
}
]
},
"streamSettings": {
"fingerprint": "chrome",
"network": "raw",
"security": "reality",
"realitySettings": {
"show": false,
"dest": "1111",
"xver": 0,
"serverNames": [
"example.com"
],
"privateKey": "123",
"shortIds": [
"123"
]
}
},
"sniffing": {
"routeOnly": true,
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
]
}
},
{
"listen": "@xhttp",
"protocol": "vless",
"settings": {
"decryption": "none",
"clients": [
{
"id": "тот же id что у reality",
"email": "тот же email что у reality"
}
]
},
"streamSettings": {
"network": "xhttp",
"xhttpSettings": {
"path": "/"
}
},
"sniffing": {
"routeOnly": true,
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
]
}
}
]
}
Потом в v2rayN изменяю transport на xhttp, и в Path указываю /.
Ну и опять не работает. Чёт вообще этой темы не выкупаю.
В настройках клиента надо ещё flow сделать пустым вместо rprx-vision (вдруг забыли). А так должно работать
Да, надо было flow пустым сделать, теперь работает, спасибо.
Это не демаскирует клиента для провайдера?
Отключение flow xtls-rprx возвращает проблему tls-in-tls. Если транспорт xhttp ее не решает, то конечно демаскирует
Предположу, что не демаскирует, так как в xhttp работает мультиплексирование. Т.е. клиент смешивает в кучу все сессии, потом нарезает в n-ое количество уже новых сессий и уже на сервере собирает в нужную последовательность. Таким образом с одной стороны уменьшается количество открытых сессий, а с другой стороны это одновременно является идеальной маскировкой.
Но это лишь мое предположение, сам хочу получить ответ, прав ли я.
Я изучил все китайские посты и статьи по теме (которых к слову не особо много, все ссылки есть в этом треде), и по сути единственное упоминание tls-in-tls в контексте xhttp вот это:
(https://github.com/XTLS/Xray-core/discussions/4113#discussioncomment-11468947)
И, наконец, кульминация - еще одна новая эра: разделение исходящего и входящего трафика. Мы знаем, что сейчас GFW обнаруживает такие характеристики трафика, как TLS in TLS, основываясь на одном соединении. Таким образом, если мы разделим исходящий и входящий трафик на разные системы проверки, например, исходящий трафик будет идти через IPv4 TCP, а входящий - через IPv6 UDP, GFW не сможет сразу среагировать.
Т.е. да, по всей видимости tls-in-tls там присутствует, как в классическом vless без rprx-vision, а бороться с детектом они предлагают через разделение потоков на up и down и мультиплекс сессий. Видимо, xhttp изначально делался под использование именно с CDN на как миниум одном из потоков, а там rprx-vision всё равно применить никак нельзя. На всякий случай спросил у разработчиков ещё.
Собственно поэтому от идеи использовать xhttp с только прямым reality подключением я пока отказался. Сейчас удалось настроить более замороченные схемы по типу CDN_UP+REALITY_DOWN и CDN UP+DOWN через два разных домена, буду пока их тестировать.
Мультиплексирование не решает tls-in-tls, да
Можно примеры конфигурации сервера и клиента?
Я все конфиги взял отсюда:
Нужен nginx, да. В конфигурации клиентов раздел “sockopt” можно опускать, в блоке “extra” можно убрать всё кроме “downloadSettings”, если их нет - можно весь “extra” также опустить. (это написано там в комментах иероглифами, советую весь конфиг переводчиком с китайского тоже прогнать, чтобы комментарии были понятны)
Единственное, что я добавил от себя - конфиг клиента для cdn up/down на два домена:
//xhttp_cdn_up_down
{
"tag": "proxy",
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "domain1.com",
"port": 443,
"users": [
{
"id": "ваш_xhttp_id",
"encryption": "none"
}
]
}
]
},
"streamSettings": {
"network": "xhttp",
"security": "tls",
"tlsSettings": {
"serverName": "domain1.com",
"allowInsecure": false,
"alpn": ["h2"],
"fingerprint": "chrome"
},
"xhttpSettings": {
"host": "",
"path": "/ваш_xhttp_path",
"mode": "auto",
"extra": {
"downloadSettings": {
"address": "domain2.com",
"port": 443,
"network": "xhttp",
"security": "tls",
"tlsSettings": {
"allowInsecure": false,
"alpn": ["h2"],
"fingerprint": "chrome"
},
"xhttpSettings": {
"host": "domain2.com",
"path": "/ваш_xhttp_path",
"mode": "auto"
}
}
}
}
}
},
Тут “восходящий” поток идёт через domain1, а “нисходящий” через domain2. Оба домена приземляются на nginx через cdn.
И все-таки я продолжу предполагать, что xhttp закрывает проблему tls-in-tls, привел весь текст, но главное внизу выделил:
Try to understand the focus and logic of our series of protocols under XTLS. If you are wrong, please@RPRXCorrection.
The first generation of XTLS splice/direct/origin, etc. - solving performance:
traditional TLS over TLS will have two layers of encryption overhead, while XTLS directly and losslessly embeds/splices the inner TLS data into the outer TLS stream, making the surface It’s still single-layer TLS, but the proxy traffic is actually hidden. Reduce repeated encryption and decryption processes. The CPU load and encryption and decryption costs are significantly reduced without sacrificing security, thus improving performance.
VISION----Solution to TLS in TLS characteristics:
When multi-layer TLS is superimposed (TLS in TLS), there are two interactions between the inner TLS handshake and the outer TLS. This timing has obvious characteristics and can be accurately identified by GFW. The significance of VISION is to smooth out this unnatural timing characteristic by simulating delay and message exchange sequence, making the multi-layer TLS handshake process look closer to real Internet traffic and reducing the risk of being identified.
REALITY----Solving the SNI blocking problem:
Mainland China’s SNI cannot be encrypted, so GFW can identify and block it through SNI.
REALITY disguises itself in the TLS handshake and certificate delivery. By returning a certificate and initial data that looks like a real website in the handshake between the two parties, it is difficult to distinguish the authenticity of the entire TLS connection and the connection to the “big factory” HTTPS website. If GFW wants to block it, it needs to risk accidentally damaging the real website.
XHTTP - solves the common “single tunnel” feature of circumvention protocols:
traditional protocols (such as Shadowsocks, Vmess, Trojan, etc.) usually only encrypt data and continuously transmit it through a specific port, which can appear to be “stable and long-lasting” “Time encrypted flow” characteristics; reviewers can suspect that it is proxy traffic through statistical analysis, long connection characteristics, and data transmission patterns.
Therefore, XHTTP focuses on the application layer this time, further packaging the encrypted transmission into real HTTP requests and responses. By splitting the upstream data into multiple normal-looking POST requests and URLs with randomized parameters, the downstream data is disguised as large file streaming downloads or the continuous output of SSE (Server-Sent Events), which makes the traffic behavior different from that of ordinary users. The browsing and downloading patterns are very close. Compared with traditional “encrypted tunnels”, XHTTP is no longer a stable and continuous data pipeline, but is ostensibly composed of multiple independent, fragmented and natural HTTP interactions, more like common WEB access actions.
А какой CDN используете, Cloudflare или что-то еще? И что настраиваете на стороне провайдера?
А может кто-нибудь пожалуйста привести конфиг для 3xui с xhttp для двух reality сайтов (без воровства своего серта)
Вроде такое возможно или нет?
- Создаете новый inbound.
- Вводите порт 443, или другой, если этот у вас уже где-то занят.
- Выбираете в выпадающем меню Transmission XHTTP
- Выбираете Security Reality
- Вводите в Dest и SNI воруемый сайт.
- Получаете ключи кнопкой Get New Cert.
- Жмете Create.
- Экспортируете ключик в клиент.
Стоит уточнить, что клиентов, которые поддерживают xhttp можно пересчитать по пальцам. На винду, по-моему, только v2rayN
Cloudflare. Настройки базовые, просто заведён домен купленный на godaddy, в разделе DNS records создана AAAA запись указывающая на ipv6 адрес сервера, включено проксирование, в настройках кеширования всё отключено, в настройках SSL/TLS режим Full (strict). Для второго домена то же самое. В конфиге nginx нужно разумеется оба домена указать, у обоих выполняется grpc_pass на xhttp сокет, как в тех конфигах у китайцев:
server {
listen [ваш_ipv6_адрес]:443 ssl ipv6only=on http2 so_keepalive=on;
server_name domain1.com;
ssl_certificate /path/cloudflare_cert/domain1.com.pem;
ssl_certificate_key /path/cloudflare/domain1.com.key;
...
}
server {
listen [ваш_ipv6_адрес]:443 ssl ipv6only=on http2 so_keepalive=on;
server_name domain2.com;
ssl_certificate /path/cloudflare_cert/domain2.com.pem;
ssl_certificate_key /path/cloudflare/domain2.com.key;
...
}
Сертификаты для nginx берутся в панели cloudflare в разделе SSL/TLS → Origin Server → Origin Certificates
Можно обойтись и одним верхним доменом, использовать субдомены типа up.domain1.com и down.domain1.com, но целесообразность этого под вопросом.
если не разделять трафик на 4 и 6 то получается палево ?