OpenClaw на Linux VPS в 2026 | минимальная поверхность атаки, firewall, loopback, SSH и HTTPS

OpenClaw Gateway на недорогом Linux VPS удобен до первого сканирования портов на админ-интерфейс. Практическая цель — малая, исчислимая поверхность: запрет по умолчанию на периметре, доступ к шлюзу только там, где вы его спроектировали, и осознанный выбор между SSH-туннелем для плоскости управления и публичным HTTPS reverse proxy. Ниже — повторяемый шаблон firewall, привязка к loopback, типовой SSH-доступ и матрица, чтобы не перестраховаться в первый день и не отложить ужесточение на потом.

22 / 443

Типичные публичные порты, которые нужно обосновать

127.0.0.1

Предпочтительная привязка Gateway в режиме блокировки

L0–L3

Уровни разборки для единообразия тикетов

Модель угроз в одном абзаце

Считайте возможным перебор SSH, скрейп любого HTTP-слушателя и шум цепочки поставок на путях установки. Gateway управляет токенами и сессиями — изолируйте его от посторонних демонов. Исходите из запрета входящих по умолчанию, затем явно разрешите только SSH (ключи, при необходимости allow-list по IP) и то, что вы сознательно публикуете для ассистентов или вебхуков.

Шаблон firewall: deny по умолчанию, явный allow

С ufw или nftables история одна: loopback открыт, established/related принимаются, новые входящие сужаются до SSH и (только если нужно) 80/443 для TLS. Продублируйте правила на IPv6 или осознанно отключите v6 — не оставляйте его открытым по неосторожности.

Базовая линия в стиле UFW (порты SSH подставьте свои)

# Сброс — только с консоли, которой доверяете
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH    # или: allow 22/tcp
# Если TLS для OpenClaw терминируется на этой машине:
# sudo ufw allow 80,443/tcp
sudo ufw enable
sudo ufw status verbose

Сначала security groups у провайдера

Облачные группы безопасности должны повторять ту же политику, что и ОС. Если есть оба уровня, держите их согласованными — случайный переключатель в панели не должен незаметно расширить VPS.

Привязка Gateway к loopback

Если с других хостов в LAN шлюз вызывать не нужно, привязывайтесь к 127.0.0.1 (и к loopback IPv6, если он включён). Это убирает большинство инцидентов вида «забыли закрыть высокий порт». Локальный reverse proxy на той же машине — только когда нужно стыковать протоколы; иначе для админ-трафика используйте SSH port forwarding ниже.

Проверки доступности и агенты

Если внешний мониторинг должен достучаться до Gateway с интернета, режим «только loopback» для этого пути не подходит — используйте раздельный listener, mTLS на приватном интерфейсе или перенесите проверки на процесс-супервизор хоста вместо публичного интернета.

SSH-туннель для доступа к плоскости управления

Для одного администратора или малой команды ssh -L концентрирует доверие на ключах и браузере под вашим контролем. Пример:

Локальный форвард (порты условные)

ssh -N -L 8443:127.0.0.1:18789 user@vps-hostname
# Затем в браузере https://127.0.0.1:8443, если TLS на стороне туннеля,
# или http://127.0.0.1:8443 для HTTP на loopback (в прод лучше обернуть stunnel/WireGuard).

Ужесточите SSH: только ключи, узкий AllowUsers, при необходимости fail2ban; нестандартный порт SSH — гигиена, не политика. Если туннель есть, а Gateway не отвечает, см. 2026: постоянная диагностика OpenClaw на Linux — systemd, журналы openclaw logs и зонд порта шлюза (FAQ по уровням) для разборки unit и логов.

Матрица: путь через SSH и loopback против публичного HTTPS reverse proxy

HTTPS нужен, когда браузеры, мобильные сети или вебхуки требуют стабильный публичный URL. SSH уместен, когда админкой пользуются только операторы и хочется меньше движущихся частей на периметре.

Измерение	SSH-туннель к Gateway на loopback	Публичный HTTPS reverse proxy (Nginx/Caddy)
Аудитория	Админы с SSH-ключами	Браузеры, приложения, вебхуки вендоров
Экспозиция	Только SSH (+ опционально VPN)	443 (часто и 80 для ACME)
Работа с TLS	Может быть минимальной, если доверяете транспорту SSH	Сертификаты, продление, наборы шифров
Типовые сбои	Таймауты NAT, сломанный ControlMaster	Неверный Host, устаревший upstream
Лучше всего когда	Соло/малая команда, нет публичных интеграций	Общие ассистенты, жёсткие SLO по доступности

Постепенное расширение экспозиции

В первый день — loopback и SSH. Переходите на HTTPS, когда конкретная интеграция требует стабильного публичного URL; после cutover оставьте SSH-путь как аварийный вход.

Поуровневый FAQ по разборке

Держите формулировки L0–L3 согласованными с другими runbook OpenClaw, чтобы тикеты сравнимы между инженерами.

L0 — «ничего не слушает»

Проверьте, что unit активен, затем ss -lntp. Если Gateway только на loopback, проверка с другого хоста даст ложный отрицательный результат — повторите через туннель или с оболочки на самом VPS.

L1 — «SSH есть, туннель не работает»

Ищите коллизии локального порта, различие localhost и 127.0.0.1 с IPv6 и curl -v с VPS на loopback-цель, чтобы разделить вину SSH и приложения.

L2 — «HTTPS после продления сертификата дёргается»

Смотрите режим ACME (HTTP-01 vs DNS-01), ошибки reload прокси и keepalive к upstream; продление не должно «подпрыгивать» Gateway без согласованной автоматизации проверок здоровья. Полный сценарий onboard, doctor/fix и отката HTTPS на этом VPS разберите в журнале в статье про продакшен-Gateway с Nginx/Caddy — держите runbook рядом с этой матрицей.

L3 — «подозрение на компрометацию»

Снимите состояние firewall, ротируйте SSH-ключи и токены, отзовите вебхуки и пересоберите образ с нуля вместо «долбания молью» по живому диску. Вопросы путей установки и окружения — в 2026: OpenClaw на Linux VPS — curl vs Docker, проверка окружения и FAQ по типовым ошибкам.