Обсуждение технологии xray и подобного

Ratiborus

Гуру форума
Администрация
Так получилось, что многие страны стали блокировать доступ к тем или иным ресурсам в сети. xray появился в Китае для обхода их "Великого Фаервола". У нас РосКомНадзор тоже занимается блокировками. Давайте здесь не будем писать о том какой РКН плохой и "рашка" говно. Мы живём в России и не называем свою страну оскорбительными именами. Иначе кто мы ?
Предлагаю здесь обсуждать саму технологию, другие технологии обхода блокировок.

Моё отношение к блокировкам РКН. Нужно блокировать тех кто несёт лживую информацию о стране, о её вооруженных силах. Вот только поменьше бы "перегибов" в процессе блокировок.
 
В панелях xray есть inbound, подключение. Сейчас на наших серверах каждый клиент имеет свой inbound. Но можно сделать и один inbound, и уже в нем создать подключения всех пользователей.
Например, создаем inbound с названием VLESS и размещаем там всех клиентов. У клиента будет идентификатор типа VLESS-yhgfdcv. Всё что после "-", идентифицирует клиента. Параметры соединения задаются при создании inbound.
В чем плюсы и минусы. При размещении клиентов на отдельном inbound, у них у каждого свой порт. Если все клиенты будут на одном inbound, у них у всех будет один порт, например 443, остальные порты VPS можно будет закрыть фаерволом.
Пишите свои соображения.

PS: Сейчас программа учета работает с inbound, может включать их, отключать, удалять. Но можно всё легко переделать для работы с клиентами внутри одного inbound, для меня это не проблема, API xray позволяет это сделать.
 
у тебя на 443-порту висит веб сервер NGIX и работает https-трафик весь. (собственно это часть маскировки под нормального клиента!)
я таких экспериментов ни разу не вытворял сам, но подозреваю, что вылезут конфликты и что-то точно отвалится и перестанет работать.
---
портов мало? цитата из гугла:
Количество портов ограничено с учётом 16-битной адресации (0-65536).
Все порты разделены на три диапазона — общеизвестные (или системные, 0—1023), зарегистрированные (или пользовательские, 1024—49151) и динамические (или частные, 49152—65535).

то есть в кол-во портов мы точно не упремся ибо не обладаем такой обширной клиентской базой, чтобы их все "забить".

к тому же ты неверно трактуешь работу инбаунда.
если 443 открыт ВСЕГДА снаружи и вовнутрь, то остальные порты (пользовательские) по умолчанию закрыты.
и открываются x-ui или ей подобными панелями при установке соединения с клиентом.
тут nmap в помощь для проверки этого утверждения. (но прошу иметь ввиду, что за сканирование сервера хостер может прибанить (если сканируем с него его самого же), такие виды активностей не относятся к разрешенным клиентами хостингов.)

вобщем смотрите мою подпись, там четко отражена моя позиция по этому вопросу.
"If it ain't broke don't fix it."

профитов от изменения логики работы я не вижу ни одного, а вот возможность заруинить все к чертям и майским жукам вполне реальная.
 
Всем привет, ох, даже незнаю стоит ли мне лезть в это "болото", интересно блин.
В клиенте v2rayng (не только в нем) есть такая настройка, смотрим скриншот.
Если мы пропишите там dns 8.8.8.8 то увидим следующее, на сайте по утечкам днс
Если оставим поле пустым, т.е. по умолчанию, программа будет использовать dns 1.1.1.1 и мы увидим изменения

Видим, что появились сервера cloudflare. Интересно вот что: если мы пропишим какой нибудь свой dns сервер в клиенте, как поведёт себя северная часть нашего vps. Мы знаем, что на немецком сервере прописаны гугл dns. Так вот сервер будет жёстко работать со своими прописанным днс , или будет приоритет по днс, который прислал приложение клиент, или приоритет по прописаным в сервер днс. Изложил как смог.
 
Последнее редактирование:
у дании по умолчанию ДНС клоуд флейр. они к нему ближе быстрее. (1.1.1.1)

у немца СТАТИЧЕСКИ прописаны днс гугла:
auto enp0s3
iface enp0s3 inet static
address 49.*.*.*
netmask 255.255.255.0
gateway *.*.1.1
dns-nameservers 8.8.8.8 8.8.4.4

в роутерах или софте обычно опрашивается первый в списке днс и если он отвечает - домен резольвится с него.
если с первым проблемы, берется вторичный и запрос посылается ему.
руками в данном случае ничего прописывать не нужно.
так вы только создаете "сборную солянку днс-ов" в случае их утечки в браузере, чем минусуете себе карму фингерпринта, вызывая дополнительное подозрение к клиенту.
 
Описанный мной эффект не был обнаружен в клиенте nekoray (windows) (крайней версии на текущий момент), хотя что-то там все таки происходит любопытное,
, но был обнаружен в клиентах, крайних версий на текущий момент (в том числе и pre-release), v2rayn (windows) и v2rayng (android). И как я понимаю, как раз таки, если в этих клиентах ничего не прописывать ручками (иммею ввиду днс), то они отсылают свой, зашитый в них по умолчанию, днс 1.1.1.1, что приводит, при использовании немецкого сервера, к "сборной солянке днс-ов", в случаи их утечки.
 
Последнее редактирование:
обычно в программах используется по умолчанию настройка "использовать днс удаленного сервера". (шлюза)
если настройка отличается - то это проблема программы и вопросы к ее автору.
---
прибивать гвоздями заранее определенные днс сервера (неважно какие) это дурной тон и некрофилия, что я осуждаю ><
 
у нас тут имеется один местечковый субпровайдер.
вот эти кретиноиды в бытность своего становления и бурного роста не задумывались о создании собственных ДНС-серверов, и поэтому всем клиентам в радиоточки доступа и роутеры тупо вбивали гугл+яндекс паблик днс-ы.
при этом они много раз меняли магистральных провайдеров.
на последний момент когда я видел у знакомого работу этого недо-прова фарш из трех ДНС-серверов выглядел ТАК: (лето 23-го года.)

причем гугл, стоящий первым резольвился не из рф, а из финлядии! адские пинги.
играть в какие либо онлайн игры невозможно от слова совсем.
у моего знакомого "пригорало" из за того, что у него "танки" имели такой инпут лаг к изображению на экране, что это даже слайдшоу нельзя назвать, это таймтрип какой то.
это лишь один из ярких примеров из моего сетевого экспириенся когда попадалось что-то сделанное раз и навсегда, что переставало работать как задумано.

p.s. мораль: не прибивайте гвоздями ДНС-настройки если не понимаете зачем вам это нужно! (порой это необходимо в некоторых сценариях использования).
 
"Поигрался" я тут с маршрутизацией и пришел к кое-каким выводам.
На клиенте nekoray проверялось на обоих движках (xray, sing box), на клиенте v2rayn только на движке xray,
на v2rayng (android) выбора нет, только xray. Описанный выше эффект с днс-сами, назовем солянкой.

Проявляется эта солянка, в случаях когда мы начинаем использовать доменную стратегию IpOnDemand (эффект сработает сразу если есть правило на основе ip),

а также IpIfNonMatch если присутствуют какие-то правила роутинга и по домену и по ip(эффект сработает если есть просто правило на основе ip). Стратегия работает своеобразно, вот тут подробней расписано.

Но если мы будем использовать доменную стратегию AsIs то такого эфекта уже не будет.

Тоесть че получается, если нам нужно отрезольвить какие-то свои правила маршрутизации то подключается еще один днс, который в клиентах v2rayn (ng) по умолчанию 1.1.1.1, а в клиенте nekoray по умолчанию 8.8.8.8. Если кто то заморачивается со всей это маршрутизацией будте аккуратней.
Приведенные выше примеры соответсвуют движку xray, для движка sing box ситуация аналогична, только название доменной стратегии выглядит как use ipv4 и т.п.
 
Последнее редактирование:
Размышления: доменная стратегия IpIfNonMatch адекватней работает в клиенте V2rayN до тех пор
пока вы не задействуйте глобальное правило по портам
Код:
[
  {
    "id": "*******",
    "port": "0-65535",
    "outboundTag": "proxy",
    "ip": [],
    "domain": [],
    "process": [],
    "enabled": true
  }
]
В nekoray возможно придется вручную править конфигурацию, чтобы стратегия заработа как надо. Хотя на текущий момент тут xray ядро старее, может в нем дело.
Вот тут немного инфы. На синг бокс ядре работает норм, в актуальной на текущий момент версии
Не претендую на истину в последней инстанции, может кому то поможет двигаться в правильном направлении.
 
Последнее редактирование:
Назад
Верх Низ