Системные требования

Прежде чем планировать оборудование, зафиксируйте допущения. Приведённые ниже требования — это эксплуатационные базовые уровни, на которых строится здоровое окружение Ризомы.

Допущения о хостах

Каждый узел, шлюз и управляющий сервис работает на хостах Linux со стабильной сетевой доступностью и административным доступом для подключения. Платформа поставляется с пакетами для APT, DNF и YUM, юнитами systemd и установщиками, — поэтому узел присоединяется к mesh через свой пакетный менеджер и работает как полноценный сервис systemd, а регистрация релеев и статус обновлений обрабатываются в рамках жизненного цикла.

Подключённым агентам необходимы привилегии для открытия TUN-интерфейса и применения маршрутов — именно на этой поверхности ядра построен mesh.
Хосты должны быть синхронизированы по времени; mesh полагается на подписанные обмены с метками времени для защиты от повторов и аудита.
Обновляйте агенты с той же дисциплиной, что и патчи безопасности, — пиры работают лучше, когда весь mesh использует одно семейство версий.

Сеть и DNS

Собственный трафик mesh адресуется внутри 100.64.0.0/10 и никогда не требует публичных IP для маршрутов между узлами — QUIC работает поверх UDP через большинство NAT, а остальное покрывают релеи. Что действительно необходимо, — это владение именами DNS, которые вы публикуете:

Владение DNS для каждого публикуемого ingress, а также действительные сертификаты для этих имён.
UDP-доступность для QUIC между узлами (и в сторону релеев там, где прямые маршруты недоступны).
Правила межсетевого экрана, рассматривающие 100.64.0.0/10 как доверенный внутренний диапазон, — ничто иное не должно иметь возможность его имитировать.

Расчёт диапазона адресации

  mesh range:    100.64.0.0/10  (CGNAT space, reserved for private overlays)
  per node:      /32 assignment
  names:         <host>.rizoma.mesh   (Magic DNS, resolved inside the mesh)
  tunnel MTU:    1420
  transport:     QUIC over UDP (firewall-friendly, NAT-friendly)

Хранение данных и состояние

Сервисам с состоянием необходимо изолированное хранилище — отдельное от ОС и от других рабочих нагрузок, чтобы снапшоты и восстановления никогда не смешивали несвязанное состояние. Координатор хранит записи узлов, ACL, учёт релеев, события и снапшоты в SQLite или PostgreSQL; выбирайте PostgreSQL, когда необходимы координация нескольких инстансов или централизованный эксплуатационный инструментарий.

Хранилище S3 доступно только внутри mesh: эндпоинт — это mesh-IP узла на порту 9000, с областью действия 100.64.0.0/10, без публичного DNS-имени и без слушателя, обращённого в интернет. Планируйте резервные маршруты также внутри mesh — потоки снапшотов, а не публичные выгрузки.

Резервные копии — часть требований. Развёртывание, не способное восстановить состояние своего координатора, — это развёртывание, которое ещё не начиналось. Запланируйте покрытие снапшотами до подачи производственного трафика — порядок развёртывания описывает место резервных копий.

Разделение управления и рабочих нагрузок

В окружениях, чувствительных к безопасности, следует разделять сервисы control plane, релеи и клиентские рабочие нагрузки по отдельным хостам (или как минимум по отдельным доменам отказа). Релей, совмещённый с хостом клиентских рабочих нагрузок, становится одновременно узким местом пересылки и поверхностью атаки, — этим двум ролям нечего делать в одном ядре.

Та же логика применима к доступу: административный доступ для подключения должен быть ограничен каждым хостом и ротироваться как любые учётные данные. Когда хосты разделены, а доступ ограничен, страница «Политики zero-trust» описывает, как выразить это разделение политиками, а не надеждами.

Назад Architecture Overview Далее Deployment Flow