# 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: ```bash 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) **Вход (проверено, работает):** ```bash 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-приложение: ```bash 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. ## Связанные заметки - [[kraken-network]] — SSH, WG топология - [[wireguard-vpn]] — полное описание WG (⚠️ VPS-звено мёртво на 2026-09-01) - [[kraken-portainer-access]] - [[openmediavault-rpi5]] - [[tech/cloudflare-tunnel-ssh-published-route]] — генерализуемое руководство: SSH через Cloudflare Tunnel (1-уровневый subdomain + Universal SSL), питфолы