А, ладно, но судя по названиям параметров, эти соединения переиспользуются? Я хз, доки ужасные у xhttp
Навайбкоди пхп скрипт который будет добавлять нужные параметры
Если указать stream-one или хотя бы stream-up, тоже плодит?
Будет плодить на любом режиме, если жестко не задать maxConnections.
Блин, реально. Для сервера из ~10 устройств 1500 соединений. Режим не форсируется, только себе ставлю stream-one, у остальных auto, плюс клиент (приложение) неадевкатный может быть (не v2rayn[g]).
А в каком статусе большинство соединений? ESTABLISHED или TIMEWAIT?
Можно попробовать в самой системе поиграться параметрами
net.ipv4.tcp_fin_timeout
net.ipv4.tcp_max_tw_buckets
net.ipv4.tcp_tw_reuse
ESTABLISHED
Подскажите такой вопрос. У меня сейчас БС VPS, и доступ к ней по XHTTP+Reality. Мимикрию под како-то сайтец из БС не самый раскрученный. Но, как я понял, SNI не проверяется у нас, только CIDR блокировка. Соответственно, хотелось бы самоподписанный сертификат поставить (это self-steal называется, да?), чтобы даже домен не покупать, устал я их покупать и следить за обновлением certbot’a. Умеет так делать транспорт XHTTP? Потому что я не понял, документация его ужасна, и там написано что с Vision он не дружит. А в этой ветке вроде пишут что так можно. Короче запутался я. Может кто скинет ссылку на конфиг примерный, если не трудно, сильно бы помогло. С XHTTP+свой сертификат я бы поставил в настройках клиента ip адрес сервера и указал нужный sni, тогда и DNS на клиенте не нужен чтобы резолвить адрес сервера - надежно и просто.
Reality мне прям не нравится, что создает траффик на тот сайт под который я мимикрирую. Это же фигово.
С другой стороны оно защищает от active probing, но будут ли его применять? А даже если актив пробинг, а у меня самоподписанный сертификат, что они будут делать в этом случае? Сижу вот думаю, какой конфиг оптимальнее, чтобы дольше проработала VPS’ка.
xhttp умеет и в секурити ноне
xhttp - это транспорт, передающий данные за счет http запросов и мимикрирующий под статистическое поведение http,.а tls - обертка для транспорта.
SNI является понятием TLS, вне TLS оно не существует
xhttp к tls имеет отношение как килограммы к метрам
например, у меня эндпоинтом выступает веб сервер nginx на своем домене,
а в секретном URI grpc pass на xray . в нем xhttp и security “none”.
потому что обертку TLS делает nginx
но если не нужно ничего “менеджерить” на 443 порту, можно слушать и прямо из xray на 443. и тогда нужен security TLS. к нему, соответственно, подтягивается желаемый сертификат, вместо nginx. хоть валидный, хоть self-signed
но полноценный nginx лучше для актив пробинг, потому что это реальный веб сервер. xray не может его сэмулировать, разве что куда-то проксить еще на существующий сайт. но если это свой сайт на том же хосте, то не лучше ли вперед вывесить его, а не xray ?
TLS handshake - полностью аутентичный веб сайт nginx на своем домене
без стила откуда-либо. зачем у себя воровать ?
Нет. Самоподпис серт это тобою лично созданный сертификат (а не полученный из lets encrypt), он не будет принят нигде кроме твоего компа. self-steal это маскировка xray reality под свой же сайт (на одном и том же айпи адресе и сайт и реалити)
Что-то пока не заводится у меня XHTTP с nginx’ом.
Сейчас на 443 порту стоит Xray в конфигурации XHTTP+Reality. Работает хорошо.
Установил nginx. Настроил его на 8443 порт.
server {
listen 8443 ssl http2 reuseport;
server_name XYZ.ru;
ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
client_header_timeout 5m;
keepalive_timeout 5m;
root /var/www/html;
index index.html;
location / {
try_files $uri $uri/ =404;
}
location = /robots.txt {
default_type text/plain;
return 200 "User-agent: *\nDisallow: /\n";
}
location /SECRET {
grpc_buffer_size 16k;
grpc_socket_keepalive on;
grpc_read_timeout 1h;
grpc_send_timeout 1h;
grpc_set_header Connection "";
grpc_set_header X-Real-IP $remote_addr;
grpc_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
grpc_set_header X-Forwarded-Proto $scheme;
grpc_set_header X-Forwarded-Port $server_port;
grpc_set_header Host $host;
grpc_set_header X-Forwarded-Host $host;
grpc_pass unix:/dev/shm/xray_xhttp.sock;
}
}
В браузере index.html открывается на порту 8443.
Добавлю в xray новый inbound:
{
"listen": "/dev/shm/xray_xhttp.socket,0666",
"protocol": "vless",
"settings": {
"clients": [
{
"id": "ID",
"email": "route@direct"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "xhttp",
"xhttpSettings": {
"mode": "stream-one"
}
}
}
и тишина…
На клиенте outbound натроен так (используется не самая последняя версия, где еще не выпилили allowInsecure):
{
"tag": "proxy",
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "x.x.x.x",
"port": 8443,
"users": [
{
"id": "ID",
"security": "auto",
"encryption": "none"
}
]
}
]
},
"streamSettings": {
"network": "xhttp",
"security": "tls",
"tlsSettings": {
"allowInsecure": true,
"serverName": "XYZ.ru",
"alpn": [
"h2"
],
"fingerprint": "chrome"
},
"xhttpSettings": {
"path": "/SECRET",
"host": "XYZ.ru",
"mode": "stream-one"
}
},
"mux": {
"enabled": false,
"concurrency": -1
}
}
Может какую-то очевидную ошибку допустил?
Тут они должны совпадать - первое, что в глаза бросилось
Лучше всего запускать xray от www-data, чтобы не давать 666. www-data - юзер nginx
Или замутить что-то с группой
Чтобы проверить доходит ли дело до xray, можно сделать strace -fp $(pidof xray)
Если при дергании там молчок, то не доходит.
Если посыпались сисколлы - доходит
Спасибо всем за советы, они пригодились.
В итоге после упорной диагностики удалось заставить работать XHTTP позади nginx.
Подсвечу основные моменты.
В конфиге nginx:
server {
listen 8443 ssl http2;
server_name XYZ.com;
ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
root /var/www/html;
index index.html;
client_header_timeout 5m;
keepalive_timeout 5m;
location = /robots.txt {
default_type text/plain;
return 200 "User-agent: *\nDisallow: /\n";
}
# ! секция с SECRETPATH должна идти перед секцией на все остальные пути "/"
location /SECRETPATH/ {
client_max_body_size 0;
client_body_timeout 1w;
grpc_read_timeout 1w;
grpc_pass unix:/dev/shm/xray_xhttp.socket;
}
location / {
try_files $uri $uri/ =404;
}
}
В конфиге Xray:
"inbounds": [
{
"listen": "/dev/shm/xray_xhttp.socket,0666",
"protocol": "vless",
"settings": {
"clients": [
{
"id": "UUID",
"email": "route@direct"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "xhttp",
"xhttpSettings": {
"mode": "stream-one",
"path": "SECRETPATH" # ! здесь обязательно указывается SECRETPATH
}
}
}
],
Права на сокет выставляется корректно, Nginx может работать с сокетом от юзера nobody с выставленными в конфиге Xray правами.
Теперь осталось понять какие оптимальные настройки по таймаутам и прочему в Nginx, но здесь трудно из-за хреновой справки по XHTTP, когда же они ее допилят..
В режиме stream-one я наблюдаю столько соединений:
# ss -tn state established '( dport = :8443 or sport = :8443 )'
Recv-Q Send-Q Local Address:Port Peer Address:Port Process
0 0 X.X.X.X:8443 Y.Y.Y.Y:2465
0 0 X.X.X.X:8443 Y.Y.Y.Y:2485
0 0 X.X.X.X:8443 Y.Y.Y.Y:2523
0 0 X.X.X.X:8443 Y.Y.Y.Y:2504
0 0 X.X.X.X:8443 Y.Y.Y.Y:2467
0 0 X.X.X.X:8443 Y.Y.Y.Y:2450
0 0 X.X.X.X:8443 Y.Y.Y.Y:2513
0 0 X.X.X.X:8443 Y.Y.Y.Y:2474
0 0 X.X.X.X:8443 Y.Y.Y.Y:2500
0 0 X.X.X.X:8443 Y.Y.Y.Y:2508
0 0 X.X.X.X:8443 Y.Y.Y.Y:2461
0 0 X.X.X.X:8443 Y.Y.Y.Y:2503
0 0 X.X.X.X:8443 Y.Y.Y.Y:2448
0 0 X.X.X.X:8443 Y.Y.Y.Y:2458
0 0 X.X.X.X:8443 Y.Y.Y.Y:2499
0 0 X.X.X.X:8443 Y.Y.Y.Y:2505
0 0 X.X.X.X:8443 Y.Y.Y.Y:2473
0 0 X.X.X.X:8443 Y.Y.Y.Y:2501
0 0 X.X.X.X:8443 Y.Y.Y.Y:2487
0 0 X.X.X.X:8443 Y.Y.Y.Y:2446
0 0 X.X.X.X:8443 Y.Y.Y.Y:2452
0 0 X.X.X.X:8443 Y.Y.Y.Y:2507
0 0 X.X.X.X:8443 Y.Y.Y.Y:2509
0 0 X.X.X.X:8443 Y.Y.Y.Y:2455
# ss -tan | grep :8443 | awk '{print $1}' | sort | uniq -c
24 ESTAB
1 LISTEN
Это адекватно для stream-one? Конфигурация XHTTP по умолчанию.
Надо на клиенте в xhttpSettings добавить доп. настройки:
"xmux": {
"maxConcurrency": 0,
"maxConnections": 1,
"cMaxReuseTimes": 0,
"hMaxRequestTimes": "600-900",
"hMaxReusableSecs": "1800-3000",
"hKeepAlivePeriod": 0
}
Сколько maxConnections поставите, столько и будет соединений.
А возможны подобные реализации с другими веб серверами, или nginx единственный вариант для взаимодействия с xhttp?
Подойдёт любой веб-сервер, поддерживающий ту или иную форму reverse proxy.
А какая нужна? У меня, например, не завелось в связке с lighttpd. Не исключаю что у меня мозгов не хватает, вот и решил спросить у тех кто уже более менее с опытом;)