Skip to content

Runbook — Cloudflare-туннели

Audience: operator. Все туннели — это systemd-юниты, переживают ребут (Restart=always + enabled). Восстановление почти всегда = systemctl restart <unit> на нужном хосте.

Токены туннелей лежат в env-файлах (/etc/…env, режим 600) и в age-хранилище секретов. cloudflared показывает свой токен в psне копировать вывод ps с токеном куда-либо.

Карта туннелей

ХостнеймСостояниеEdge → коннектор → origin
gitlab.kontinuum.cloudLIVECF Access → head → reverse-SSH → gitlab-host :80
updates.kontinuum.cloudLIVECF Tunnel → aruba1 → python static :8088
legal.kontinuum.cloudНЕ обслуживаетсяCF Access edge поднят, origin не запущен — resurrect-or-retire pending

1. gitlab.kontinuum.cloud (публичный доступ к GitLab)

Самый длинный путь: GitLab живёт внутри домашней сети (только :80), а наружу выставлен через две сцепленные ноги.

plantuml Diagram

Состав:

  • Edge: Cloudflare Access — email-OTP, allow belanchuk@gmail.com (+ service-token для API/CI). Управляется в CF dashboard / через CF API.
  • Коннектор: cloudflared-gitlab.service на head. Обязан стартовать с --protocol http2 --edge-ip-version 4 (иначе QUIC/IPv6 на этом аплинке не держится). Токен — в /etc/cloudflared-gitlab.env (режим 600). Проксирует на 127.0.0.1:9180.
  • Вторая нога: gitlab-revtun.service на gitlab-host — reverse-SSH, поднимает head:9180gitlab-host:80.

Восстановление:

bash
# на head
systemctl status cloudflared-gitlab.service
systemctl restart cloudflared-gitlab.service
journalctl -u cloudflared-gitlab.service -n 50 --no-pager

# на gitlab-host (через worker на LAN, или через head-туннель)
systemctl restart gitlab-revtun.service

Оба — Restart=always + enabled, поэтому после ребута поднимаются сами; ручной restart нужен только если юнит упал в failed.

Коннектор НЕ переносить домой

Домашний аплинк не выдерживает udp/tcp 7844 cloudflared. Connector обязан жить на датацентр-хосте (head). Никогда не запускать cloudflared для этого туннеля в домашней сети.

Проверка живости:

bash
curl -sI https://gitlab.kontinuum.cloud   # ожидается 302 на cloudflareaccess.com
systemctl is-enabled cloudflared-gitlab.service   # enabled
systemctl is-active  cloudflared-gitlab.service   # active

2. updates.kontinuum.cloud (канал обновлений приложения)

CF Tunnel → aruba1 cloudflared.service → kontinuum-updates-static.service
            (python static, слушает 127.0.0.1:8088, CORS, за cloudflared)

Раздаёт latest.json + подписанный APK. Подробнее о публикации — в runbook релизов.

Восстановление (на aruba1, ssh root@94.177.204.91):

bash
systemctl restart cloudflared.service
systemctl restart kontinuum-updates-static.service
journalctl -u kontinuum-updates-static.service -n 30 --no-pager

Проверка:

bash
curl -s https://updates.kontinuum.cloud/latest.json     # снаружи
ssh root@94.177.204.91 'ss -ltnp | grep 8088'           # python на :8088

Tunnel vs nginx

Канал обновлений идёт через CF Tunnel напрямую на python-static, минуя nginx aruba1. Не заводить его за nginx.


CF Access edge отвечает (запрос редиректит на OTP-логин), но origin не запущен — раньше это был локальный VitePress (:5173), сейчас процесс не поднят. Считать сервис не-живым.

Решение resurrect-or-retire — за founder/CTO:

  • resurrect: поднять VitePress-origin + соответствующий коннектор;
  • retire: удалить CF Access app + DNS-запись, чтобы не висел мёртвый хостнейм.

Сводка юнитов

UnitХостНазначение
cloudflared-gitlab.serviceheadedge-коннектор GitLab
gitlab-revtun.servicegitlab-hostreverse-SSH нога к GitLab :80
cloudflared.servicearuba1edge-коннектор updates
kontinuum-updates-static.servicearuba1python static :8088
head-tunnel.serviceworkerreverse-SSH worker→head (см. бэкапы/recovery)