> - **⚠️ «Камера на TrueNAS» — ИСПРАВЛЕНО (2026-09-14, вечер-10) + ✅ РЕШЕНО ОКОНЧАТЕЛЬНО (вечер-13):** прежняя запись «камера = USB-вебка на t610, upstream `cam.*:8090` к камере отношения не имеет» — **❌ НЕВЕРНА**. Поиск в `Caddyfile.bak` доказал: **`cam.mallexxx.duckdns.org → 192.168.2.197:8090` — ЭТО И БЫЛА камера** на TrueNAS: отдельный HTTP-MJPEG-сервис (`ustreamer`/`mjpg-streamer`, порт 8090 — канон для «USB-вебка → MJPEG»). **Контейнер УТРАЧЕН** при пересоздании пула (локальный образ не пережил `.ix-apps`; из живого Caddyfile строка удалена — `cam.*` больше нет). **✅ ФИНАЛ (вечер-13):** вебка `046d:0825` физически в **t610**, работает через **аддон `a889bffc_go2rtc-hardware`** → RTSP H.264 `rtsp://192.168.2.176:8554/usb_camera_h264` → **Generic Camera** `camera.192_168_2_176` (зона `kotelnaia`, `unique_id`, **WebRTC работает**, поворот `#rotate=90`). Схема `camera: platform: ffmpeg` в Core — **❌ ОТВЕРГНУТА** (`Resource busy` + нет `unique_id`). Подробно — [[family/how-to/home-automation]] §5-кватер-И-3/И-6.
> - **Не перенесено с TrueNAS:** ~~погашение TrueNAS-стека (Этап 4 п.6 — заблокировано: Caddy на TrueNAS держит точку входа)~~ → **✅ ЗАКРЫТО 2026-09-14 (ночь): стек автоматизации ПОГАШЕН, Caddy остался на TrueNAS (так и задумано).** См. §5-кватер-Л в [[family/how-to/home-automation]].
> Обновлено: 2026-09-15 (вечер: ПЛАН `vless-space` на внешней outbound-подписке `profilegrid.net` — шаг 1 готов (28 серверов, HTTP 200), стоит на шаге 2 (нужны креды панели, `admin/admin` → 403); подзадача `hermes-taiga` → переключить `vless-proxy` с мёртвого `v.qentra.top`). Ранее: 2026-09-15 (subscription-канал 3x-ui: ссылки `/sub/<subId>` работают, base64 vless-список; раздел `xray-admin` → «SUBSCRIPTION-КАНАЛ»). Ранее: 2026-09-02 (vpn.mallexxx:443 = РАБОЧИЙ Xray-сервер, проверено end-to-end; vless-proxy outbound мёртв)
> Обновлено: 2026-09-15 (ночь-2: **`vless-space` — артефакты СОБРАНЫ И ПРОВЕРЕНЫ, применение в живую БД остановлено** (SSH к TrueNAS оборвался ровно на `docker stop`; контейнер сам поднялся, БД не тронута). Путь через БД подтверждён как рабочий (доступ к панели НЕ нужен), шаг «нужны креды панели» **снят как неверный**. Готовы `apply_space.sql` (проверен в песочнице), `template_config.new.json` (10 outbound + правило + `space-balancer` leastPing), UUID клиента. Разделы `xray-admin` обновлены: питфолл `x-ui.db`+WAL, `xrayTemplateConfig` как точка правки, `outbound_subscriptions` **НЕ задействуется** (выбран путь «outbound'ы из подписки, развёрнутые в шаблон»). Ранее 2026-09-15 (вечер: черновой план `vless-space`, шаг 1 — подписка проверена). Ранее: 2026-09-15 (subscription-канал 3x-ui: ссылки `/sub/<subId>` работают, base64 vless-список). Ранее: 2026-09-02 (vpn.mallexxx:443 = РАБОЧИЙ Xray-сервер, проверено end-to-end; vless-proxy outbound мёртв)
> ## ⏳ ПЛАН 2026-09-15: клиент `vless-space` на ВНЕШНЕЙ outbound-подписке (НЕ ВЫПОЛНЕН, стоит на шаге 2 из 6)
> ## ✅ РЕАЛИЗАЦИЯ 2026-09-15: клиент `vless-space` на ВНЕШНЕЙ outbound-подписке — АРТЕФАКТЫ ГОТОВЫ, ПРИМЕНЕНИЕ НЕ ВЫПОЛНЕНО
>
> **Задача Alex:** добавить в `xray-admin` третьего клиента `vless-space`, чей трафик идёт через **внешнюю** Xray-подписку `profilegrid.net` с авто-обновлением серверов. `user1` и `kraken-user` **НЕ трогать**.
> **Задача Alex:** добавить в `xray-admin` третьего клиента `vless-space`, чей трафик идёт через **внешнюю** Xray-подписку `profilegrid.net` с авто-обновлением серверов. `user1` и `kraken-user` **НЕ трогать**. Серверы — **«авто брать»** (все, с балансировкой).
>
> **Разбор путаницы (обе версии были в диалоге, верна ВТОРАЯ):**
> - ❌ «Сервер не может ходить через чужую подписку, он только принимает» — **НЕВЕРНО**, я сам себя опроверг в том же ответе.
> - ✅ **ВЕРНО: 3x-ui так УМЕЕТ** — это функция **`outbound_subscriptions`** (`/panel/api/xray/outbound-subs`, `/panel/api/xray/outbound-subs/parse`). Панель тянет внешнюю подписку, парсит её серверы как свои **outbound**'ы, обновляет по `update_interval`. Это НЕ клиентская подписка (`/sub/<subId>`), а **обратное направление**: сервер сам ходит наружу через чужие серверы.
> - ❌ «Сервер не может ходить через чужую подписку, он только принимает» — **НЕВЕРНО**, агент сам себя опроверг в том же ответе. Alex справедливо на это указал.
> - ✅ **ВЕРНО: 3x-ui так УМЕЕТ.** Но реализовано это **НЕ** через таблицу `outbound_subscriptions` (как предполагалось в черновике), а **через `xrayTemplateConfig`**: серверы подписки разворачиваются в обычные **outbound'ы** шаблона, а выбор клиента делается routing-правилом. См. «Как реализовано» ниже.
> - 🔑 **Два разных «subscription» в 3x-ui — не путать:**
> - Маскировочные метки в `#`: `🇩🇪 Germany`, `🇱🇻 Latvia | YT`, `🇬🇧 United Kingdom` и т.д.
> - **Питфолл:** 28 хостов, но реальных адресов ~9 — подписка отдаёт **несколько записей на один хост** с разными `pbk`/`sid` (перебор ключей).
> - **Питфолл:** 28 строк → **10 уникальных серверов**. Подписка отдаёт несколько записей на один хост с разными `pbk`/`sid` (перебор ключей). Дедуп по `host + pbk + sid`. Даже после дедупа встречаются повторы хостов с разными ключами.
> - 10 уникальных: `edge-{de,lv,nl,ee,pl,fr,us}.mirrorgrid.net`, `packages-{nl,se}.repocache.com`, `md.repodelivery.com` — теги `space-01`…`space-10` (в отчёте на Mac сохранены маскировочные имена: `🇩🇪 Germany`, `🇱🇻 Latvia | YT` …)
>
> ### ⏸️ ГДЕ ВСТАЛИ (продолжать отсюда)
> **Шаг 2 требует ДОСТУПА К ПАНЕЛИ 3x-ui.** Причины, почему через БД нельзя:
> - `outbound_subscriptions` содержит сложные поля (`link_identities`, `last_fetched_outbounds`), руками SQL-строку не собрать;
> - в `x-ui.db` живой **WAL** (4 МБ) + `-shm`, править под работающей панелью = риск;
> - в контейнере **нет `sqlite3`** (только `strings`), запись невозможна технически.
> - `POST https://vpn-panel.mallexxx.duckdns.org/login` с `admin/admin` → **HTTP 403** (дефолт не подходит, креды у Alex).
> - Список `sub*`-настроек в БД содержит только `subDomain/subPort/subScheme` (усечённый вывод `strings`) — это клиентская подписка, **не** `outbound_subscriptions` (таблицей подтверждена отдельно ниже).
> ### 🔑 КЛЮЧЕВОЕ ОТКРЫТИЕ: правка идёт через `xrayTemplateConfig` в БД, панель НЕ нужна
> Черновой вывод «нужен доступ к панели 3x-ui» — **❌ НЕВЕРЕН**, снят в этой же сессии. Факты:
> - Таблица **`settings`**, ключ **`xrayTemplateConfig`** (2128 б) — **это и есть** шаблон, из которого 3x-ui генерирует `/app/bin/config.json` при старте. Именно сюда вносятся outbound'ы и routing-правила. **Не править `/app/bin/config.json` — он перезаписывается.**
> - Все ключи `settings` в базе: `secret`, `subDomain`, `subPort`, `subScheme`, `panelGuid`, **`xrayTemplateConfig`**. Ключа `webBasePath` **НЕТ**.
> - Таблица `outbound_subscriptions` **существует, но ПУСТА** (0 записей) — выбран другой путь (см. ниже).
> - `observatory` = `{"subjectSelector":["space-"],"probeUrl":"https://www.google.com/generate_204","probeInterval":"30s","enableConcurrency":true}` — **обязателен для `leastPing`** (иначе балансировщик не знает задержки)
> - **Питфолл REALITY в outbound:** формат `realitySettings` — `serverName` + `publicKey` + `shortId` + `spiderX` + `fingerprint`; `flow: xtls-rprx-vision` кладётся в `users[0].flow` (в подписке он приходит как query-параметр).
> - **Питфолл парсера подписки:** `spx` в ссылке URL-энкодирован (`%2F…`) — обязателен `unquote`, иначе Xray падает на `spiderX`.
>
> ### ✅ Шаг 4 ВЫПОЛНЕН (на Mac) — клиент `vless-space` + SQL, проверен в песочнице
> `apply_space.sql` делает 3 вещи: ① `UPDATE inbounds.settings` (id=1, tag `in-10095-tcp`) — добавляет клиента к `user1`/`kraken-user`; ② `UPDATE settings.xrayTemplateConfig` — новый шаблон; ③ `INSERT INTO clients` — строка клиента для учёта в панели.
>
> **Результат прогона в песочнице (`test_apply.db`) — совпал с ожиданием:**
> | Проверка | Результат |
> |---|---|
> | Клиенты в БД | `user1`, `kraken-user`, **`vless-space`** |
> ### ⏸️ Шаг 5 НЕ ВЫПОЛНЕН — применение в живую БД остановлено (продолжать отсюда)
> **Что произошло:** SSH-сессия к TrueNAS **оборвалась ровно на `docker stop xray-admin`** (`Connection to mallexxx.duckdns.org closed by remote host`). Контейнер поднялся сам (**`restart: unless-stopped`**), БД осталась нетронутой.
>
> **Факт-проверка после обрыва (БД НЕ изменена):** `vless-space` в конфиге — **0**, outbound'ов **3**, правил **1**, `balancer` — **null**.
>
> **Порядок применения (одна короткая команда — SSH к TrueNAS рвётся на длинных операциях):**
> ```bash
> # на TrueNAS, из /mnt/RED_2TB/docker/xray-admin/
> ⚠️ **Питфолл:** `docker stop` у 3x-ui сам корректно закрывает БД и **сливает WAL в основной файл** — поэтому `-wal`/`-shm` надо удалять **после** остановки, иначе правка уйдёт в файл, который потом перезапишется из WAL.
> ⚠️ Если правка выполняется при жизни WAL **без** остановки — риск потери изменений и порчи базы. `sqlite3` в самом контейнере **отсутствует** (`which sqlite3` пусто) — работать только хостовым бинарём или через `alpine`-контейнер.
>
> **Шаг 6 (проверка фактом) — не начат:** временным клиентом с id `vless-space` дёрнуть `curl` и убедиться, что egress **НЕ** `90.189.160.148` (TrueNAS) и **НЕ** `92.62.70.41` (Kraken), а IP сервера из подписки.
> | 4 | Создать клиента `vless-space` в inbound `in-10095-tcp` (панель сгенерит свой `subId`) | ⏳ не начат |
> | 5 | Routing-правило `user: ["vless-space"]` → outbound из подписки (`space-*`) | ⏳ не начат |
> | 6 | Проверка фактом: `curl` через нового клиента → ждём egress **НЕ** `90.189.160.148` и **НЕ** `92.62.70.41`, а IP сервера из подписки | ⏳ не начат |
>
> **Выбор Alex по шагу 5 (открыт):** какой сервер из 28 брать — первый/дефолтный, конкретный (`edge-de`), или балансировщик по всем (тогда нужен `routing.balancers`).
> | 6 | Проверка фактом: egress = IP из подписки | ⏳ не начат |
>| 7 | Обновить доки | ⏳ не начат |
>
> ### ⚠️ Питфоллы, выявленные в этой сессии
> - **Панель отдаёт 403 на логин с дефолтными кредами** — не «панель сломана», а `webBasePath`/пароль заданы. Не подбирать.
> - **`/sub/<subId>` отдаётся без авторизации** (см. вопрос безопасности выше) — при добавлении `vless-space` его sub-ссылка будет так же открыта.
> - **Xray-сервер ≠ Xray-клиент.** `vless-proxy` — клиент (SOCKS → наружу), `xray-admin` — сервер (принимает). Единственный способ заставить `xray-admin` ходить наружу через чужие серверы — `outbound_subscriptions`.
> - **`docker run --rm -v /mnt/RED_2TB/docker/...:/d alpine cat ...`** — рабочий приём чтения root-owned конфигов TrueNAS (в этой сессии апрув-запрос на такую команду **истёк**, повтор без подтверждения не делать).
> - **🔴 SSH к TrueNAS обрывается на `docker stop xray-admin`.** Первое выполнение `docker stop` завершилось `closed by remote host` — контейнер при этом **перезапустился сам** (`restart: unless-stopped`). Длинные операции с остановкой контейнеров делать **одной короткой командой**, а не серией вызовов.
> - **Панель 3x-ui не нужна для этой задачи.** `/login` с `admin/admin` → **403**; но правка идёт через `settings.xrayTemplateConfig`, доступного по БД. Не подбирать пароль, не требовать креды.
> - **Xray-сервер ≠ Xray-клиент.** `vless-proxy` — клиент (SOCKS → наружу), `xray-admin` — сервер (принимает). `xray-admin` ходит наружу только через свои **outbound'ы**; подписка превращается в набор outbound'ов внутри `xrayTemplateConfig`.
> - **`docker exec <c> sh -c "strings <file>"`** — штатный приём чтения бинарных/config-файлов внутри контейнера TrueNAS, где нет `sqlite3`/`jq`/`python3`.
> - **`docker run --rm -v /mnt/RED_2TB/docker/...:/d alpine cat ...`** — рабочий приём чтения root-owned конфигов TrueNAS (`docker cp` с копированием БД на хост тоже работает).
> - **`outbound_subscriptions` vs разворачивание в шаблон:** таблица `outbound_subscriptions` (штатный путь 3x-ui, роуты `/panel/api/xray/outbound-subs[/parse]`) осталась **пустой**. Выбранный путь — «развернуть серверы подписки в обычные outbound'ы + `leastPing`-балансировщик + routing-правило по `user`». Плюс: не зависит от панели. Минус: авто-обновление списка серверов при смене подписки **не автоматическое** — потребуется повторно собрать шаблон (тот же `build_template.py`) и применить. **Для настоящего «auto» нужен cron-скрипт** (тянет подписку → пересобирает шаблон → применяет SQL).
>
> ---
>
> ## ⏳ ПОДЗАДАЧА 2026-09-15: `hermes-taiga` переключить с мёртвого `vless-proxy` (НЕ ВЫПОЛНЕНА)
>
> **Факт:** `hermes-taiga` ходит **НЕ** через `xray-admin`/`user1`, а через **отдельный** контейнер `vless-proxy`.
> - На TrueNAS контейнер `vless-proxy` (teddysun/xray) outbound указывает на `v.qentra.top:443` → **сейчас мёртв**. Hermes-Taiga (SOCKS5 через `vless-proxy:1080`) **без рабочего прокси**.
> - WireGuard Eagle↔VPS↔Kraken: VPS-звено мёртво.
> - Rasputin-роутер VLESS-туннель (`188.239.191.235` / node3.sysnx.net) — это ДРУГОЙ сервер (не qentra), не трогать.
> - Замена для выхода клиентов сети TrueNAS → Kraken: см. **[[tech/xray-reverse-tunnel-kraken-truenas]]** (Xray reverse, ЧАСТИЧНО внедрён: 3x-ui на TrueNAS развёрнут 2026-09-01, reverse-клиент на Kraken ещё нет).
> - Замена для выхода клиентов сети TrueNAS → Kraken: см. **[[tech/xray-reverse-tunnel-kraken-truenas]]** (Xray reverse, ✅ внедрён и проверен end-to-end 2026-09-02).
> - Замена для выхода через **внешнюю подписку** (не через VPS): см. **[[personal/tech/xray-outbound-subscription-3xui]]** (клиент `vless-space` в `xray-admin`, 10 серверов `profilegrid.net`, `leastPing`; ⏳ SQL готов, в БД не применён на 2026-09-15).
> - **Контейнер `vless-proxy`** на TrueNAS до сих пор указывает outbound'ом на мёртвый `v.qentra.top` → `hermes-taiga` без прокси. Готовый план переключения (4 поля в `config.json`) — в [[family/how-to/truenas-infrastructure]] (раздел «ПОДЗАДАЧА 2026-09-15: hermes-taiga»).
> - **Замена для `vless-proxy` (Hermes-Taiga) — ГОТОВЫЙ ПЛАН, НЕ ВЫПОЛНЕН (2026-09-15, вечер):** переписать 4 поля в `/mnt/RED_2TB/docker/vless-proxy/config.json`. Сейчас outbound ⇒ мёртвый `v.qentra.top:443` (VPS удалён). Станет ⇒ `vpn.mallexxx.duckdns.org:443`, VLESS-WS, path `/vless`, host `vpn.mallexxx.duckdns.org`.
# Xray outbound из внешней подписки в 3x-ui (`vless-space`)
> **Статус 2026-09-15:** артефакты **собраны и проверены в песочнице**, применение в живую БД **НЕ выполнено** (SSH к TrueNAS оборвался на `docker stop xray-admin`). Продолжать с §6.
> Разбор контейнера и клиентов — в [[family/how-to/truenas-infrastructure]] (разделы `xray-admin`).
## Задача
Добавить в `xray-admin` (3x-ui на TrueNAS) **третьего клиента**`vless-space`, чей трафик идёт не напрямую (как `user1`) и не через reverse-Кра́кен (как `kraken-user`), а**через серверы внешней Xray-подписки**`profilegrid.net`, с автоматическим выбором живого сервера. `user1` и `kraken-user` не трогаются.
└→ space-01…space-10 (leastPing) → интернет (DE/LV/NL/EE/PL/FR/US/SE/MD)
```
## Ключевые решения и почему
| Решение | Почему |
|---|---|
| **Править `settings.xrayTemplateConfig` в `x-ui.db`, а не панель** | 3x-ui генерирует `/app/bin/config.json` из БД при старте. Панель для этой задачи не нужна (`/login`с`admin/admin` → 403, креды не требовались). `/app/bin/config.json` править **бесполезно** — перезапишется. |
| **Развернуть серверы подписки в обычные outbound'ы** | Не зависит от панели и её версии. Работает сразу после `docker start`. |
| **НЕ использовать таблицу `outbound_subscriptions`** | Штатный путь 3x-ui (роуты `/panel/api/xray/outbound-subs[/parse]`), но требует панели и её сложных полей (`link_identities`, `last_fetched_outbounds`). Таблица осталась **пустой (0 записей)**. |
| **`leastPing` + `observatory`** | Alex: «авто брать» — все 10 серверов в пул, живой выбирается сам. `observatory`**обязателен**, иначе балансировщик не знает задержек. |
| **Правило по `user`, а не по клиентскому id** | Образец взят с рабочего `kraken-user-via-reverse`: Xray матчит клиента inbound'а по `email`. |
## Питфоллы (все проверены фактом)
1.**🔴 SSH к TrueNAS обрывается на `docker stop xray-admin`** — `closed by remote host`. Контейнер **сам поднялся** (`restart: unless-stopped`), БД не пострадала. Останавливать и применять SQL **одной короткой командой**, не серией вызовов.
2.**WAL:**`docker stop` у 3x-ui корректно закрывает БД и **сливает WAL в основной файл**. Удалять `-wal`/`-shm` можно только **после** остановки. Правка при живом WAL = риск порчи базы.
3.**`sqlite3` внутри контейнера ОТСУТСТВУЕТ** (`which sqlite3` пусто). Использовать: `docker cp` БД на хост, либо хостовый `sqlite3`, либо `alpine`-контейнер.
4.**Дедуп подписки:** 28 строк → **10 уникальных серверов**. Одна подписка отдаёт несколько записей на один хост с разными `pbk`/`sid` (перебор ключей). Ключ дедупа — `host + publicKey + shortId`.
5.**REALITY в outbound:** параметры кладутся в `streamSettings.realitySettings` (`serverName`, `publicKey`, `shortId`, `spiderX`, `fingerprint`), а`flow: xtls-rprx-vision` — в `users[0].flow` (в ссылке он приходит query-параметром).
6.**`spx` в ссылке URL-энкодирован** (`%2F…`) — обязателен `unquote`, иначе Xray падает на `spiderX`.
8.**Правки в `routing.rules` добавлять В КОНЕЦ** — существующие правила (`api`, `geoip:private→blocked`, `bittorrent→blocked`, `kraken-user→via-kraken`) должны сохранить приоритет.
docker exec xray-admin sh -c "cat /app/bin/config.json"| jq -c '.routing.balancers'
```
```bash
# end-to-end: временный xray-клиент с id vless-space → curl api.ipify.org
# ожидаем egress НЕ 90.189.160.148 (TrueNAS) и НЕ 92.62.70.41 (Kraken),
# а IP сервера из подписки (DE/LV/NL/…)
```
**Откат:** бэкап `/mnt/RED_2TB/docker/backups/xray-admin-before-vless-space-20260915-012057/` → скопировать `x-ui.db` обратно (при остановленном контейнере) → `docker start xray-admin`.
## Ограничение: «auto» здесь НЕ автоматическое
Выбранный путь разворачивает серверы подписки в **статические** outbound'ы. Если провайдер сменит список серверов, шаблон надо **пересобрать вручную**: `build_template.py` → `make_sql.py` → применить.
**Для настоящего авто-обновления нужен cron-скрипт на TrueNAS:**
Не реализован. Альтернатива без скрипта — использовать штатную таблицу `outbound_subscriptions` через панель (даёт `update_interval` из коробки, но требует доступа к UI).
## Открытый вопрос безопасности (не решён)
`/sub/<subId>` отдаётся **без авторизации** (`/sub/abc` тоже 200). Новая ссылка `vless-space` будет так же открыта. Варианты: подписка по токену, ротация `subId`. Задано Alex 2026-09-15, решения нет.
portal+bridge BOTH pinned to 26.4.25; required but insufficient by itself.
verified_fix_2026_09_02:>-
@@ -26,6 +27,16 @@ verified_fix_2026_09_02: >-
# Xray Reverse Tunnel — Kraken ↔ TrueNAS
> ## 🔀 НЕ ПУТАТЬ с egress-подпиской (2026-09-15)
> У `xray-admin` **три независимых механизма выхода**, их легко перепутать:
> | Механизм | Кто выходит | Док |
> |---|---|---|
> | `user1` → outbound `direct` | клиент выходит через **TrueNAS** `90.189.160.148` | ниже |
> | `kraken-user` → `via-kraken` → **этот** reverse-туннель | клиент выходит через **Кра́кен** `92.62.70.41` | **этот док** |
> | `vless-space` → `space-balancer` (`space-01…10`) | клиент выходит через **внешнюю подписку** `profilegrid.net` | [[personal/tech/xray-outbound-subscription-3xui]] |
>
> Reverse-туннель (portal на TrueNAS + bridge на Кра́кене) — отдельные контейнеры, `xray-admin` его лишь **использует** как outbound `via-kraken` (SOCKS `xray-reverse-portal:12345`). Подписочный клиент `vless-space` reverse-туннель **не задействует**.
> **Статус: ✅ ВНЕДРЕНО И ПРОВЕРЕНО END-TO-END (2026-09-02).** TrueNAS SOCKS `:12345` → VLESS Reverse TCP+REALITY+Vision → Kraken → internet работает. HTTP и HTTPS тесты оба вернули выходной IP Kraken `92.62.70.41`. **Истинная причина:** Docker bridge/NAT на Kraken сбрасывал reverse mux; bridge должен работать с `network_mode: host`. Более ранние секции со статусом «не работает» и гипотезами #6612/#6242 сохранены ниже как история диагностики и суперсидированы секцией «Верифицированный фикс».
> Архитектурное решение: проксировать исходящий трафик локальных клиентов сети TrueNAS через **TrueNAS → Kraken → интернет**.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Alexey Martemyanov