rmm-openwrt/ROADMAP.md

OpenWrt RMM Roadmap

Цель

Создать RMM-платформу для удаленного мониторинга и управления устройствами на OpenWrt: роутерами, шлюзами, точками доступа и небольшими edge-устройствами.

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

Основные принципы

• Устройство само устанавливает исходящее соединение с сервером.
• Агент должен быть легким и совместимым с ограниченными ресурсами OpenWrt.
• Все команды должны быть проверяемыми, журналируемыми и ограниченными по правам.
• Конфигурация OpenWrt должна изменяться через штатные механизмы: uci, ubus, init scripts, opkg.
• MVP должен быть простым, но архитектурно не мешать переходу к production-уровню.

Целевая архитектура

Agent

Компонент, устанавливаемый на OpenWrt-устройство.

Обязанности:

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

Server

Центральный backend для управления устройствами.

Обязанности:

• учет организаций, пользователей и устройств;
• прием heartbeat и метрик;
• хранение состояния устройств;
• очередь команд;
• аудит действий;
• API для web UI;
• интеграции с уведомлениями.

Web UI

Панель оператора.

Обязанности:

• список устройств и их состояние;
• карточка устройства;
• просмотр интерфейсов, Wi-Fi, DHCP leases, маршрутов и системных метрик;
• запуск разрешенных команд;
• управление конфигурацией;
• просмотр логов и истории действий;
• алерты и уведомления.

Этап 0: Подготовка проекта

Цель: зафиксировать базовую структуру и технические решения.

Задачи:

• выбрать основной стек для server и web UI;
• выбрать формат агента для MVP: shell, Go или Rust;
• описать модель устройств и команд;
• определить минимальный набор поддерживаемых версий OpenWrt;
• описать threat model;
• подготовить структуру репозитория.

Результат:

• базовая документация;
• структура директорий;
• черновой API-контракт;
• список ограничений MVP.

Этап 1: MVP Agent

Цель: получить минимальный агент, который может зарегистрироваться, отправлять состояние и выполнять безопасные команды.

Функции:

• конфигурационный файл агента;
• уникальный device id;
• enrollment token;
• heartbeat;
• сбор базовых данных:
  • hostname;
  • OpenWrt version;
  • uptime;
  • load average;
  • memory usage;
  • disk usage;
  • network interfaces;
  • default route;
  • WAN IP;
• выполнение базовых команд:
  • ping target;
  • traceroute target;
  • reboot;
  • service restart;
  • opkg list-installed;
• отправка результата команды на сервер.

OpenWrt-интеграции:

• ubus call system board;
• ubus call system info;
• uci show;
• ip addr;
• ip route;
• /etc/init.d/*;
• opkg.

Результат:

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

Этап 2: MVP Server API

Цель: реализовать backend, достаточный для работы агента и первой панели управления.

Функции:

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

Основные сущности:

• organization;
• user;
• device;
• device enrollment;
• device heartbeat;
• command;
• command result;
• audit event.

Результат:

• REST API или WebSocket API для агента;
• REST API для UI;
• хранилище данных;
• минимальная авторизация.

Этап 3: MVP Web UI

Цель: сделать рабочую панель оператора.

Функции:

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

Результат:

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

Этап 4: Безопасность

Цель: довести базовую модель безопасности до уровня, пригодного для реального использования.

Задачи:

• mTLS или подписанные device tokens;
• ротация токенов устройства;
• подпись команд;
• allowlist команд на агенте;
• RBAC для пользователей;
• per-organization isolation;
• audit log для всех операторских действий;
• rate limits;
• защита от replay-атак;
• secure enrollment flow.

Результат:

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

Этап 5: Управление конфигурацией OpenWrt

Цель: перейти от диагностических команд к управляемым изменениям конфигурации.

Функции:

• чтение UCI-конфигурации;
• безопасное изменение UCI-секций;
• preview diff перед применением;
• apply/commit/revert workflow;
• управление Wi-Fi SSID;
• управление firewall rules;
• управление DHCP;
• управление static routes;
• backup текущей конфигурации;
• восстановление конфигурации.

Результат:

• оператор может менять типовые настройки OpenWrt без ручного SSH.

Этап 6: Мониторинг и алерты

Цель: добавить наблюдаемость и уведомления.

Метрики:

• online/offline;
• uptime;
• load average;
• memory usage;
• disk usage;
• WAN status;
• interface errors;
• Wi-Fi clients;
• DHCP leases;
• packet loss;
• latency to configured targets.

Алерты:

• устройство offline;
• WAN down;
• высокая нагрузка;
• мало памяти;
• мало места на диске;
• потеря VPN;
• частые перезагрузки.

Интеграции:

• email;
• Telegram;
• Slack;
• webhook.

Результат:

• система не только показывает состояние, но и сообщает о проблемах.

Этап 7: Remote Access

Цель: обеспечить безопасный удаленный доступ к устройствам и сервисам за ними.

Возможности:

• reverse tunnel;
• временный SSH-доступ через сервер;
• browser-based terminal;
• TCP port forwarding;
• доступ к LuCI через tunnel;
• ограничение доступа по времени и пользователю;
• запись audit events для сессий.

Результат:

• оператор может попасть на устройство без проброса портов и публичного IP.

Этап 8: Обновления и пакеты

Цель: управлять установленными пакетами и обновлениями.

Функции:

• список установленных пакетов;
• доступные обновления;
• установка пакета;
• удаление пакета;
• обновление package lists;
• staged upgrade;
• контроль совместимости;
• запрет опасных операций без подтверждения;
• история изменений пакетов.

Результат:

• управление пакетами становится частью RMM-процесса.

Этап 9: Fleet Management

Цель: управление группами устройств.

Функции:

• группы устройств;
• теги;
• массовые команды;
• шаблоны конфигурации;
• политики;
• rollout с лимитами;
• canary-группы;
• отчет о применении изменений.

Результат:

• система подходит не только для одного роутера, но и для парка устройств.

Этап 10: Production Hardening

Цель: подготовить систему к эксплуатации.

Задачи:

• structured logging;
• metrics для server;
• health checks;
• backup/restore базы данных;
• миграции схемы данных;
• horizontal scaling;
• graceful shutdown;
• retry policies;
• disaster recovery plan;
• нагрузочное тестирование;
• e2e-тесты agent-server;
• package build для OpenWrt.

Результат:

• систему можно разворачивать и поддерживать в production-среде.

Предлагаемая структура репозитория

rmm-openwrt/
  agent/
    README.md
    openwrt/
    scripts/
    package/
  server/
    README.md
    cmd/
    internal/
    migrations/
  web/
    README.md
    src/
  docs/
    architecture.md
    api.md
    security.md
    openwrt.md
  ROADMAP.md

MVP Scope

Минимальный полезный продукт должен включать:

• agent enrollment;
• heartbeat;
• basic inventory;
• device list;
• device detail page;
• command queue;
• command result;
• basic audit log;
• allowlist команд;
• offline detection.

Что сознательно не входит в первый MVP:

• полноценный remote shell;
• массовые rollout-операции;
• сложный RBAC;
• управление firmware upgrade;
• полноценный tunnel к LuCI;
• multi-region deployment.

Открытые вопросы

• Какой стек использовать для backend: Go, Node.js/TypeScript или другой?
• Агент MVP делать на shell или сразу на Go?
• Нужен ли self-hosted-only вариант или SaaS-модель с multi-tenant архитектурой?
• Какие версии OpenWrt поддерживать первыми?
• Нужна ли интеграция с LuCI или отдельный UI будет основным интерфейсом?
• Какой транспорт выбрать для агента: polling HTTPS, WebSocket или MQTT?
• Нужно ли поддерживать устройства за CG-NAT без постоянного соединения?

Ближайший следующий шаг

Сформировать техническое решение для MVP:

• выбрать стек;
• описать API agent-server;
• создать структуру репозитория;
• реализовать первый вертикальный сценарий:
  • агент регистрируется;
  • агент отправляет heartbeat;
  • UI показывает устройство online.