Xray с XTLS-Reality и Nginx на одном порту | Мини-блог

[utterances-bot]

Xray с XTLS-Reality и Nginx на одном порту | Мини-блог

Что делаем? Настроим так чтобы на одном порту 443 висел и nginx с нашими сайтами и xray XTLS-Reality, который работает как прокси для авторизованных пользователей и притворяется валидным сайтом (в примере www.google.com)

https://coyotle.ru/posts/xray-and-nginx/

[Ysery]

Здравствуйте. Спасибо за инструкцию. Но у меня возникла проблема - в логах при обращении к сайту(ам) IP адреса посетителей определяются как 127.0.0.1 Как это исправить? Я всю голову сломал уже...

[Ysery]

Таки нашёл решение, используя proxy_protocol. Вот как это выглядит в конфиге.

...
upstream xray {
    server 127.0.0.1:8050;
}

upstream www {
    server 127.0.0.1:7443;
}

server {
    listen          443;
    proxy_pass      $sni_name;
    proxy_protocol on;
    ssl_preread     on;
}

    server {
        listen 8050 proxy_protocol;
        proxy_pass 127.0.0.1:8443;
    }

Не забудьте также в блоке слушателей сайта указать

    listen 7443 ssl proxy_protocol;
    listen [::]:7443 ssl proxy_protocol;

И в блоке http вот это надо прописать.

http {
   # Включаем поддержку реального IP
    set_real_ip_from 127.0.0.1;   #Доверяем локальному прокси
    real_ip_header proxy_protocol;   #Используем заголовок для получения реального IP клиента (чтобы в логах именно он и прописывался)
...

Принцип прост: в просушиваемый на 443 порту TCP трафик добавляется заголовок с IP адресом при передаче слушателю на сервере. А чтобы отключить такое поведение для трафика, что передаётся на xray, он проходит через ещё один сервер, где заголовки эти удаляются. Уточню на всякий случай, что указывать надо поддержку proxy_protocol только для соответствующего слушающего порта (блок слушателей сайта). Для остальных это делать не надо, включая quic, который работает на 443 порту, но по UDP и, соответственно, никак не мешает слушателю в блоке stream, который оперирует только TCP.

[coyotle]

@Ysery спасибо за коммент, может кому-то пригодится

[MrEagle123]

@Ysery У вас решение для сайтов. А вот XRAY продолжит в своих логах access.log и error.log писать IP посетителя XRAY как 127.0.0.1. Пока не нашёл решение этого вопроса...

[Ysery]

@MrEagle123 Да, суть была - обеспечить контроль сайта. А уж вероятность несанкционированного доступа к xray стремится к нулю, так что я даже не задумывался над этим. Однако в тот момент, когда я искал решение, я выяснил, что оказывается сам xray может проксировать трафик. В этом случае в его логах наверняка будут реальные IP, а вот способ передачи от xray реального IP для проксируемого на сайт трафика я не нашёл. И это при том, что xray поддерживает входящий трафик с proxy_protocol , за это отвечает опция acceptProxyProtocol: true. Я в свете выясненной информации хотел включить поддержку proxy_protocol, дабы дополнительно не направлять трафик на прописанный в конфиге Nginx дополнительный server, задача которого сводится по сути лишь к очистке от заголовков proxy_protocol и дальнейшей передачи трафика на xray. Но у меня не получилось. В итоге я плюнул и оставил как есть.

[MrEagle123]

@Ysery Получается, что в XRAY не передаются IP-адреса пользователей и в нём нельзя настроить ограничение по количеству подключенных IP для каждого пользователя.

[slva2000]

Спасибо за статью. Вот вариант конфига, более продвинутый: https://github.com/chika0801/Xray-examples/blob/main/VLESS-Vision-REALITY/nginx_sni_shunting/nginx.conf

[slva2000]

А как обновить Xray-core и есть ли в этом смысл?

[coyotle]

@slva2000 я периодически скачиваю последний релиз отсюда https://github.com/XTLS/Xray-core/releases и распаковываю Xray-linux-64.zip поверх предыдущей версии. Периодически стоит обновляться, бывают исправлени и улучшения

[b1ack4x]

Хорошо бы то же самое, но в Докере. Почему? Потому что, раз уже мы купили VPS, то есть смысл его юзать по-полной. Т.е. навешать пачку полезных сервисов. Бложик, например. Под него, кстати, и маскироваться самое парвильное. Соответсвтенно, нужен и XUI в Докере, а не на хосте.

[coyotle]

Хорошо бы то же самое, но в Докере. Почему? Потому что, раз уже мы купили VPS, то есть смысл его юзать по-полной. Т.е. навешать пачку полезных сервисов. Бложик, например. Под него, кстати, и маскироваться самое парвильное. Соответсвтенно, нужен и XUI в Докере, а не на хосте.

@b1ack4x а как эта схема мешает вешать что-то еще на vps? Тут как раз речь о том как сделать чтобы работали и сайты обслуживаемые nginx (или чем-то еще), и xray. Просто добавь нужные тебе upstream и всё.

У меня сейчас xray работает именно в докере, но без панели, она мне не нужна.

docker-compose.yaml

services:
  xray:
    image: teddysun/xray:24.10.16
    restart: unless-stopped
    ports:
      - "127.0.0.1:8443:8443"
    volumes:
      - ./config.json:/etc/xray/config.json

/etc/nginx/stream-enabled/proxy

map $ssl_preread_server_name $sni_name {
    hostnames;

    # local services
    example.ru           www;
    *.example.ru         www;
    default              xray;
}

upstream xray {
    server 127.0.0.1:8443;
}

upstream www {
    server 127.0.0.1:7443;
}

server {
    listen          443;
    proxy_pass      $sni_name;
    ssl_preread     on;
}