Эксплуатация и проверка узла AeroNyx

Это руководство по эксплуатации описывает повседневные команды для зарегистрированного узла AeroNyx: статус, проверку состояния, журналы, доказательства работы ретрансляции и почтового ящика, безопасные обновления, откат и проверки после перезапуска. Все команды находятся в репозитории узла (deploy/node/aeronyx-node.sh и исполняемый файл aeronyx-server) и приведены с теми параметрами, которые принимает код.

Если вы ещё не установили узел, начните с Установка и регистрация узла AeroNyx.

Перед началом

Выполняйте все команды из оболочки root (sudo -i). Каталог конфигурации /etc/aeronyx и каталог состояния /var/lib/aeronyx имеют права 700, поэтому команды статуса, проверки состояния, валидации и ретрансляции не могут прочитать их от имени другого пользователя.

Перейдите в репозиторий, из которого фактически работает служба, и передавайте его через --repo-dir в каждой команде скрипта. Без --repo-dir скрипт предполагает путь /opt/aeronyx/AeroNyx.

cd "$(systemctl show aeronyx-server -p WorkingDirectory --value)"
pwd

На узлах, установленных командой из Nodeboard, будет выведено /root/open/AeroNyx.

Краткий обзор команд

Статус

./deploy/node/aeronyx-node.sh status --repo-dir "$PWD"

status выводит по порядку:

1. systemctl status aeronyx-server (последние 20 строк)
2. сводку локального API состояния (http://127.0.0.1:8421/api/vpn/health) и API статуса оператора (http://127.0.0.1:8421/api/operator/status)
3. локальную готовность обнаружения из http://127.0.0.1:8422/api/discovery/status: анонсирование ChatRelay и кворум пиров
4. состояние последней процедуры обновления из /var/lib/aeronyx/upgrade-status.json
5. рекомендацию для оператора: operator_status, operator_title, operator_detail и operator_next_step

Рекомендация формируется по результатам проверки состояния. Её статус принимает одно из значений:

Проверка состояния

./deploy/node/aeronyx-node.sh health --repo-dir "$PWD" --json

Проверка состояния читает файлы, systemd и локальные конечные точки; она никогда не изменяет систему. Каждая проверка выводит [PASS], [WARN] или [FAIL], затем строку [SUMMARY] pass=… warn=… fail=…, затем одну строку JSON. Используйте --json-only, чтобы вывести только JSON. Команда завершается с ненулевым кодом, если какая-либо проверка не пройдена.

Что проверяется: репозиторий, отслеживаемый Cargo.lock и исполняемый файл релиза; валидация конфигурации с помощью aeronyx-server validate; файлы регистрации и ключей; модуль systemd, политика перезапуска и усиление защиты; память, диск и порты 51820 и 8421; пересылка IP и NAT; локальная конечная точка состояния; обнаружение; резервные копии релизов.

Основные поля JSON:

Исходные локальные конечные точки можно прочитать напрямую:

curl -s http://127.0.0.1:8421/api/vpn/health
curl -s http://127.0.0.1:8422/api/discovery/status

Журналы

./deploy/node/aeronyx-node.sh logs --repo-dir "$PWD" --lines 200
./deploy/node/aeronyx-node.sh logs --repo-dir "$PWD" --follow

Это обёртки над journalctl -u aeronyx-server -n <lines> --no-pager (по умолчанию 160 строк) и journalctl -u aeronyx-server -f. Для выборки по времени используйте journalctl напрямую, например journalctl -u aeronyx-server --since "1 hour ago".

Доказательства работы ретрансляции и почтового ящика

Эти команды отвечают на разные вопросы. Не считайте успешную синтетическую проверку доказательством реальной доставки.

relay-probe (синтетическая проверка)

./deploy/node/aeronyx-node.sh relay-probe --repo-dir "$PWD" --json
./deploy/node/aeronyx-node.sh relay-probe --repo-dir "$PWD" --two-hop --json

Отправляет один синтетический случайный непрозрачный конверт BlindRelay с этого узла на обнаруженный пир ChatRelay и сообщает только об изменениях счётчиков. --two-hop отправляет его через промежуточный узел на конечный узел. Поле status в результате принимает значение ok, attention, blocked или error, а two_hop_readiness объясняет, чего не хватает, если двухшаговый путь невозможен. Команда читает кэш пиров и ключ узла, поэтому ей нужны права root. Это не пользовательский трафик, и она не доказывает доставку в почтовый ящик. fleet-smoke выполняет аналогичную синтетическую проверку на нескольких публичных узлах, которые вы перечисляете в --endpoints.

relay-smoke (аутентифицированная, сквозная)

./target/release/aeronyx-server relay-smoke --confirm-live-relay-smoke --json

relay-smoke действует как реальный клиент по отношению к узлу на этом хосте. Он открывает два кратковременных сеанса с одноразовыми идентичностями и выполняет производственное рукопожатие с закреплением ключа этого узла. Он отправляет одно случайное сообщение размером 48 байт со сквозным шифрованием по аутентифицированному многошаговому пути ретрансляции. Затем он проверяет подписанное подтверждение конечного узла именно для этого запроса, забирает сообщение из почтового ящика этого узла, расшифровывает его, подтверждает получение и проверяет, что почтовый ящик пуст, а сеансы закрыты.

Он отказывается запускаться, если не пройдены все условия:

Примечания:

• Команду нужно запускать от root на самом узле. Она читает /etc/aeronyx/server.toml и ключ узла и принимает только адреса loopback (--server, по умолчанию 127.0.0.1:51820; --health-url, по умолчанию http://127.0.0.1:8421/api/vpn/health).
• --timeout-seconds задаёт окно доказательства: от 5 до 120 секунд, по умолчанию 30.
• Требование нуля активных сеансов означает, что узел, обслуживающий пользователей VPN, нужно сначала освободить. Включите Maintenance Mode в Nodeboard и дождитесь, пока число сеансов станет нулевым.
• Два тестовых сеанса — это реальные сеансы протокола, поэтому они могут ненадолго появиться в разделе Sessions в Nodeboard.
• При успехе "status": "passed", а terminal_receipt_observed, entry_mailbox_round_trip_verified, entry_mailbox_ack_verified и e2e_ciphertext_verified все равны true, и session_cleanup имеет значение explicit_authenticated_close. terminal_replica_cleanup имеет значение node_ttl_managed: подтверждение на входном узле не удаляет копию, хранящуюся на конечном узле; она истекает сама.
• Любое непройденное условие, ошибка или отсутствующее поле означает проваленное доказательство, а не частичный успех.

mailbox-probe (со стороны клиента)

./target/release/aeronyx-server mailbox-probe \
  --seed http://SEED_PUBLIC_IP:8422 \
  --target <64-hex node ID of the mailbox node> \
  --entry <64-hex node ID of a different entry node> \
  --confirm-live-mailbox-probe --json

mailbox-probe ведёт себя как приложение: использует одноразовые ключи, строит собственный луковый маршрут из подписанных дескрипторов, собранных с узлов --seed, и отправляет обычные HTTP-запросы к публичному API пиров входного узла без сеанса VPN. Он выполняет полный жизненный цикл анонимного почтового ящика на целевом узле: ticket_issue, lease_create, put, pull_one, ack и завершающий pull_one. Он проверяет, что полученные байты совпадают и что после этого почтовый ящик пуст. При успехе выводится "status": "verified" и количество шагов.

• --seed можно указывать несколько раз. Без --entry маршрут состоит из одного шага.
• Идентификатор узла — это 64-символьный шестнадцатеричный открытый ключ узла. На узле, которым вы управляете, его выводит ./target/release/aeronyx-server pubkey -c /etc/aeronyx/server.toml.
• На целевом узле должен быть включён анонимный почтовый ящик ([memchain.chat_relay.anonymous_mailbox] enabled = true); по умолчанию он отключён.
• --work-bits (по умолчанию 12) должно быть не меньше настройки работы для тикетов на целевом узле. --timeout-seconds задаётся на каждый запрос (по умолчанию 20).
• Команда не читает локальные файлы узла, поэтому её можно запускать с любой машины, где есть исполняемый файл. Она доказывает хранение непрозрачного элемента, но не то, что получатель может его расшифровать.

Безопасное обновление

Используйте процедуру обновления, а не git pull с последующим systemctl restart:

./deploy/node/aeronyx-node.sh upgrade --repo-dir "$PWD" --build-priority live --build-jobs auto

Что она делает:

1. Захватывает блокировку развёртывания и отказывается работать, если отслеживаемые файлы в рабочей копии изменены (--allow-dirty отменяет это ограничение).
2. Получает main (или собирает точный коммит в изолированной рабочей копии с --commit <40-hex SHA>).
3. Выполняет сборку закреплённым в репозитории набором инструментов Rust. Приоритет live (по умолчанию) и --build-jobs auto используют примерно половину процессоров, чтобы работающий узел продолжал обслуживание.
4. Проверяет /etc/aeronyx/server.toml новым исполняемым файлом. Файл конфигурации никогда не перезаписывается.
5. Создаёт резервную копию фактически работающего исполняемого файла в /var/lib/aeronyx/releases/.
6. Проверяет активные сеансы после сборки и ещё раз непосредственно перед перезапуском. Если они есть или их количество невозможно прочитать во время работы службы, процедура останавливается без смены версии.
7. Обновляет модули systemd, подменяет исполняемый файл новым и перезапускает службу.
8. До 180 секунд (90 проверок с интервалом 2 секунды) ожидает, пока локальная проверка состояния сообщит ok от только что собранного коммита. Если перезапуск, состояние службы или проверка состояния завершаются неудачей, она автоматически восстанавливает предыдущий исполняемый файл и модули.
9. Хранит 10 последних резервных копий каждого типа и записывает результат в /var/lib/aeronyx/upgrade-status.json.

Если у узла есть активные сеансы, сборка всё равно выполняется, после чего обновление останавливается с сообщением Active sessions appeared during compilation. Enter maintenance mode, drain sessions, and run the upgrade again. Включите Maintenance Mode в разделе Settings в Nodeboard, дождитесь, пока число активных сеансов станет нулевым, и снова выполните ту же команду. Повторная сборка использует кэш.

Подготовить сейчас, перезапустить позже

./deploy/node/aeronyx-node.sh upgrade --repo-dir "$PWD" --no-restart

--no-restart выполняет сборку, проверку и резервное копирование, затем устанавливает новый исполняемый файл на диск без перезапуска. После этого status сообщает upgrade_staged. Работающий процесс сохраняет старую версию. Любой последующий перезапуск, включая перезагрузку или автоматический перезапуск после сбоя, запустит новый исполняемый файл.

Чтобы переключиться в окне обслуживания, освободите узел и снова запустите обновление без получения изменений, чтобы оно переключилось именно на подготовленную версию с проверкой сеансов, ожиданием состояния и откатом:

./deploy/node/aeronyx-node.sh upgrade --repo-dir "$PWD" --skip-pull

Не используйте --force. Он выполняет перезапуск, даже если есть активные сеансы или их количество неизвестно, и отключает пользователей.

Ручной откат

Обновление откатывается автоматически, если новый релиз не запускается или не сообщает об исправном состоянии. Чтобы позже вернуться к более раннему релизу, повысьте один из сохранённых исполняемых файлов:

ls -lt /var/lib/aeronyx/releases/
./deploy/node/aeronyx-node.sh promote-binary --repo-dir "$PWD" \
  --binary /var/lib/aeronyx/releases/<aeronyx-server.binary.YYYYMMDD_HHMMSS.xxxxxx>

promote-binary проверяет конфигурацию выбранным исполняемым файлом и отказывается работать, если число активных сеансов не равно ровно нулю. Команда просит ввести PROMOTE BINARY, сохраняет резервную копию текущего исполняемого файла рядом с ним, подменяет исполняемый файл и перезапускает службу. Если служба не перейдёт в исправное состояние в течение 180 секунд, команда восстановит предыдущий исполняемый файл. Она заменяет только исполняемый файл, но не модули systemd.

После любого перезапуска

Проверьте по порядку:

1. systemctl is-active aeronyx-server возвращает active. Модуль имеет тип Type=notify, поэтому active означает, что процесс сообщил о готовности; запуск может занять до 300 секунд, прежде чем systemd прекратит ожидание.
2. ./deploy/node/aeronyx-node.sh status --repo-dir "$PWD" показывает operator_status=ok или понятное вам предупреждение.
3. ./deploy/node/aeronyx-node.sh health --repo-dir "$PWD" --json завершается строкой с "success":true, а local_vpn_health.status равно ok.
4. Работающий коммит — тот, который вы планировали: curl -s http://127.0.0.1:8421/api/vpn/health сообщает его как runtime.git_commit. (runtime.git_commit в health --json — это коммит рабочей копии.)
5. discovery_readiness.peer_quorum.quorum_ready равно true после первых раундов gossip.
6. Для узлов ретрансляции: relay-probe --two-hop --json сообщает ok.
7. В Nodeboard heartbeat свежий, Rust Runtime показывает новую версию, а перезапуск отображается в разделе Alerts / Events. По завершении отключите Maintenance Mode.
8. В journalctl -u aeronyx-server --since "15 min ago" нет повторяющихся ошибок.

Как это отображается в Nodeboard

Nodeboard получает подписанные heartbeat и отчёты о сеансах узла. Сам по себе он не выполняет команды на хосте; выбранные там действия ставятся в очередь, и узел выполняет их при следующем heartbeat.

На странице сведений об узле также есть карточка Operator Runbook с копируемыми командами health, status, logs и подготовки обновления для обнаруженного пути репозитория.

Что содержат выходные данные

status, health, relay-probe, relay-smoke и mailbox-probe выводят только агрегированные значения: количества, состояния, временные показатели и коды причин. Они не выводят закрытые ключи, регистрационные коды, публичные IP-адреса клиентов, адреса назначения, содержимое DNS, полезную нагрузку или открытый текст сообщений. Записи о сеансах с ключами клиентов видны в Nodeboard, а не в этих выходных данных; см. Руководство по консоли оператора Nodeboard. Передавая выходные данные в поддержку, отправляйте JSON и его метку времени, а не адреса хостов или учётные данные.

Часто задаваемые вопросы

Какую команду запустить первой, если что-то выглядит не так?

Запустите ./deploy/node/aeronyx-node.sh status --repo-dir "$PWD" от root. Она показывает состояние службы, локальное состояние, обнаружение и рекомендуемый следующий шаг и не изменяет систему.

Почему проверка состояния завершается ошибкой «config missing» или предупреждениями Git?

Вероятно, вы работаете не от root или указываете не тот репозиторий. /etc/aeronyx и /var/lib/aeronyx доступны только root, а без --repo-dir скрипт проверяет /opt/aeronyx/AeroNyx вместо рабочей копии, из которой работает служба.

Чем relay-probe отличается от relay-smoke?

relay-probe отправляет один синтетический непрозрачный конверт и лишь показывает, что путь ретрансляции принимает трафик. relay-smoke действует как реальный клиент: проверяет подписанное подтверждение конечного узла, а также полное извлечение из почтового ящика и подтверждение получения для одного зашифрованного тестового сообщения.

Почему relay-smoke требует ноль активных сеансов?

Он относит изменения счётчиков к своим собственным тестовым сеансам, поэтому работает только на простаивающем узле. Включите Maintenance Mode в Nodeboard, дождитесь, пока число активных сеансов станет нулевым, и запустите его.

Можно ли обновиться, не отключая пользователей?

Собрать и подготовить обновление с --no-restart можно, пока пользователи подключены. Переход на новую версию требует перезапуска, поэтому освободите узел с помощью Maintenance Mode, а затем выполните upgrade --skip-pull.

Как вернуться к предыдущей версии?

Неудачное обновление откатывается автоматически. Чтобы откатиться позже, используйте promote-binary с одной из резервных копий в /var/lib/aeronyx/releases/; команда требует ноль активных сеансов и восстанавливает предыдущий исполняемый файл, если повышенный оказался неисправен.