Одна из задачь VLESS это прикидываться настоящим, но при этом чужим web сайтом, он умеет это делать на 443 порту под https. Однако большинство сайтов всегда имеют поддержку http и https, на 80 и 443 порту соответсвенно. Обычно сервер настроен так, что бы производить переадресацию, или если вам угодно редирект c http на https, чтобы всегда обсуживать клиента с шифрованием. Надо, чтобы xray-core тоже умел это делать, это возможно? Закрытый 80 порт на таком прокси, уже может вызвать подозрение, а если таким способом будут по быстрому “пробивать” подозрительные ip?
Я решил эту проблему перенаправлением портов на маскировочный IP:
- В коммандах ниже заменить эти переменные на свои:
222.222.222.222 - чужой IP, который мы используем для маскировки с помощью Reality
111.111.111.111 - IP нашего сервера
ens3 - интерфейс, через который наш сервер выходит в интернет
- Установим файервол в лице iptables и модуля для сохранения правил после перезагрузки (если ещё не установлены):
apt update
apt install iptables iptables-persistent
- Перенаправим траффик с нашего 80 порта (стандартный для http) на чужой IP, который используем для Reality:
iptables -t nat -A PREROUTING -i ens3 --dport 80 -j DNAT --to-destination 222.222.222.222:80
iptables -t nat -A POSTROUTING -o ens3 -d 222.222.222.222 --dport 80 -j SNAT --to-source 111.111.111.111
- При необходимости (если чужой IP так же слушает на UDP 443) перенаправяем и его:
iptables -t nat -A PREROUTING -i ens3 -p udp --dport 443 -j DNAT --to-destination 222.222.222.222:443
iptables -t nat -A POSTROUTING -o ens3 -p udp -d 222.222.222.222 --dport 443 -j SNAT --to-source 111.111.111.111
- Сохраняем правила, что бы они не сбрасывались после перезагрузки сервера:
iptables-save > /etc/iptables/rules.v4
- Отредактируем sysctl.conf для разрешения перенаправления:
nano /etc/sysctl.conf
Ищем параметр
#net.ipv4.ip_forward=0
И приводим его к следующему виду (декомментируем и активируем)
net.ipv4.ip_forward=1
Нажимаем Ctrl+X, Y, Enter
- Сохраняем настройки и перезапускакм сервер:
sysctl -p && reboot
- В браузере переходим по http://111.111.111.111 если открывается сайт, под который мы маскируемся, то всё отлично и перенаправление портов настроено правильно.
В клиенте в flow есть возможность переключать режимы xtls-rprx-vision и xtls-rprx-vision-udp443 судя по названию можно предположить, что xray может гонять трафик и по UDP, а если это так, то может не стоит вмешиваться в маршрутизацию и перенаправлять UDP, который может надобиться xray?
Данные настройки можно выполнить с помощью firewall-cmd?
Работает только в том случае, если на сервере настроена работа по UDP вместо TCP, без этого коннекта не будет. Да и смысла кмк в этом нет, ибо теряется преимущество маскировки под обыкновенный HTTPS сайт.
Для UDP трафика есть настройка XUDP (включена в XRAY по умолчанию, в клиентах на Sing-Box зачастую приходится включать вручную), которая позволяет гонять UDP трафик поверх TCP. Не так эффективно, как голый UDP, зато позволяет работать UDP-only приложениям (вроде той же голосовой связи в Discord).
Если на 443 / UDP ничего не настроено, то вреда как такового не будет, но и пользы, в случае если маскировочный IP не слушает на 443 / UDP.
Насчёт firewall-cmd не подскажу, но уверен что настроить можно и алгоритм действий будет похожим, нужно только видоизменить команды.
Для работы нужен включенный ip forward
Нет, прочитайте доки xray. Vision по умолчанию блокирует udp на 443 port для блокировки quic (для ускорения работы и возможно приватности), vision-udp443 разрешает quic, но идти он будет все равно поверх tcp
Кстати да, забыл упомянуть, благодарю. Поправлю пост.
Хм, интересно… А чем это тогда отличается от XUDP? Разная реализация одного и того же?
packetaddr/xudp не связаны с vision, они нужны для fullcone nat, udp трафик будет проходить и без них
А возможно ли реализовать тоже самое ресурсами самого xray-core или может быть кто то знает наверняка, что на текущий момент это технически нереализуемо? Это могло бы быть немного проще, маскировка ради xray-core через его же config. Разумеется в ОС разблокировать 80 порт, если фаерволом он закрыт.
приделайте снизу nginx c redirect, это проще всего. тут не плохо пример хоть и усложнённый.
Да ставить веб сервер из за такой мелочи, как то слишком “громозко”, тем более если можно обойтись без него, если действительно можно…
Но всё равно спасибо и за эту инфу, и за предыдущие которые были представлены другими участниками - тоже.