prod/HY2XS_flamy
5
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 6 Wiki Activity

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

Browse Source 
Отзыв секрета не сходился: `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
This commit is contained in:
Crimson
2026-09-02 23:24:01 +05:00
parent 8dcb50a07c
commit cb20d8d28f
66 changed files with 4981 additions and 2684 deletions
Download Patch File Download Diff File Expand all files Collapse all files
orchestrator/src/config/env.ts
+33
View File
@@ -315,6 +315,39 @@ export function validateRuntimeConfig(config: RuntimeConfig): void {
if (config.hysteriaBindHost !== "0.0.0.0") {
throw new Error("HY2XS_HYSTERIA_BIND_HOST must be 0.0.0.0 in production profile");
}
/**
* Traffic Stats API — ВНУТРЕННИЙ control plane, и его адрес не является
* операторской настройкой.
*
* Что было. `normalizeIpv4Host` принимал любой корректный IPv4, шаблон
* честно рендерил `trafficStats.listen: <любой IP>:36712`, и проверка
* профиля сверяла конфиг с тем же значением — то есть валидная с точки
* зрения всех гейтов конфигурация ломала продукт.
*
* Ломала потому, что у второй половины продукта контракт другой: админка
* берёт из `trafficStats.listen` только ПОРТ и всегда ходит на loopback
* (apps/proxy/hysteria2_api.go). При `HY2XS_HYSTERIA_TRAFFIC_STATS_HOST`
* равном, скажем, LAN-адресу, Hysteria слушает один адрес, админка стучится
* в другой, и дальше по цепочке: `/online` недоступен -> лимит устройств
* fail-closed -> отказ авторизации ВСЕМ пирам, учёт трафика и принудительное
* отключение не работают. Всё это — от одной строки в env, прошедшей все
* проверки.
*
* `0.0.0.0` отдельным дефектом не является — админка достучится через
* loopback, — но публикует внутренний API на всех интерфейсах, что при
* `HY2XS_FIREWALL_MODE=external|off` не прикрыто ничем.
*
* Поэтому адрес фиксирован. Делать его настраиваемым на стороне админки —
* неверное направление: у внутреннего API одного процесса на одной машине
* нет сценария, в котором ему нужен другой адрес.
*/
if (config.hysteriaTrafficStatsHost !== "127.0.0.1") {
throw new Error(
"HY2XS_HYSTERIA_TRAFFIC_STATS_HOST is fixed in the HY2XS production profile: 127.0.0.1. " +
"Traffic Stats API is an internal control plane: the admin backend always reaches it over loopback, " +
"so any other address leaves Hysteria and the panel talking past each other."
);
}
if (!config.uiPublicAccess && config.uiBindHost !== "127.0.0.1") {
throw new Error("HY2XS UI must bind to 127.0.0.1 in production baseline");
}