utterances-bot commented 3 weeks ago

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

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

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

Ysery commented 3 weeks ago

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

Ysery commented 3 weeks ago

Таки нашёл решение, используя 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 commented 3 weeks ago

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

MrEagle123 commented 6 days ago

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

Ysery commented 6 days ago

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

MrEagle123 commented 6 days ago

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

slva2000 commented 4 days ago

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

coyotle / minimal-blog

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

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