Remnawave: архитектура панели, ноды и безопасная эксплуатация

Remnawave — система управления инфраструктурой на базе Xray-core, в которой панель, база данных и рабочие ноды разделены на самостоятельные компоненты. Такая архитектура удобна для централизованного администрирования, но требует больше дисциплины, чем один сервис на одном сервере: появляются секреты между узлами, отдельные домены, резервные копии PostgreSQL и дополнительные сетевые границы.

Правовой и этический дисклеймер. Эта статья рассматривает Remnawave как серверное программное обеспечение: архитектуру, развёртывание компонентов, защиту панели, мониторинг и восстановление. Материал не рекламирует услуги доступа, не описывает обход ограничений и не содержит готовых пользовательских конфигураций. Используйте технологии только в собственной инфраструктуре и в соответствии с законом, договором с провайдером и правилами подключённых сетей.

Цель — не получить работающую кнопку любой ценой, а понять, какие данные и соединения нужно защищать до запуска системы.

Из каких компонентов состоит Remnawave

Основной компонент — Panel. Он управляет пользователями, нодами, конфигурациями и служебными данными. Панель использует PostgreSQL и запускается вместе с необходимыми сервисами через Docker Compose. Рабочая нода размещается отдельно и выполняет сетевую конфигурацию Xray-core, полученную от управляющего контура.

Упрощённая схема:

Администратор → HTTPS → Reverse proxy → Remnawave Panel → PostgreSQL
                                         │
                                         ├→ Node A → Xray-core
                                         ├→ Node B → Xray-core
                                         └→ метрики и журналы

Такое разделение помогает централизовать управление, но панель становится критической системой. Потеря её базы или секретов затрагивает все связанные ноды. Поэтому резервное копирование и изоляция должны появиться раньше рабочих объектов.

Официальный код и актуальная документация находятся в репозитории Remnawave и на сайте проекта. Не копируйте compose-файлы из случайных сборок: переменные и структура компонентов меняются между версиями.

Panel и Node — не одно и то же

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

Плюсы отдельной панели:

• единая точка управления несколькими нодами;
• централизованная база и аудит;
• рабочие серверы не обязаны публиковать административный интерфейс;
• ноду можно обслуживать независимо от frontend.

Минусы:

• больше контейнеров и сетевых связей;
• отдельная PostgreSQL;
• секреты взаимодействия Panel и Node;
• зависимость от DNS, TLS и reverse proxy;
• более сложное восстановление.

Для одного личного стенда компактная панель может быть проще. Если сравниваете подходы, прочитайте материал 3x-ui для администратора.

Что нужно подготовить до установки

До запуска контейнеров определите:

1. отдельный домен для административной панели;
2. домен публичной страницы подписки, если она действительно нужна вашему внутреннему сценарию;
3. адреса и зоны размещения нод;
4. способ резервного доступа к серверам;
5. место хранения шифрованных копий;
6. окно обновлений и порядок отката;
7. ответственного за ключи и токены.

Не начинайте с публикации всех портов. Сначала нарисуйте потоки: кто обращается к панели, как панель связывается с нодой, куда отправляются метрики и где находится база.

Docker Compose — это не граница безопасности

Контейнеры упрощают доставку компонентов и воспроизводимость версий, но сами по себе не изолируют плохо настроенный сервис от интернета. Опубликованный порт остаётся опубликованным, а секрет в файле .env остаётся секретом, который нужно защищать.

Официальная инструкция Remnawave требует привязывать внутренние сервисы к 127.0.0.1 и использовать reverse proxy. Это принципиально: PostgreSQL, внутренний backend и метрики не должны быть доступны из произвольной сети.

Проверьте compose-конфигурацию на три типа ошибок:

• порт опубликован на 0.0.0.0 вместо localhost;
• каталог с базой или секретами имеет слишком широкие права;
• используется плавающий тег образа без зафиксированной версии и плана обновления.

После запуска сравните ожидаемые порты с фактически слушающими. Docker способен добавлять сетевые правила, которые администратор не заметит при беглом просмотре обычного firewall.

Секреты в .env

Remnawave использует несколько секретов для аутентификации и внутренних функций. Официальная инструкция отдельно требует сгенерировать APP_SECRET, METRICS_PASS и WEBHOOK_SECRET_HEADER, а также заменить пароль PostgreSQL.

Правила обращения с .env:

• генерируйте каждый секрет независимо;
• не используйте примеры из документации как реальные значения;
• ограничьте чтение файла владельцем сервиса;
• не добавляйте .env в Git;
• не отправляйте файл целиком в чат или тикет;
• учитывайте секреты в процедуре резервного копирования;
• планируйте ротацию и последствия замены каждого значения.

Изменение секрета может разорвать связь компонентов. Не ротируйте всё одновременно: сначала зафиксируйте зависимости и подготовьте проверку после каждого шага.

Reverse proxy для панели

Reverse proxy должен быть единственной публичной точкой входа к веб-интерфейсу. Он завершает TLS, перенаправляет запросы на localhost и создаёт отдельный журнал доступа.

Минимальные требования:

• действующий HTTPS-сертификат;
• закрытый прямой порт backend;
• корректные заголовки Host и адреса клиента;
• лимит размера запросов;
• разумные тайм-ауты;
• ограничение административного домена по адресам или закрытой сети, если это возможно;
• отдельная защита от перебора учётных данных.

Не используйте один и тот же виртуальный хост для панели, метрик и тестовых страниц. Разные домены и явные маршруты уменьшают вероятность случайно открыть внутренний endpoint.

Первый super-admin

В Remnawave первый зарегистрированный пользователь становится super-admin. Это удобный старт и одновременно чувствительный момент.

Создавайте первого пользователя сразу после запуска, пока доступ к панели разрешён только с административного адреса. После этого проверьте, что свободная регистрация не оставлена доступной по ошибке. Используйте уникальный пароль и отдельную административную учётную запись, не совпадающую с повседневными сервисами.

Если применяется вход через внешнего поставщика OAuth, оценивайте новую зависимость: кто контролирует приложение, какие callback-адреса разрешены и что произойдёт при недоступности поставщика. Не добавляйте OAuth только ради красивой кнопки входа.

Безопасное подключение нод

Нода должна доверять только своей панели, а панель — только ожидаемой ноде. Защитите канал управления и не публикуйте служебные токены.

Перед добавлением ноды проверьте:

• сервер обновлён и имеет корректное время;
• SSH доступен по ключам;
• рабочий и административный трафик разделены правилами;
• внутренний API не открыт всему интернету;
• секрет создан специально для этой связи;
• имя ноды не раскрывает персональные данные или точный адрес;
• мониторинг отличает недоступность ноды от недоступности панели.

Добавляйте по одной ноде и проверяйте её состояние до перехода к следующей. Массовое подключение скрывает ошибки DNS, времени и firewall за общим симптомом «ничего не работает».

PostgreSQL и резервное копирование

Для Remnawave база — центральная часть восстановления. Копии одного compose-файла недостаточно. Нужны логический дамп PostgreSQL, файл переменных, конфигурация reverse proxy и список используемых версий.

Практичная политика:

• ежедневный автоматический дамп базы;
• шифрованная копия вне основного сервера;
• ограниченный срок хранения;
• контроль успешного завершения задания;
• регулярное тестовое восстановление;
• отдельная копия перед каждым обновлением.

Не считайте размер файла доказательством исправности. Проверяйте, что дамп читается и разворачивается в чистую базу. Тест выполняйте в изолированной среде без подключения к рабочим нодам, чтобы восстановленная панель не начала отправлять им старую конфигурацию.

Что восстанавливать и в каком порядке

После аварии порядок важнее скорости:

1. подготовить чистую ОС и Docker;
2. восстановить зафиксированные версии образов;
3. вернуть секреты и настройки доменов;
4. поднять PostgreSQL;
5. восстановить базу;
6. запустить backend и frontend;
7. проверить вход и целостность данных;
8. только после этого разрешить связь с одной тестовой нодой;
9. подключать остальные ноды по очереди.

Не направляйте рабочий DNS на новую панель до проверки миграций базы и совместимости версий. Старая база с новым приложением иногда требует необратимого обновления схемы.

Обновления без сюрпризов

У Remnawave активно развиваются панель, frontend и ноды. Читайте руководство по обновлению именно для установленной ветки, а не случайную инструкцию годичной давности.

Перед обновлением сохраните:

• дамп PostgreSQL;
• текущий compose-файл;
• .env и права на него;
• версии всех образов;
• конфигурацию reverse proxy;
• список активных нод;
• результат последней проверки здоровья.

После обновления проверяйте не только страницу входа. Нужны состояние миграций, связь с нодами, метрики, ошибки backend и срок действия TLS-сертификата.

Если новая версия требует изменить переменные окружения, добавляйте их осознанно. Слепая замена рабочего .env новым sample-файлом способна удалить старые обязательные параметры или секреты.

Метрики, API и webhooks

Служебные интерфейсы часто оказываются опаснее панели, потому что их забывают закрыть. METRICS_PASS и WEBHOOK_SECRET_HEADER должны быть уникальными, а endpoint — доступным только ожидаемым системам.

Для API используйте минимальные права и отдельные токены для разных интеграций. Не отдавайте super-admin токен боту, которому нужно только прочитать состояние ноды. Если токен оказался в журнале, скриншоте или репозитории, считайте его скомпрометированным и замените.

Webhook должен проверять секрет до обработки данных. Ограничение по IP полезно как дополнительный слой, но адрес источника может меняться, а доверие к заголовку без правильного reverse proxy создаёт ложную защиту.

Наблюдаемость без сбора лишнего

Полезный мониторинг отвечает на вопросы:

• доступна ли панель из административного контура;
• соединены ли ноды с управляющей системой;
• не растут ли ошибки PostgreSQL;
• хватает ли диска для базы и журналов;
• создан ли свежий дамп;
• не истекает ли сертификат;
• не появились ли новые публичные порты;
• не изменились ли версии контейнеров без запланированного обновления.

Не собирайте полные конфигурации и пользовательские секреты в общей системе логирования. Для диагностики обычно достаточно идентификатора компонента, времени, кода ошибки и обезличенного контекста.

Когда Remnawave избыточен

Распределённая система имеет смысл, когда действительно нужны несколько нод, единый контроль и отдельный жизненный цикл компонентов. Для одного тестового сервера она добавляет PostgreSQL, reverse proxy, домены и больше секретов.

Выбирайте Remnawave, если готовы обслуживать:

• отдельную базу;
• контейнеры нескольких компонентов;
• TLS и DNS;
• связь панели с нодами;
• регулярные миграции;
• резервное восстановление.

Если задача укладывается в небольшой личный стенд, сначала оцените более компактную архитектуру. Но независимо от панели общие правила одинаковы: минимальная публикация портов, стабильные версии и резервные копии.

Техническую основу Xray без рекламного контекста разбирает статья VLESS как туннель между своими проектами.

Чек-лист перед вводом в эксплуатацию

• Panel, PostgreSQL и метрики не опубликованы напрямую.
• Reverse proxy принимает HTTPS и проксирует только нужные маршруты.
• Первый super-admin создан из доверенной сети.
• Все стандартные секреты заменены случайными уникальными значениями.
• .env исключён из Git и закрыт правами.
• Каждая нода имеет понятную границу доступа.
• IPv4 и IPv6 проверены с внешней машины.
• Версии контейнеров зафиксированы.
• Дамп PostgreSQL создаётся автоматически.
• Тестовое восстановление выполнено без связи с рабочими нодами.
• API, метрики и webhooks защищены отдельными секретами.
• Журналы ротируются и не содержат ключей.

Итог

Remnawave стоит рассматривать как управляющий контур, а не просто веб-страницу над Xray-core. Надёжность зависит от разделения Panel и Node, закрытых внутренних портов, защищённого .env, PostgreSQL-копий и контролируемых обновлений.

Сначала обеспечьте восстановление и минимальную поверхность атаки, затем подключайте рабочие ноды по одной. Такая последовательность полезна для любой распределённой панели и не зависит от конкретного сетевого сценария.