2026 OpenClaw Gateway и Tailscale
Частный туннель, loopback и удалённый CLI: runbook

OpenClaw Gateway уже запущен на VPS или домашнем сервере, но порт 18789 нельзя выставлять в открытый интернет; при этом ноутбуку, другой Linux-машине или мобильному узлу нужен доступ к CLI и WebSocket как к внутреннему сервису. Здесь разобраны частный туннель Tailscale и привязка к loopback по умолчанию: границы топологии, токен и переменные среды, чеклист удалённого CLI и отдельно сценарий «туннель в порядке, но нет сессии / RPC ведёт себя странно». Вы поймёте, как эта статья сочетается с материалом про Cloudflare Tunnel и systemd и в каких случаях тяжёлую нагрузку логичнее вынести на выделенный удалённый Mac.

01

Почему в 2026 году «просто сменить bind на 0.0.0.0» — плохой ответ

OpenClaw Gateway по умолчанию слушает 127.0.0.1, то есть уменьшает плоскость атаки до того, что ОС уже обещает: напрямую с WebSocket/HTTP управления могут говорить только локальные процессы. Частая ошибка — ради «удалённого openclaw» переключить прослушивание на 0.0.0.0 и донастраивать сеть вручную: на демо среде это сходит, в проде одновременно вскрываются сканирование, утечки токенов, ошибки CORS.

  1. 01

    Рост сканируемой поверхности: порт, доступный из интернета, попадёт в автоматические обходы за часы; даже с сильным токеном логи и SIEM зашумлены.

  2. 02

    Конфликт с hardening: в материале про усиление Gateway подчёркиваются loopback, ротация токенов и одобрение опасных действий; открытый bind снимает первый барьер.

  3. 03

    Искажение сигналов отладки: в публичном пути появляются CDN, NAT, корпоративный прокси; половина сбоев — не OpenClaw, а half-close и MTU.

  4. 04

    Аудит и соответствие: сложно доказать, какой публичный IP соответствовал сотруднику; в tailnet проще сопоставить устройство, теги и ACL.

  5. 05

    Несколько экземпляров Gateway: при экспериментах с второй копией на одном хосте растут риск коллизий портов и путаницы с токенами.

  6. 06

    Удалённый Mac: долгий тяжёлый трафик — Xcode, симуляторы, большие кэши; Gateway лучше держать лёгким, а исполнение переносить на выделенный узел.

Правильная модель: оставить Gateway на loopback, а доступность обеспечить сетевым слоем (Tailscale и т. п.). Это тот же класс привычек, что и БД только на 127.0.0.1 плюс SSH-туннель. Если вам ближе Cloudflare Tunnel, сначала сопоставьте Linux VPS, systemd и Cloudflare Tunnel с этой схемой: там «вход с периметра», здесь — «только tailnet, loopback наружу не выставляем».

02

Три схемы: loopback + Tailscale, публичный bind, Cloudflare Tunnel

ИзмерениеLoopback + TailscaleПубличный bindCloudflare Tunnel
Модель доверияИдентичность в tailnet + ACL, по умолчанию приватноФайрвол + токен, большая поверхностьИдентичность на периметре и учётные данные туннеля, ориентир на публичный вход
Операционная нагрузкаСредняя: ACL, имена, тегиНизкий старт, высокий долгосрочный рискВыше среднего: DNS, сертификаты, политика к origin
Соответствие дефолтам OpenClawВысокое: bind не трогаемНизкое: подталкивает к 0.0.0.0Среднее: туннель к порту на loopback
Типичные пользователиОдиночки и малые команды с приватной оркестрациейНе рекомендуется для продаКонтролируемый вход из интернета

«Туннель решает маршрут, не замену аутентификации: токен и политика исполнения остаются включёнными.»

Смысл Tailscale — положить машины в одну зону доверия и обращаться к стабильным именам в сети 100.x; он не снимает с Gateway токен. ACL вида *:* внутри tailnet создают «мини-публичный интернет» внутри сети.

В типовой топологии 2026 встречаются маршрут подсети (subnet router) и exit node: первая схема открывает до LAN без клиента Tailscale, вторая гоняет исходящий трафик через выбранный хост. Если Gateway и СУБД в одном VPC, а ноутбук только в tailnet, важно явно нарисовать, какой источник может дойти до порта БД — иначе «curl с сервера к БД работает, удалённый CLI ловит 500» окажется следствием ACL или несимметричного маршрута, а не бага OpenClaw.

Деталь: MagicDNS и поисковые домены — в корпоративных сетях *.ts.net иногда перехватывают. При сбоях сравнивайте dig через публичный резолвер и встроенный в tailnet; иначе «DNS вперемешку» похоже на сбой сессии OpenClaw. Зафиксируйте выводы в runbook, чтобы сократить однотипные инциденты при онбординге.

03

Сторона Tailscale: MagicDNS, ACL и приёмка «только с машин обслуживания»

Установив и залогинив Tailscale на хосте Gateway, сначала на ноутбуке в том же tailnet подтвердите RTT по ping и tailscale ping. Затем в админ-консоли: корректные теги на ноде, MagicDNS, ACL с явным разрешением TCP 18789 (или вашего порта) с роли «ops» к роли «gateway».

hujson
// Фрагмент ACL: только tag:ops к 18789 на узле с tag:gateway
{
  "groups": { "group:ops": ["alice@github", "bob@github"] },
  "tagOwners": { "tag:gateway": ["group:ops"] },
  "acls": [
    {
      "action": "accept",
      "src":    ["tag:ops"],
      "dst":    ["tag:gateway:18789"]
    }
  ]
}
warning

Внимание: фрагмент иллюстрирует форму. Реальная политика должна учесть exit node, маршруты подсети и мобильные устройства с минимальными правами; после изменений переподключите tailnet и повторите проверки.

В чеклист приёмки стоит включить: Gateway по-прежнему на 127.0.0.1:18789; health-check c ноутбука в tailnet (конкретный путь зависит от версии; локально на сервере — curl -v http://127.0.0.1:18789); в облачном security group нет входа на 18789 из интернета. Сопоставление с «каналом молчит» смотрите в статье про зондирование каналов и dmPolicy.

04

Сторона OpenClaw: шесть шагов к удалённому CLI при loopback

Ниже предполагается, что openclaw doctor на сервере зелёный. Если нет, начните с кроссплатформенной установки и первого runbook, затем возвращайтесь сюда.

  1. 01

    Адрес прослушивания: на сервере lsof -nP -iTCP:18789 -sTCP:LISTEN — ожидается 127.0.0.1. Если *:18789, сначала откатите конфигурацию, не «лечите» туннелем.

  2. 02

    Источник токена: в первую очередь OPENCLAW_GATEWAY_TOKEN в среде процесса, не долгоживущий секрет в репозитории, который синхронизируется на всех машинах.

  3. 03

    Remote на ноутбуке: в ~/.openclaw/openclaw.json задайте remote на tailnet-имя и порт (имена полей — по справке вашей версии CLI), WebSocket ws:// или wss:// в соответствии с политикой.

  4. 04

    Порт в окружении: при нестандартном порту согласуйте OPENCLAW_GATEWAY_PORT и на сервере, и в клиентской сессии, чтобы «doctor зелёный» не сосуществовал с «CLI бьёт не в тот порт».

  5. 05

    Где обрывается TLS: если в tailnet ещё стоит обратный прокси, убедитесь, что обновление WebSocket не вырезано по пути.

  6. 06

    Следы для тикетов: сохраняйте в одной заявке gateway status, doctor и лог неудачной сессии — при обновлении Gateway проще сравнивать.

json
// Пример: ~/.openclaw/openclaw.json (имена полей — по CLI вашей версии)
{
  "gateway": {
    "remote": {
      "url": "ws://openclaw-gateway.tailnet-1234.ts.net:18789",
      "token": "use-env-or-osx-keychain-instead-of-plaintext"
    }
  }
}
info

Заметка: не стоит совмещать на одном слабом VPS тяжёлые сборки и Gateway: при постоянных xcodebuild и больших кэшах устойчивее вынести исполнение на выделенный удалённый Mac, а Gateway оставить оркестратором. Оценка диска и региона: страница тарифов аренды.

05

Таблица симптомов и три формулировки для runbook

СимптомС чего искатьДействие
tailscale ping OK, CLI таймаутПорт не в ACL или локальный файрвол режет цепочку к loopbackСначала loopback на сервере, затем кольцо наружу
HTTP 401Расхождение токенов, переменные не в unit systemdСравнить Environment= в unit и интерактивную сессию
WebSocket сразу рвётся / closed(1000)Несовместимость scope или сессии после обновленияСвериться с runbook по gateway closed, сузить токен и scope
Канал «в сети», сообщений нетНет пейринга / dmPolicyПодкоманда channels и материал о каналах (ссылка выше)

Если после минорного обновления Gateway один и тот же ACL и токен ведут себя иначе только в удалённом CLI, сначала сравните примечания к релизу и таблицу портов, откатитесь на последнюю стабильную и разделите проблему пополам; не крутите ACL вслепую, иначе в тикете останутся ложные срабатывания.

  • Порт по умолчанию и стоимость смены: в экосистеме OpenClaw к контролю чаще всего привязан 18789 (уточняйте по release notes); любое смещение должно совпадать в systemd, Compose и remote у клиента.
  • RTT в tailnet: 80–150 мс ещё терпимы для CLI, но частые tool-вызовы умножают задержку; сокращайте чат-подобные round-trip, переходя к скриптам пакетами.
  • Идентичность и жизненный цикл: повесьте на узел tag:gateway и заранее опишите в runbook «увольнение = удаление машины и отзыв устройства в tailnet».

И «голый» публичный bind, и слишком широкие ACL в 2026 году делают плоскость управления агентом плохо проверяемой; вся тяжёлая нагрузка на одном мини-VPS упирается в RAM и диск. Рациональнее: лёгкий Gateway, доступ через tailnet, тяжёлая работа на выделенном macOS-узле. Для длительных сессий Xcode и предсказуемого диска обычно уместна аренда облачного Mac Mini в NodeMini.

FAQ

Частые вопросы

Пакет из tailnet попадает в сетевой стек хоста; дальше локальный путь ведёт к 127.0.0.1:18789 без смены bind на все интерфейсы. Критичны ACL, host firewall и токен. Для выбора ёмкости диска и региона можно открыть страницу с тарифами.

Материал про Tunnel закрывает безопасный вход из интернета к внутреннему сервису; здесь — приватный tailnet и loopback. Комбинируйте осознанно, не дублируя цепочки аутентификации без необходимости.

Полный список материалов OpenClaw — в разделе блога с фильтром по категории. Вопросы SSH, сессий и среды — в справочном центре по облачному Mac.