137 lines
10 KiB
Markdown
137 lines
10 KiB
Markdown
# VPnBot Xray patches
|
||
|
||
Этот репозиторий хранит только наши изменения для Xray-core. Полной копии
|
||
чужого проекта здесь нет: `scripts/prepare-source.sh` получает точный тег из
|
||
официального [`XTLS/Xray-core`](https://github.com/XTLS/Xray-core), проверяет
|
||
его commit и последовательно накладывает три файла из `patches/`.
|
||
|
||
Патчи добавляют capability-маркер `vpnbot-active-revoke-v3`. Он означает, что
|
||
после удаления пользователя через Xray API закрываются уже установленные
|
||
VLESS, Trojan, VMess и Shadowsocks-сессии этого пользователя. Обычный
|
||
официальный Xray запрещает только новые подключения; поэтому до принятия этого
|
||
механизма upstream-проектом VPnBot не может безопасно устанавливать чистый
|
||
официальный бинарник на платные узлы.
|
||
|
||
Второй маркер `vpnbot-live-user-audit-v1` означает, что команда
|
||
`xray api vpnbot-audit-users` читает всех пользователей всех inbound через
|
||
один процесс и одно локальное gRPC-соединение. Команда делает два полных
|
||
прохода и сверяет каждый список с `GetInboundUsersCount`; узловой помощник
|
||
сравнивает оба прохода и по-прежнему безопасно отказывает при любой
|
||
неоднозначности. На старых узлах без маркера остаётся совместимый, но более
|
||
дорогой аудит отдельными командами.
|
||
|
||
## Граница источников
|
||
|
||
- чужой исходный код загружается только из официального GitHub XTLS;
|
||
- Forgejo хранит наши патчи, проверки, сборочные сценарии и готовые релизы;
|
||
- тег и commit upstream закреплены в `upstream.env` для ручной сборки, а
|
||
автоматический выпуск создаёт отдельный build-env с теми же строгими
|
||
проверками;
|
||
- SHA-256 каждого патча закреплён в `patches/series`;
|
||
- Actions заново применяет патчи к официальному исходнику, запускает профильные
|
||
тесты и собирает три Linux-архива, которые используются VPnBot.
|
||
|
||
## Автоматические dev-релизы
|
||
|
||
Workflow `Follow official Xray dev releases` каждые шесть часов читает
|
||
официальный `XTLS/Xray-core/releases.atom`, после чего временным shallow
|
||
Git-fetch получает ровно найденный тег, его commit, время и `go.mod`.
|
||
GitHub API, API-токен, подвижная ветка `main` и постоянная локальная копия
|
||
Xray-core для discovery не используются. Официальный prerelease/dev-тег для
|
||
него является нормальным входом, но не становится стабильным релизом VPnBot
|
||
сразу.
|
||
|
||
Цепочка разделена на два состояния:
|
||
|
||
1. Actions разрешает тег в точный официальный commit, применяет патчи, запускает
|
||
unit- и real-process-тесты, собирает архивы и публикует Forgejo prerelease с
|
||
суффиксом `-candidate.1`.
|
||
2. Root-only таймер на production-хосте устанавливает точный кандидат на
|
||
выделенный canary-узел, проверяет живую конфигурацию и запускает изолированный
|
||
VLESS-сценарий с двумя непрерывными потоками. После удаления пользователя A
|
||
поток A должен закрыться не позднее 10 секунд, а поток B — продолжить
|
||
работу. Тот же canary до и после удаления проверяет двухпроходную команду
|
||
live-аудита и не сохраняет пользовательские идентификаторы в proof-файле.
|
||
3. Только после этого создаётся обычный `proven`-релиз. Его файлы копируются из
|
||
candidate без пересборки и поэтому имеют ровно те же SHA-256.
|
||
|
||
Стабильные Xray-updater-таймеры на узлах используют канал `stable`: они
|
||
игнорируют `prerelease=true` и видят только proven-релизы. При конфликте патча,
|
||
падении теста, недоступном canary или неуспешном отзыве новый stable-релиз не
|
||
создаётся.
|
||
|
||
Каждый candidate содержит `vpnbot-xray-release-manifest.json` с официальным
|
||
тегом/commit, SHA-256 патчей и архивов. Proven дополнительно содержит
|
||
`vpnbot-xray-pilot-proof.json`, то есть машинно проверяемый отчёт живого пилота.
|
||
Для Linux amd64 один выпуск содержит два архива из одного и того же исходника:
|
||
совместимый `Xray-linux-64.zip` (`GOAMD64=v1`) и оптимизированный
|
||
`Xray-linux-64-v3.zip` (`GOAMD64=v3`). Манифест схемы 3 закрепляет требования
|
||
к процессору, узловой updater выбирает вариант по фактически видимым гостевой
|
||
системе CPU flags, а production-canary обязан доказать именно v3-вариант.
|
||
Схема 3 дополнительно закрепляет обязательный `vpnbot-live-user-audit-v1`,
|
||
чтобы старый бинарник нельзя было ошибочно продвинуть как новый выпуск с
|
||
однопроцессным аудитом.
|
||
Полная модель состояний, гонок и rollback описана в
|
||
[`docs/2026-08-07-automatic-dev-release-plan.md`](docs/2026-08-07-automatic-dev-release-plan.md).
|
||
|
||
Production-компонент устанавливается от root:
|
||
|
||
```bash
|
||
scripts/install_promoter.sh
|
||
```
|
||
|
||
Перед включением таймера нужен runtime-файл
|
||
`/etc/vpnbot-xray-release-promoter.env` по примеру из `systemd/` и root-only
|
||
Forgejo-токен с областью `write:repository`. Токен, SSH-ключ и состояние пилота
|
||
не хранятся в Git.
|
||
|
||
Тот же установщик добавляет независимый наблюдатель
|
||
`vpnbot-xray-release-alert.timer`. Он раз в пять минут проверяет последний
|
||
`candidate.yml`, возраст опубликованных candidate без proven и root-only
|
||
состояние canary. Оператор получает Telegram-сообщение при безопасной остановке
|
||
выпуска, редкое напоминание для продолжающейся аварии и отдельное сообщение о
|
||
подтверждённом восстановлении. Переходный retry workflow или canary не считается
|
||
восстановлением.
|
||
|
||
Forgejo может показывать публичные Actions-запуски в интерфейсе, но возвращать
|
||
пустой `workflow_runs` через публичный API. В таком случае наблюдатель читает
|
||
страницу именно `candidate.yml`, выбирает последний запуск `main` и извлекает
|
||
только встроенное структурированное JSON-состояние страницы запуска. Он не
|
||
угадывает результат по цвету иконки или локализованному тексту. Незавершённый
|
||
запуск старше общего `stall`-интервала становится отдельной аварией runner,
|
||
потому что бесконечное `waiting` иначе оставляло бы сторож молчащим.
|
||
|
||
Для наблюдателя нужен `/etc/vpnbot-xray-release-alert.env` по отдельному примеру
|
||
из `systemd/`. В нём нет токена Telegram: скрипт читает только
|
||
`VPNBOT_BOT_TOKEN` из существующего root-only runtime-env VPnBot. Долговечное
|
||
состояние дедупликации хранится в
|
||
`/var/lib/vpnbot-xray-release-alert/state.json` и никак не участвует в решении о
|
||
публикации proven.
|
||
|
||
Режимы ручной проверки после установки:
|
||
|
||
```bash
|
||
sudo -n /usr/local/libexec/vpnbot-xray-release-promoter/release_alert_monitor.py --print-status
|
||
sudo -n /usr/local/libexec/vpnbot-xray-release-promoter/release_alert_monitor.py --send-test
|
||
```
|
||
|
||
Первый вызов ничего не отправляет и не меняет incident-state. Второй отправляет
|
||
одно явно помеченное тестовое сообщение и тоже не создаёт ложную аварию.
|
||
|
||
## Локальная проверка
|
||
|
||
```bash
|
||
scripts/test-patches.sh
|
||
scripts/build-release.sh ./release-assets
|
||
```
|
||
|
||
Для подготовки исходного дерева без сборки:
|
||
|
||
```bash
|
||
scripts/prepare-source.sh ./xray-with-vpnbot-patches
|
||
```
|
||
|
||
Каталоги назначения должны отсутствовать или быть пустыми.
|
||
|
||
Исходный Xray-core и изменённые файлы распространяются по Mozilla Public
|
||
License 2.0. Полный текст лицензии находится в `LICENSE`.
|