2026 OpenClaw Gateway в Docker на облачной ВМ с приватным доступом через Tailscale

Команды, которые поднимают OpenClaw Gateway на недорогой облачной Linux-ВМ, обычно хотят одного: чтобы MCP и Streamable HTTP жили только в tailnet, без публичного слушателя на хосте и без лишних отверстий в security group. Устойчивый шаблон — стек Docker Compose, где официальный образ Tailscale выступает sidecar: он владеет tailscale up, состоянием в постоянном томе и поднятием интерфейса, а контейнер шлюза слушает loopback или внутренний bridge и никогда не публикует 0.0.0.0:443 в Интернет. Облачный файрол провайдера необходим, но недостаточен: правила docker publish и systemd-сокеты могут обойти то, что «на бумаге» закрыто группами безопасности. Конкретные теги образов, healthcheck и порты зависят от закреплённой версии OpenClaw; здесь зафиксированы слои сети и аутентификации для runbook. Как сопоставить Docker и нативные демоны на удалённом Mac — в материале 2026 OpenClaw: практическое удалённое развёртывание на Mac — пути установки, Docker и постоянный запуск на хосте, частые ошибки и сценарии рабочих процессов.

1. Sidecar в Compose: не дайте ports: снова открыть публичный контур

Размещайте sidecar и шлюз на одной пользовательской bridge-сети, монтируйте разные каталоги состояния и не шарьте один /var/lib/tailscale между двумя контейнерами. Типичная ошибка — ports: "443:443" или привязка шлюза к 0.0.0.0 «на минутку для проверки»: файрол в облаке может быть идеален, а Docker всё равно пробросит порт наружу. Предпочтительно слушать на внутреннем адресе, а клиентов пускать по именам MagicDNS с других участников tailnet. Если нужна терминация TLS, делайте её на обратном прокси, который доступен только внутри tailnet, а не через host publish. Перед долгой настройкой ACL и сертификатов выполните docker ps и убедитесь, что ни один контейнер не мапит порты на публичный интерфейс хоста.

Правило: сначала устраните публикацию портов Docker, затем занимайтесь политиками Tailscale — иначе вы отладите не ту плоскость.

2. Привязка Gateway к tailnet: HTTPS и Bearer-токены

После успешного tailscale up выпускайте доверенные сертификаты через tailscale cert или внутренний Caddy, чтобы клиенты не отклоняли цепочку из-за самоподписанных файлов. Токены передавайте через переменные окружения или Docker secrets как файлы — не запекайте их в слои образа. Если TLS обрывается на прокси, проверяйте Authorization: Bearer и на прокси, и в самом Gateway, чтобы обходной маршрут не пропускал анонимов. В логах разводите 401 приложения и ошибки рукопожатия TLS; при ротации токенов планируйте rolling restart, потому что долгоживущие процессы часто держат старый секрет в памяти. Таблица владельцев auth key Tailscale и редакторов ACL должна жить рядом с таблицей API-ключей.

3. Serve и Funnel: явные границы политики

tailscale serve обычно подходит для доступа только внутри tailnet. Funnel намеренно выносит выбранные пути в публичный Интернет. Если compliance требует нулевой публичной экспозиции, держите Funnel выключенным по умолчанию, запретите его политикой и периодически ищите «временные» флаги отладки. В режиме Serve несовпадение имени хоста или префикса пути относительно базового пути Gateway выглядит как нестабильные 404 или редиректы при здоровом процессе — сводите имена MagicDNS, пути Serve и таблицы маршрутов OpenClaw в один тикет изменений.

4. Обрывы соединения: сужайте пространство поиска в фиксированном порядке

1) Внутри sidecar выполните tailscale status и убедитесь, что tailnet подключён без состояния вроде NeedsLogin. 2) С другого участника проверьте ping на адрес 100.x и curl -vk https://имя-машины, чтобы отделить отказ ACL от бага приложения. 3) Вызовите шлюз с реальным заголовком Authorization, иначе TLS-ошибки маскируются под 401. 4) Если падает Streamable HTTP при рабочем stdio, пройдите цепочку таймаутов простоя и лимитов тела запроса end-to-end. Для учебных инцидентов ужесточите ACL, снимите логи, откатите скриптом — откат должен быть таким же воспроизводимым, как сам сбой. На постоянно включённом Mac с launchd полезно сверять doctor, статус и журналы по гайду 2026 OpenClaw: справочник по стабильности шлюза в launchd — сверка doctor/status/logs, порты и конфликт двух LaunchAgent на удалённом постоянно включённом Mac.

  • Не обнулил ли перезапуск sidecar том состояния и не потребовал ли узел повторного входа?
  • Нет ли одновременно хостового tailscaled и контейнерного sidecar на пересекающихся маршрутах?
  • Не попали ли облачные metadata-эндпоинты в таблицы, помеченные как «только внутренние»?

Linux-шлюз в облаке, macOS — для тяжёлой части

Держать Gateway на компактной Linux-ВМ выгодно по счёту, но нотаризация, подпись кода и отладка с GUI остаются сильной стороной macOS. Разделение контейнеров управления в tailnet и пиковых нагрузок на выделенном Mac mini даёт полосу памяти Apple Silicon и нативный Xcode без публичного доступа к любой из сторон. Mac mini в простое потребляет порядка четырёх ватт, работает тихо под постоянной нагрузкой и опирается на Gatekeeper, SIP и FileVault для машин без администратора рядом. Если такую пару хотите собрать без закупки железа на стол, начните с Mac mini M4 в ближайшем регионе на главной странице Macstripe и включите его в тот же tailnet, что и этот Compose-стек.