fix(admin): связать отзыв учётных данных с идентичностью сессий и свести адрес control plane к одному

Отзыв секрета не сходился: `auth_id` при смене секрета оставался прежним, поэтому сессия, установленная по отозванным учётным данным, была неотличима от законной, и цикл учёта не имел признака, по которому её следовало завершить. У состояния есть путь без единой неудачи — Hysteria регистрирует соединение в Traffic Stats API только после возврата backend-auth, поэтому успешный /kick может пройти мимо. Новое поколение credentials получает новый auth_id, kick идёт по старому, пережившая сессия становится orphan. Адрес Traffic Stats API имел два контракта: оркестратор принимал любой IPv4, админка всегда шла на loopback. Валидная по всем гейтам конфигурация выключала лимит устройств, учёт трафика и принудительное отключение разом. Адрес зафиксирован, а расхождение файла с ним админка называет. Состояние службы стало трёхзначным: util.Exec выбрасывал вывод systemctl при ненулевом коде, поэтому «остановлена» и «спросить не удалось» приходили одним значением, а доступность Traffic Stats API выводилась из него же. Журнал Hysteria разбирается в фактическом формате upstream (time — дробное число), страница конфигурации показывает файл вместо дефолтов UI и не возит секреты в браузер, санитайзер выгрузки следует по YAML-якорям. Разбор: docs/acceptance/2026-09-02-v1.0.0-rc4-preflight-findings.md
2026-09-02 23:24:01 +05:00
parent 8dcb50a07c
commit cb20d8d28f
66 changed files with 4981 additions and 2684 deletions
@@ -347,6 +347,56 @@ ClientAliveCountMax 2
 - auth material
 - что используется совместимый клиентский конфиг

+### Ни один пир не проходит авторизацию
+
+Симптом резкий: подключения перестают устанавливаться у всех сразу, в журнале
+админки — `device limit unavailable`.
+
+Лимит устройств проверяется **fail-closed**: без ответа `/online` админка не
+знает, сколько устройств уже на связи, и пускать подключения не имеет права.
+Значит вопрос ровно один — почему недоступен Traffic Stats API.
+
+```bash
+# 1. что записано в конфиге
+grep -A2 '^trafficStats:' /etc/hysteria/config.yaml
+
+# 2. отвечает ли API по этому адресу
+curl -sS -H "Authorization: <trafficStatsSecret>" http://127.0.0.1:36712/online
+
+# 3. что говорит сама админка
+journalctl -u hy2xs-admin -n 100 --no-pager | grep -i 'traffic stats'
+```
+
+Частая причина — правка `trafficStats.listen` руками. Админка обращается к
+Traffic Stats API **только по loopback**, поэтому адрес вроде `192.168.1.10`
+разводит Hysteria и панель по разным адресам: сама Hysteria работает, туннели
+существующих клиентов живут, но лимит устройств, учёт трафика и принудительное
+отключение выключаются разом. С таким конфигом админка отказывает явно:
+
+```text
+trafficStats.listen слушает 192.168.1.10, а админка обращается к Traffic Stats
+API только по loopback. ...Верните 127.0.0.1 через `hy2xs-orchestrator reconfigure`
+```
+
+Страница конфигурации показывает тот же адрес и помечает его как не-loopback.
+
+### Дашборд показывает «состояние службы неизвестно»
+
+Это **не** «Hysteria остановлена». Значение означает, что не удалось получить
+ответ `systemctl is-active hysteria-server`: сломанный или недоступный systemctl
+при живой Hysteria выглядит именно так.
+
+Проверяется отдельно от туннеля:
+
+```bash
+systemctl is-active hysteria-server   # active | inactive | failed | ...
+```
+
+Доступность Traffic Stats API на дашборде — независимый факт, полученный
+фактическим обращением к API. Сочетание «состояние неизвестно» + «API доступен»
+означает исправно работающий туннель и сломанную диагностику службы; сочетание
+«служба активна» + «API недоступен» — предыдущий раздел.
+
 ### Install/reconfigure падает на DNS AAAA
 Проверить значение `HY2XS_DNS_AAAA_POLICY` в `/etc/hy2xs/hy2xs.env`:
 - `strict` (default): AAAA приводит к fail в IPv4-only профиле;