# Архитектура Server Monitor Manager ## 1. Выбранная топология Первый рабочий вариант использует один **Mesh Hub** на Linux-сервере с белым IP. Остальные узлы не требуют входящего публичного порта и устанавливают исходящее WireGuard-соединение с Hub. ```text 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. При потере Hub он сохраняет атомарный root-only буфер: последние точки остаются с полной детализацией, старые группы уплотняются с сохранением наиболее важного пика. Размер очереди ограничен, а подтверждённые Hub точки удаляются строго по порядку. ## 4. Links между серверами Link — направленный ресурс: ```text 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 heartbeat устанавливает долговечный marker в SQLite, Hub повторно применяет последнюю эффективную отключённую политику и снимает marker только после успешного подтверждения firewall. При перезапуске Control Hub незавершённый marker сохраняется. ## 5. Сценарий AI-агента 1. На целевом сервере создаётся отдельный Unix-пользователь, например `ai-agent-dev`, без root-доступа. 2. Рабочие каталоги и команды ограничиваются Unix-правами, группами, контейнером или sandbox-профилем. 3. Создаётся Link от узла с AI-агентом к целевому адресу и только необходимому SSH-порту. 4. AI-агент использует отдельную SSH identity, не ключ мониторинга приложения. Отдельный mTLS-сертификат Automation привязан к source Node и позволяет читать только его эффективные Link-grants; он не открывает трафик и не изменяет Links. 5. Пользователь включает 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 и отклоняется при попытке повторить тот же ключ с другим телом запроса. Control Hub сохраняет inventory, heartbeat-метрики, направленные Links, idempotency и аудит в SQLite. Желаемое состояние отключения Link фиксируется до вызова ограниченного nftables wrapper; при ошибке фактическое состояние становится `Partial`. Отдельная mTLS identity `Operator` читает inventory, управляет Links и получает NDJSON event stream, сертификат `Agent` ограничен heartbeat собственного `node_id`, а `Automation` — чтением эффективных Link-grants одного закреплённого source Node. Agent использует ограниченный долговечный буфер и повторяет доставку с тем же idempotency key. Hub принимает накопленные точки только в настроенном временном окне и сохраняет исходное время измерения. Event stream уже подключён к WinUI. ## 7. Целевые ограничения MVP - без Kubernetes и обязательного Docker; - отсутствие публичного agent API; - вторичные серверы работают без белого IP; - 50–100 узлов на одном небольшом Hub; Control/SQLite путь проверяется CI-сценарием со 100 одновременно активными Node; - Node agent: idle RAM до 50 МБ и CPU менее 1%; - команды не повторяются без idempotency key; - потеря истории метрик не должна приводить к потере управления Links.