# 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-среде. ## Предлагаемая структура репозитория ```text 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.