113 lines
8.0 KiB
Markdown
113 lines
8.0 KiB
Markdown
# 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), питфолы
|
||
|