Архитектура Server Monitor Manager

1. Выбранная топология

Первый рабочий вариант использует один Mesh Hub на Linux-сервере с белым IP. Остальные узлы не требуют входящего публичного порта и устанавливают исходящее WireGuard-соединение с Hub.

Windows client -- ограниченный SSH --> Mesh Hub (публичный UDP)
                                            ^
                                            |
                                исходящие WireGuard-туннели
                                            |
                           AI-agent / Home / Server2 / ...

Hub выполняет две разные функции:

control plane первого MVP: список узлов, политики Links и команды управления через ограниченный SSH forced-command;
data plane первого MVP: маршрутизация WireGuard-трафика с обязательной фильтрацией nftables.

Это осознанная звёздная топология. Прямые peer-to-peer соединения, relay и отказоустойчивый второй Hub не входят в первый MVP.

2. Текущий переходный режим

Windows client

Packaged WinUI 3 приложение хранит профили серверов локально, создаёт отдельную Ed25519 identity мониторинга и вызывает только разрешённые SSH-команды. Клиент показывает snapshot метрик, узлы Mesh и направленные Links.

SSH monitoring endpoint

На Hub и Node создаётся непривилегированный пользователь ochenstarik-monitor. Его ключ привязан к root-owned forced-command и не даёт shell, PTY или forwarding. В текущем протоколе доступны metrics и ограниченные команды mesh на Hub.

Mesh Hub

Hub хранит:

публичные WireGuard identities узлов;
выданные внутренние адреса;
желаемое и фактическое состояние Links;
политики CIDR, протокола, порта и TTL;
журнал управляющих операций.

Приватный WireGuard-ключ каждого Node создаётся на самом Node и никогда не передаётся Hub. Временный enrollment token не является ключом узла.

Node

Node устанавливает исходящее WireGuard-соединение с Hub. Входящий публичный порт не нужен. Node применяет выданную конфигурацию, подтверждает её версию и хранит приватный ключ с правами 0600.

3. Метрики

Текущий SSH snapshot содержит CPU/load, память, корневой диск, uptime и задержку. Следующая версия добавляет swap, inode, сетевые счётчики и выбранные systemd units.

Постоянный Linux agent появится после стабилизации трёхсерверного сценария. Он будет отправлять метрики исходящим mTLS-соединением, вести ограниченный локальный буфер и не открывать публичный API.

4. Links между серверами

Link — направленный ресурс:

Draft -> Connecting -> Active -> Disconnecting -> Disabled
                   \-> Partial
                   \-> Failed
Active -> Expired -> Disabled

Каждый Link содержит:

source и destination;
разрешённый IP или CIDR;
протокол TCP/UDP и список портов;
ручной режим или TTL;
причину, владельца и запись аудита;
версию политики и подтверждение применения.

Пустая политика не означает allow all. Ответный трафик существующего соединения разрешается stateful-правилом, обратное новое соединение требует отдельного Link.

При Disconnect Hub сначала блокирует направление в nftables, затем фиксирует Disabled. Если подтверждение узла недоступно, интерфейс показывает Partial, а обязательное состояние применяется после reconnect.

5. Сценарий AI-агента

На целевом сервере создаётся отдельный Unix-пользователь, например ai-agent-dev, без root-доступа.
Рабочие каталоги и команды ограничиваются Unix-правами, группами, контейнером или sandbox-профилем.
Создаётся Link от узла с AI-агентом к целевому адресу и только необходимому SSH-порту.
AI-агент использует отдельную SSH identity, не ключ мониторинга приложения.
Пользователь включает Link на ограниченное время и после работы отключает его.

6. Следующий control layer

После проверки текущей топологии SSH-команды управления заменяются небольшим control service:

SQLite для инвентаря, политик, истории и аудита;
одноразовая enrollment-регистрация;
исходящие mTLS-сессии агентов;
WebSocket/stream событий для desktop client;
idempotency key и защита от replay.

Hub остаётся маршрутизатором Mesh первого поколения. Разделение control plane и data plane возможно позже без изменения модели направленных Links.

Первый реализованный срез control layer использует ASP.NET Core 10 и SQLite. Hub выдаёт агенту сертификат по CSR только после атомарного погашения десятиминутного token. После регистрации Agent выполняет только исходящие HTTPS-запросы с mTLS, а Hub связывает thumbprint сертификата с конкретным node_id. Heartbeat содержит idempotency key и отклоняется при попытке повторить тот же ключ с другим телом запроса.

Сейчас этот срез сохраняет inventory, heartbeat-метрики, idempotency и аудит регистрации. Перенос политик Links из файлов в SQLite, постоянный event stream и локальный буфер Agent выполняются следующими частями этапа.

7. Целевые ограничения MVP

без Kubernetes и обязательного Docker;
отсутствие публичного agent API;
вторичные серверы работают без белого IP;
50–100 узлов на одном небольшом Hub;
Node agent: idle RAM до 50 МБ и CPU менее 1%;
команды не повторяются без idempotency key;
потеря истории метрик не должна приводить к потере управления Links.

7.9 KiB Raw Blame History Unescape Escape