2026 OpenClaw MeshMac на практике: мультиузловой шлюз, fail-closed прокси, патчи по белому списку, JSON от validate и минимальный патруль дрейфа

Единый источник правды отсутствует. Инженер правит один Mac, чтобы разблокировать CI, и не промотирует тот же пакет gateway.proxy.yaml на остальные узлы пула.

Переопределения вне репозитория. LaunchAgent, профили shell или локальные plist подмешивают endpoint прокси и не попадают в ревью политики.

Частичный отказ без остановки трафика. Узел с проваленным validate продолжает отвечать клиентам — в логах это похоже на «битый» upstream, хотя причина — расщепление политики между шлюзами.

Управление таким дрейфом — это не разовый аудит, а непрерывное согласование артефактов и вывода validate после каждого изменения, с владельцем выката и записью в журнал смен.

В линии 2026.4.x акцент смещён на прокси-рантайм: любое расширение исходящих целей или канала доставки патча должно быть либо заранее перечислено в политике, либо приведёт к отказу процесса стартовать. Это сознательно «неудобно» для срочных правок вручную на одном узле — зато команда видит одинаковое поведение на всех шлюзах и может автоматизировать сравнение JSON без ручного чтения десятка файлов. Для совместной работы закрепите правило: нет merge в канал выката без артефакта и номера policy_revision, который уже прошёл validate на стенде с тем же составом белых списков, что ожидается в продакшене.

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

1. Зафиксировать Node LTS. На каждом хосте класса gateway выполните node -v и выберите одну линию — например Node 22.x или Node 20.x — на весь пул. Разные major меняют стек TLS и телеметрию, что маскируется под «дрейф прокси».

2. Одна сборка шлюза. Установите OpenClaw из одного внутреннего канала или tarball с закреплённым хешем; зафиксируйте вывод openclaw version в тикете изменения.

3. Контрольная точка отката A — до правок.

mkdir -p .meshmac-checkpoints/2026-04-25-gateway
cp gateway.proxy.yaml .meshmac-checkpoints/2026-04-25-gateway/
cp com.openclaw.gateway.plist .meshmac-checkpoints/2026-04-25-gateway/ 2>/dev/null || true

4. Блок в духе 2026.4.x. Установите proxy.runtime.fail_closed: true, явно перечислите allowed_patch_channels и allowed_upstream_hosts, отключите wildcard URI динамической перезагрузки. Неизвестные ключи и ошибки разбора трактуйте как запрет старта, а не «предупредить и продолжить». Учёт токенов и привязок к мессенджерам сверьте с материалом канал тревоги, ротация токенов и минимальные права.

5. Doctor и строгий validate в JSON.

openclaw gateway doctor --json | tee /tmp/gw-doctor.json
openclaw gateway validate --config ./gateway.proxy.yaml --strict --json | tee /tmp/gw-validate.json

6. Изоляция портов и токенов. Админ-интроспекцию вешайте на 127.0.0.1 и отдельный loopback-порт; слушатели webhook — за краевым ACL на другом порту. Bearer и секреты — через Keychain или handle секрет-хранилища в переменных окружения, а не в YAML в общем репозитории.

7. Повторяемость сеанса. Все команды выше выполняйте от того же сервисного пользователя, под которым работает шлюз в продакшене (часто через sudo -u …), чтобы doctor видел те же пути к конфигу и переменным, что и рабочий процесс. Иначе «зелёный» validate с личной оболочки и красный на LaunchAgent — ещё один источник ложного спокойствия.

Поле ok: true должно появляться только когда пройдены все ворота fail-closed. Пример структуры для корреляции с логами (идентификаторы приведены как образец):

{
  "ok": true,
  "mesh_node_id": "meshmac-pool-7",
  "policy_revision": "gateway-proxy@2026-04-25.3",
  "fail_closed": true,
  "allowed_upstream_hosts": ["api.meshmac.internal", "hooks.slack.com"],
  "deny_reason": null
}

Чтобы коллаборация не скрывала дрейф из-за порядка ключей, соберите JSON со всех шлюзов и нормализуйте:

for id in gw-a gw-b gw-c; do
  ssh "$id" 'openclaw gateway validate --config /etc/openclaw/gateway.proxy.yaml --strict --json'
done | jq -s 'sort_by(.mesh_node_id)' > /tmp/all-gw.json
jq -c '.[] | {mesh_node_id, policy_revision, fail_closed}' /tmp/all-gw.json

Если на любом узле отличается policy_revision или fail_closed, считайте узел вне эталона до выравнивания файлов и перезапуска агента. Смежные квоты шлюза не должны противоречить прокси-политике — см. лимиты сессий и rate limit шлюза.

Точка B — сразу после успешного canary-validate: снова скопируйте рабочий YAML с суффиксом .ok.

Порядок отката при деградации трафика: восстановить файлы из точки A, перезагрузить LaunchAgent или systemd-unit, снова выполнить openclaw gateway validate --strict --json на каждом узле до ok: true, затем по runbook включать входящие маршруты — в том числе по шагам балансировки и failover. В журнал смен добавьте id тикета и субъект, чтобы управление дрейфом оставалось проверяемым.

Если откат касается только белого списка upstream, а не всего файла, всё равно восстанавливайте целый согласованный артефакт из checkpoint, а не «ручной» фрагмент в редакторе: частичные правки — главный способ снова получить скрытое расхождение между узлами. После отката сохраните JSON validate в артефакты CI на одну неделю — это удешевляет разбор инцидентов.

Вопрос: Можно ли временно ослабить fail-closed на одном шлюзе для отладки?
Ответ: Только в согласованном окне, с тикетом и автоматическим возвратом; иначе вы создаёте долгоживущий «мягкий» узел, который ломает доверие к пулу. Лучше отдельный стендовый mesh_node_id и та же строгая схема validate.

Вопрос: Достаточно ли сравнить только хеш файла YAML?
Ответ: Нет: процесс мог не перечитать файл. Ориентир — совпадение полей JSON validate, включая policy_revision, плюс успешный контрольный рестарт по runbook после изменения.

Вопрос: Где хранить jq-скрипт сбора по SSH?
Ответ: В репозитории инфраструктуры с ревью; запуск — из CI или bastion с журналируемым доступом, без копирования секретов в лог.

• Структурированный validate обязан отдавать mesh_node_id, policy_revision и флаг fail_closed — иначе алерты в конвейере событий не отличат полную проверку от заглушки.
• Согласованность Node LTS — часть модели угроз: разные сборки OpenSSL меняют наборы шифров и осложняют разбор TLS-инцидентов на прокси.
• Артефакты патчей по белому списку должны иметь semver или digest; тег latest на общих хостах для динамической перезагрузки не использовать.

Дополнительный контур жёсткого отказа — политика плагинов fail-closed на мультиузле, чтобы ужесточение прокси не обходилось расширением поверхности плагинов.