415 lines
14 KiB
Markdown
415 lines
14 KiB
Markdown
# 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.
|