diff --git a/docs/learn/life-after-3x-ui.md b/docs/learn/life-after-3x-ui.md new file mode 100644 index 0000000..b2ecdec --- /dev/null +++ b/docs/learn/life-after-3x-ui.md @@ -0,0 +1,389 @@ +--- +sidebar_position: 3 +title: Жизнь после 3X-UI +--- + +# Как жить с Remnawave после перехода с 3X-UI? + +Этот небольшой гайд направлен на то, чтобы вы смогли понять **ключевые архитектурные отличия Remnawave** от панели **3X-UI** (и её форков), а также перестроить мышление после перехода на новую модель управления. + + + +--- + +## Как это выглядело в 3X-UI + +После установки **3X-UI** вам обычно не требуется никаких дополнительных настроек. +Типичный сценарий работы: + +1. Устанавливается панель +2. Создаётся инбаунд (host / inbound) +3. Внутри инбаунда создаётся пользователь +4. Копируется ссылка — клиент может подключаться + +На старте такой подход кажется простым, понятным и удобным. + +Однако есть важный нюанс: в 3X-UI пользователь создаётся **внутри конкретного инбаунда**. +Если одному пользователю требуется доступ к нескольким инбаундам, его нужно вручную создавать в каждом из них отдельно. + +Это не всегда заметно сразу, но начинает создавать неудобства по мере роста конфигурации и количества серверов. + +### Почему так работает? + +Потому что ядро **XRAY уже встроено в панель 3X-UI**. +Устанавливая 3X-UI, вы сразу получаете: + +- панель управления +- ядро XRAY +- конфигурацию и обработку трафика в одном месте + +С одной стороны — это просто и доступно. +С другой — именно здесь скрыта основная проблема. + +--- + +## Основная проблема архитектуры 3X-UI + +Проблемы начинаются, когда вам нужно: + +- несколько серверов +- разные локации (EU, RU, US и т.д.) +- масштабирование проекта +- разделение нагрузки + +В этот момент у вас практически нет гибких вариантов. + +Единственное решение: +установить **полную копию 3X-UI на каждый сервер**. + +### Чем это плохо + +- на каждой ноде разворачивается целая панель +- пользователи дублируются +- конфигурации нужно синхронизировать вручную +- обновления превращаются в боль +- любая ошибка масштабируется вместе с инфраструктурой + +Формально это работает, +но каждая новая нода = новая головная боль. + +--- + +## Какое решение предлагает Remnawave? + +Решение довольно простое: +**разделить ответственность компонентов**. + +--- + +## Архитектурный подход Remnawave + +Remnawave полностью изолирует: + +### Панель + +Панель отвечает только за управление: + +- пользователи +- инбаунды +- хосты +- подписки +- статистика и учёт трафика + +### Ноды + +Ноды отвечают только за обработку трафика: + +- ядро XRAY +- сетевые подключения +- реальный выход в интернет + +Именно это является ключевым отличием Remnawave и других панелей, которые не являются форками 3X-UI. + +--- + +## Что вы видите после установки Remnawave + +После установки Remnawave в браузере перед вами **просто панель управления**. + +Внутри панели **нет ядра XRAY**. + +Это означает: + +- какие бы конфиги XRAY вы ни редактировали, +- как бы ни пытались подключиться напрямую — + +подключения не будет, потому что подключаться просто некуда. + +И это нормально. + +--- + +## Что нужно сделать дальше? + +Нужно развернуть дополнительный компонент — +**Remnawave Node (Remnanode)**. + +Именно в ноде: + +- находится ядро XRAY +- принимаются подключения клиентов +- обрабатывается весь трафик + +Панель управляет, +ноды работают. + +--- + +## Можно ли ставить панель и ноду вместе? + +Технически — да. + +Но: + +- это плохая практика +- это небезопасно +- это ломает саму идею архитектуры + +Учитесь разделять: + +- административные ресурсы +- публично доступные ресурсы + +Если всё же очень нужно, существуют установочные скрипты, которые позволяют развернуть панель и ноду на одном сервере за несколько кликов, иногда даже с готовым конфигом. + +--- + +## Термины Remnawave: хосты, инбаунды, пользователи + +### Какая перед нами задача? + +Дать клиенту: + +- один сервер + **или** +- список серверов + +к которым он сможет подключаться из своего приложения. + +--- + +## Как это устроено в Remnawave + +Конечный пользователь получает **URL**, который называется **подпиской**. + +В подписке: + +- содержится список хостов +- именно к ним клиент и подключается + +--- + +## Инбаунды + +Инбаунд — это сущность из конфигурации ядра XRAY. + +Обычно он включает: + +- протокол +- методы шифрования +- network / security +- sniffing и другие параметры + +В актуальной версии Remnawave инбаунды больше не создаются «руками» в интерфейсе ноды. +Панель работает через **Профили конфигураций (Config Profiles)**, которые описывают полный конфиг Xray для группы нод, включая список инбаундов. + +Основные моменты: + +- инбаунды определяются внутри профиля конфигурации +- панель считывает инбаунды из профиля и отображает их как доступные сущности +- при изменении профиля пересобирается список инбаундов, а перезапускаются только ноды, использующие этот профиль + +Рекомендуется изучить официальную документацию XRAY, чтобы уверенно работать с этой частью. + +--- + +## Хосты + +Когда у вас есть готовый инбаунд, +к нему создаётся **хост**. + +В хосте указывается: + +- адрес (IP или домен) +- порт (обычно соответствует порту инбаунда) +- инбаунд, к которому он привязан + +Важно: в адресе указывается **нода**, а не панель. +Если нода и панель находятся на одном сервере — тогда да, адрес совпадает. + +Хост — это финальная сущность, которую: + +- видит пользователь +- использует клиентское приложение +- реально использует для подключения + +--- + +## Профили конфигураций (Config Profiles) + +В Remnawave все инбаунды объединены в **Профили конфигураций**. + +Профиль конфигурации: + +- содержит полный конфиг ядра Xray (inbounds, outbounds, routing и т.д.) +- может быть назначен нескольким нодам +- определяет, какие инбаунды вообще доступны для этих нод + +Главные эффекты: + +- вы редактируете конфиг один раз на уровне профиля, а не на каждой ноде +- при изменении профиля перезапускаются только ноды, которые его используют + +На уровне ноды вы выбираете: + +- какой профиль конфигурации она использует +- какие инбаунды из этого профиля будут активны именно на этой ноде + +Профиль задаёт «множество возможных» инбаундов, а нода включает только нужные ей. + +--- + +## Внутренние сквады: доступ пользователей к инбаундам + +### Что такое внутренние сквады + +**Внутренние сквады (Internal Squads)** — это группы доступа для пользователей. +Если профили конфигураций описывают поведение нод, то внутренний сквад описывает, **какие инбаунды доступны конкретным пользователям**. + +Внутренний сквад позволяет: + +- выбрать любые инбаунды из доступных профилей конфигураций +- задать, к каким протоколам, локациям и серверам получат доступ участники сквада + +Один пользователь может одновременно состоять в нескольких внутренних сквадах, что даёт гибкую модель прав. + +--- + +### Как внутренняя логика заменяет старую систему + +Раньше доступ пользователя к нодам и инбаундам задавался напрямую через связки вида «пользователь → инбаунд/нода». +Это было плохо масштабируемо и неудобно при большом количестве пользователей и конфигураций. + +Теперь используется двухступенчатая модель: + +1. **Ноды ↔ Профили конфигураций** + - профиль определяет набор инбаундов и общую логику работы Xray + - нода выбирает профиль и активные инбаунды из этого профиля + +2. **Пользователи ↔ Внутренние сквады ↔ Инбаунды** + - сквад определяет набор инбаундов, доступных участникам + - пользователь получает доступ ко всем инбаундам, включённым во все сквады, в которых он состоит + +В результате: + +- вы больше не привязываете пользователя вручную к конкретной ноде или инбаунду +- вы мыслите группами: «обычные пользователи», «премиум», «тестеры», «RU», «EU» и т.д. +- чтобы изменить права, достаточно отредактировать сквад или членство пользователя в нём + +--- + +### Практические сценарии внутренних сквадов + +Примеры: + +- **Regular** + - ограниченный набор инбаундов (пара стабильных RU/EU серверов) + - все новые пользователи автоматически попадают сюда + +- **Premium** + - расширенный набор инбаундов (больше локаций, отдельные быстрые ноды, экспериментальные маршруты) + - при апгрейде тарифа пользователя просто добавляют в этот сквад + +- Сквады по регионам + - отдельные сквады для специфичных стран/регионов + - один пользователь может одновременно быть, например, в скваде EU и Premium + +Такой подход превращает изменение логики доступа в несколько кликов по сквадам, без массовой ручной правки связок «пользователь–инбаунд». + +--- + +## Пользователи и подписки + +Когда: + +- создан профиль конфигурации и нужные инбаунды +- нодам назначены профили и включены нужные инбаунды +- для этих инбаундов созданы хосты +- настроены внутренние сквады с нужными инбаундами +- пользователь добавлен в один или несколько сквадов + +можно выдавать пользователю подписку. + +При создании пользователя: + +- ему назначаются один или несколько внутренних сквадов +- автоматически формируется подписка, которая включает только те хосты и инбаунды, к которым у него есть доступ через эти сквады + +Подписка — это ссылка, которую нужно вставить в совместимое приложение (например, **Happ**). +После этого пользователь видит все доступные ему хосты и может к ним подключаться. + +--- + +## Отличия подписок: Remnawave vs 3X-UI + +### Remnawave + +Remnawave выдаёт **одну универсальную подписку**, которая: + +- автоматически подстраивается под клиент +- формируется под нужное ядро +- работает без дополнительных действий со стороны пользователя + +Поддерживаются: + +- XRAY (JSON / links) +- Sing-box +- Mihomo (Clash Meta) +- Stash + +Пользователю не нужно выбирать тип подписки. + +--- + +### 3X-UI + +В 3X-UI: + +- существуют разные ссылки: + - обычная base64-подписка + - JSON-подписка +- отсутствует выдача подписок под Sing-box +- нет поддержки Mihomo + +Пользователь должен сам понимать: + +- какую ссылку +- в какое приложение +- и зачем вставлять + +Это создаёт лишнюю сложность и для пользователя, и для администратора. + +--- + +## Итог + +**Remnawave**: + +- построен на разделении ролей (панель ↔ ноды) +- использует **Профили конфигураций** для управления конфигами Xray и инбаундами +- использует **Внутренние сквады** как основную модель управления доступом пользователей +- хорошо масштабируется и не требует дублирования панелей +- выдаёт универсальные подписки и поддерживает современные клиенты и ядра + +**3X-UI**: + +- удобен на старте +- архитектурно ограничен +- плохо масштабируется +- становится проблемным при росте проекта