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.
|