Комментарии 19
Эээээ, это законно?
Неплохой был сервис ☠☠☠
Если ты используешь vless reality, то NAT на русском узле в перспекииве плохое решение, если у тебя этот промежуточный узел на впс хостинге в РФ, а xray при хендшейке отдает, скажем гугл или что то из белого списка sni, то когда ркн неизбежно сделает актив пробинг или как то еще начнет проверять что там живет на порту, то согласись, что гугловый серт на дешевом русском впс хостинге будет выглядеть странно.
Я бы вместо NAT поставил nginx и разруливал трафик по апстримам на уровне L4, то есть без терминирования tls, по sni. Нужный sni в xray, а остальные в заглушку, на которой повесить серт на свой домен, нахрен никому не нужный.
Если ты используешь vless reality, то NAT на русском узле в перспекииве плохое решение
у меня на том узле vless + tcp + tls
xray при хендшейке отдает, скажем гугл или что то из белого списка sni,
у меня маскировка под свой полноценный сайт, который на тех же хостах лежит. И сертификат, разумеется, настоящий, на этот сайт
Но в любом случае спасибо за рекомендации
Здорово! Но один 443 порт. Вообще да, изобретён обычный релей на ядре линукс.
Как только начались ковровые блокировки ip адресов подключил релей пробросил все протоколы histeria2, Reality, Grpc, также подписки и Telemt, обратный прокси, плюс еще пару серверов.
В статье:
Биллинг работает следующим образом: раз в минуту скрипт запрашивает через Xray API статистику трафика каждого пользователя (uplink и downlink) и сравнивает полученные значения с предыдущими. Если за минуту объём переданных данных превысил заданный порог, пользователь считается активным и с его баланса списывается одна минута. Если трафика не было или его объём оказался ниже порога, время не списывается.
На сайте в FAQ:
Прошу исправить или стать или сайт, у вас противоречие поповоду того как вы считаете минуты. И еще, если вы используете протоколы Xray то добавьте в инструкцию по настройке на сайте клиенты с открытым исходным кодом которые есть на https://f-droid.org/ параноики будут работы у вас что-то купить.
А в чем прелесть для тех, кому оно нужно стабильно и постоянно? 1000 часов - чуть меньше полутора месяцев, за год "онлайн" 8760. Упоминаний скидок больше 1000 не нашел, ссылка ведет на чат с поддержкой.
Или я что-то не понимаю?)
Хм, интересно, насколько это эффективно проходиться по всем пользователям раз в минуту 🤔
Подключился, поставил уже на android, сейчас пойду ставить на mac, и windows
Но мне показалось, что Xray на промежуточном узле здесь лишний.
А как у Вас с точки зрения отказоустойчивости? Две фатальные точки отказа: входящий сервер в России и входящий сервер за границей. В случае падения хотя бы одного из них, Ваш сервис перестает работать целиком, клиенты негодуэ, требуют вернуть деньги, скандалы, интриги, расследования. Как сделать правильно: точка входа в России, на ней крутится XRAY, работающий как балансир. За границей два промежуточных сервера и два выходных. И опять внезапно на всех стоят XRAY, балансирующие трафик. Это равномерное распределение нагрузки и, в случае выхода одного промежуточного и даже всех выходных серверов, клиенты ничего не замечают и есть время быстро сервера поменять / восстановить. Обязательно все 4 сервера в разных датацентрах. А еще, в Вашей схеме весь ru-available-only-inside трафик идет на зарубежный выходной сервер. Так как клиенты с маршрутизацией трафика на устройствах ни разу не заморачиваются, у них не открываются Озоны, Вбшки, Госуслуги, а Ваш выходной сервер неизбежно получает черную метку от РКН. Оно как бы пофиг, но лучше не надо. Чтобы это победить нужен более другой выходной сервер в России, куда первый сервер будет заворачивать российский трафик. В коммерческом продакшене, я бы поставил два таких сервера (в разных датацентрах) в целях отказоустойчивости. Для личного использования, оверхед, но в коммерческом проекте мастхев, я считаю. Так что XRAY ни разу не лишний на входе.
Скрытый текст
> точка входа в России, на ней крутится XRAY,
На узле, принадлежащем хостреру с русской юрисдикцией никогда, ни под каким видом не должно терминироваться шифрование трафика.
И никаких логов
Никакой узел в рф не должен работать как выходной для росс трафика, можно делать split tunnel на клиенте, но выпускать трафик с узла в рф это значит засветить себя лично или свое юрлицо, смотря на кого оформлен узел.
Открываем антифрод 3 и оцениваем риски.
Если делать коммерческий сервис, вообще не стоит иметь дело с хостингами где есть оплата за рубли.
Всё так, вы правильно говорите.
Я тоже к этой же мысли пришёл, так как в будущем будут палить развёрнутое ядро XRay (не важно, какой обвязки), тупо отгрепав вывод top и docker ps по ключевым словам. И шифрование volume'ов и оперативки почти бесполезно, спасёт только от ленивого админа на гипервизоре. Или просто тупо будут смотреть на зеркальность трафик - если трафик как две капли воды похож и на RX, и на TX, то вот тебе бан, юзер хостинга.
Сейчас, конечно, ядра XRay, которые работают и на вход, и на выход, и как цепочка - развёрнуты везде, и в мире, и в РФ. Теперь для локации РФ придётся думать, чем "импортозаместить" хотя бы переброс трафика зарубеж.
А чем заменить-то это, в итоге? На РФ сервере тупо перенаправлять трафик через IPTables, лол? Других решений я придумать не могу.
А чем заменить-то это, в итоге? На РФ сервере тупо перенаправлять трафик через IPTables, лол? Других решений я придумать не могу.
Я выше написал. Nginx который разруливает tcp streams по sni, не терминируя тоннель. Нужный sni отравляет на узел с Xray а все остальное на себя в заглушку. И, разумеется, надо нужный sni подобрать так, чтобы он соответствовал АС. Хапрокси тоже самое может.
Проблему соответствия rx/tx мне кажется элементарно решить, любым генератором нагрузки.
Кстати я не думаю, что хостеры будут прям усердствовать в поиске проксей, снапшоты ковырять, делать им нечего, это же выстрел в ногу себе. Я предполагаю все же, что баны будут по комплаенсу из ркн.
А по каким показателям вы оценивали, что модель себя оправдала? Хороший вышел случай для анализа удержания: человек может несколько месяцев не пополнять баланс, но продолжать пользоваться сервисом как резервным. По повторным покупкам он будет выглядеть потерянным, хотя причин уходить у него нет.
Отдельно ли вы смотрите возвращаемость к использованию и повторные пополнения? Ведь для двух описанных групп и интервалы оценки нужны разные: неделя без подключений к основному впн и к резервному не одно и то же.
Хотелось бы ознакомиться с первой частью статьи, но КГБ РКН не дремлет.
Не публиковались ли где-нибудь в самиздате? 🤔
Если что, я не для товарища майора, я с целью познания... 😁
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я свой VPN-сервис развивал