git_admin/obsidian-vault
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
e2f1a2aaece5ef1fa1f58f47d3a4ba88cbd65033
obsidian-vault/family/how-to/kraken-access.md
T

8.0 KiB
Raw Blame History

Kraken — Внешний доступ

Обновлено: 2026-09-04

Updated: 2026-09-01 23:00 — диск/докер кракена восстановились после перезагрузки.

Как зайти

Везде ssh kraken. Резолвится через ~/.ssh/config на Eagle:

  • Дома — напрямую по LAN (192.168.1.15)
  • Снаружи — ⚠️ через WireGuard (10.99.1.2) БОЛЬШЕ НЕ РАБОТАЕТ: VPS-узло (10.99.0.1/10.99.1.1) qentra.top удалили 2026-09-01. Альтернатива внешнего доступа обсуждается через Xray reverse (см. tech/xray-reverse-tunnel-kraken-truenas).

⚠️ Kraken-диск был нестабилен 2026-09-01: USB-диск TOSHIBA в цикле enumeration (device descriptor read/64 error -110, device not accepting address error -62, [sda] Read Capacity(10) failed → 0 B), Kraken перезагружался (System is booting up / pam_nologin). После повторной перезагрузки диск зарегистрировался: sda 1.8T, sda1 смонтирован в /srv/dev-disk-by-uuid-6194539b-.... Docker стал active.

⚠️ Kraken Docker на 2026-09-01: Server 29.4.3, Docker Root Dir /srv/dev-disk-by-uuid-6194539b-03e0-4f33-986b-4da09834e82f/docker-data. 30 образов сохранены, но 0 контейнеров (all прежние контейнеры — jellyfin/transmission/radarr/hermes-kraken и т.д. — потеряны и НЕ пересозданы после сбоя; data-root на HDD был в цикле enumeration). При необходимости — пересоздать из образов.

Portainer (локально)

http://kraken:9000

API:

BASE=http://localhost:9000
KEY="ptr_AJY+Ba9A7f6pcAHZfDD5koU4stkKgJCdbTEXLDLxn0g="
EP=3  # endpoint ID на Кракене = 3, не 1!

Hermes API

http://kraken:8642/v1/chat/completions — OpenAI-compatible endpoint.

Reverse Xray bridge (развёрнут 2026-09-01)

  • Контейнер xray-reverse-bridge в /home/kraken/xray-reverse/ (compose + config.json, образ teddysun/xray:latest, Xray 26.7.28 ARM64).
  • Outbound VLESS+REALITY TCP → mallexxx.duckdns.org:12346 (TrueNAS через OpenWrt DNAT), reverse tag reverse-in, egress freedom.
  • ⛔ End-to-end payload НЕ работает (bridge принимает reverse-канал, но данные от portal до bridge не доходят). Детали: tech/xray-reverse-tunnel-kraken-truenas.

Docker контейнеры (исторически было 2026-06-24; на 2026-09-01 НЕ восстановлены)

Имя Заметки
xray-reverse-bridge развёрнут 2026-09-01
cloudflared ✅ UP (2026-09-04), remote-managed по TUNNEL_TOKEN — пересоздан после сбоя
flaresolverr / hermes-kraken / homeassistant / jellyfin / portainer / prowlarr / radarr / rclone / sonarr / transmission / watchtower образы есть, контейнеры потеряны — пересоздать при необходимости

Cloudflared туннель — публичные маршруты (состояние на 2026-09-04)

Туннель kraken в Zero Trust, remote-managed по TUNNEL_TOKEN, network_mode: host, образ cloudflare/cloudflared:latest. Актуальный ingress конфиг (виден в логах cloudflared на Kraken, INF Updated to new configuration):

{"ingress":[
  {"hostname":"kraken.qentra.top",     "originRequest":{"httpHostHeader":"kraken.qentra.top"},"service":"http://localhost:8642"},  ← Hermes API
  {"hostname":"ssh-kraken.qentra.top",  "service":"ssh://localhost:22"},                                                          ← SSH (published application route)
  {"service":"http_status:404"}                                                                                                    ← default catch-all
]}

⚠️ Важно (путаница была!): kraken.qentra.top — это HTTP-маршрут на localhost:8642 (Hermes API), НЕ SSH. Поэтому SSH к kraken.qentra.top:22 и не шёл. Под SSH создан отдельный hostname ssh-kraken.qentra.top.

✅ SSH-доступ работает через ssh-kraken.qentra.top (РАБОЧИЙ, 2026-09-04)

Вход (проверено, работает):

ssh kraken@ssh-kraken.qentra.top

~/.ssh/config блок:

Host ssh-kraken.qentra.top
  HostName ssh-kraken.qentra.top
  User kraken
  ProxyCommand cloudflared access ssh --hostname %h

Первый раз — авторизация cloudflared в Access-приложение:

cloudflared access login ssh-kraken.qentra.top

Маршрут на Kraken (UP, контейнер) подхвачен ingress ssh-kraken.qentra.top → ssh://localhost:22; sshd на Kraken — 0.0.0.0:22. DNS проксировано CF (104.21.x / 172.67.x).

⚠️ Питфол: почему ssh.kraken.qentra.top (двухуровневый) НЕ сработал

Изначально под SSH добавлялся hostname ssh.kraken.qentra.top (ssh.kraken + qentra.top) → ssh://localhost:22, + Access Application (type SSH) + Service Token. Вход НЕ заработал. Решающий факт — на edge Cloudflare у этого hostname НЕТ SSL/TLS-терминации, в отличие от одиночных subdomain:

openssl s_client -connect ssh.kraken.qentra.top:443 → SSL alert 40 (handshake failure), no peer certificate
curl https://ssh.kraken.qentra.top → ssl=1 handshake failure

Любой cloudflared access login/ssh и Service Token к чистому двухуровневому SSH-hostname не помогают — клиент не доходит даже до авторизации из-за отсутствия edge-TLS.

Решение, которое сработало: использовать одиночный subdomain через дефис — ssh-kraken.qentra.top (покрывается Universal SSL *.qentra.top). На нём размещены тот же published application route SSH → ssh://localhost:22 + Access Application. Вошло сразу.

Почему так: Universal SSL зоны покрывает *.qentra.top (1 уровень) и qentra.top, но НЕ *.kraken.qentra.top (2 уровня). Для 2-уровневого нужен Advanced Certificate — проще взять одиночный subdomain.

Диагноз IPv4/IPv6 «жив, но шумит» (актуально для обоих hostname)

  • В логах cloudflared — часть Registered tunnel connection ... protocol=quic, но постоянные ERR ... write udp [::]->198.41.x.x:7844: sendmsg: network is unreachable.
  • Причина: на Kraken НЕТ глобального IPv6 (только ::1 и link-local fe80::; роутер 192.168.1.1 IPv6 не выдаёт → ping6 2606:4700::1111 = Network is unreachable). cloudflared пробует QUIC и по IPv6 → каналы падают; туннель выживает по IPv4-QUIC.
  • Возможный фикс: заставить cloudflared QUIC только по IPv4, чтобы убрать IPv6-шум.

SSH через VPS reverse (независимо от cloudflared)

Остаётся рабочим внешним путём: reverse SSH туннель через VPS 91.207.28.205:2223 (см. ниже), НЕ cloudflared.

Связанные заметки

Reference in New Issue View Git Blame Copy Permalink