AeroNyx ノードの運用と確認

このランブックでは、登録済みの AeroNyx ノードの日常的なコマンドを扱います：ステータス、ヘルス、ログ、リレーとメールボックスの証明、安全なアップグレード、ロールバック、そして再起動後に確認すべき事項です。すべてのコマンドはノードリポジトリ（deploy/node/aeronyx-node.sh と aeronyx-server バイナリ）に含まれており、コードが受け付けるオプションとともに示しています。

まだノードをインストールしていない場合は、AeroNyx ノードのインストールと登録から始めてください。

始める前に

すべて root シェル（sudo -i）から実行してください。設定ディレクトリ /etc/aeronyx と状態ディレクトリ /var/lib/aeronyx はモード 700 のため、他のユーザーでは status、health、検証、リレーの各コマンドがこれらを読み取れません。

サービスが実際に実行されているリポジトリに移動し、すべてのスクリプトコマンドで --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=… の行、最後に 1 行の JSON を出力します。JSON のみを出力するには --json-only を使用します。いずれかのチェックが失敗すると、コマンドは 0 以外の終了ステータスで終了します。

チェック対象：リポジトリ、追跡対象の 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

このノードから、発見済みの ChatRelay ピアへ、合成されたランダムで不透明な BlindRelay エンベロープを 1 つ送信し、カウンターの変化のみを報告します。--two-hop を指定すると、中間ホップを経由して終端ノードへ送信します。結果の status は ok、attention、blocked、error のいずれかで、2 ホップ経路が成立しない場合は two_hop_readiness が不足している要素を説明します。ピアキャッシュとノードの鍵を読み取るため、root が必要です。これはユーザートラフィックではなく、メールボックスへの配信を証明するものでもありません。fleet-smoke は、--endpoints で列挙した複数のパブリックノードに対して同様の合成チェックを実行します。

relay-smoke（認証済み、エンドツーエンド）

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

relay-smoke は、このホスト上のノードに対して実際のクライアントとして動作します。使い捨てのアイデンティティで短時間のセッションを 2 つ開き、このノードの鍵に固定した本番のハンドシェイクを完了します。エンドツーエンドで暗号化された 48 バイトのランダムなメッセージを 1 つ、認証済みのマルチホップリレー経路を通じて送信します。その後、そのリクエストに対する署名付きの終端受領証を検証し、このノードのメールボックスからメッセージを取り出して復号し、受信確認を行い、メールボックスが空であることとセッションが閉じられていることを確認します。

すべてのゲートを通過しない限り、開始を拒否します。

注意事項：

• ノード自体の上で root として実行する必要があります。/etc/aeronyx/server.toml とノードの鍵を読み取り、ループバックアドレスのみを受け付けます（--server、デフォルトは 127.0.0.1:51820。--health-url、デフォルトは http://127.0.0.1:8421/api/vpn/health）。
• --timeout-seconds は証明のウィンドウを設定します：5〜120 秒、デフォルトは 30 秒です。
• アクティブセッションが 0 である必要があるため、VPN ユーザーにサービスを提供しているノードは、先にドレインする必要があります。Nodeboard で Maintenance Mode をオンにし、セッションが 0 になるまで待ってください。
• 2 つのテストセッションは実際のプロトコルセッションのため、Nodeboard の Sessions に一時的に表示されることがあります。
• 合格時は "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 ノードから収集した署名付きディスクリプターから独自のオニオン経路を構築し、VPN セッションを使わずに、エントリーノードのパブリックピア API へ平文の HTTP を送信します。対象ノード上で匿名メールボックスの完全なライフサイクルを実行します：ticket_issue、lease_create、put、pull_one、ack、そして最後の pull_one です。取り出したバイトが一致すること、およびその後メールボックスが空であることを確認します。合格時は "status": "verified" とホップ数を報告します。

• --seed は複数回指定できます。--entry を指定しない場合、経路は 1 ホップになります。
• ノード ID は、ノードの 64 文字の 16 進公開鍵です。自分が運用するノードでは、./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 は CPU の約半分を使用するため、実行中のノードはサービスを継続できます。
4. 新しいバイナリで /etc/aeronyx/server.toml を検証します。設定ファイルが上書きされることはありません。
5. 実際に実行中のバイナリを /var/lib/aeronyx/releases/ にバックアップします。
6. ビルド後と、再起動の直前にもう一度、アクティブセッションを確認します。セッションがある場合、またはサービスの実行中にセッション数を読み取れない場合は、バージョンを切り替えずに停止します。
7. systemd ユニットを更新し、新しいバイナリに入れ替えて、サービスを再起動します。
8. ビルドしたばかりのコミットからローカルのヘルスが ok を報告するまで、最大 180 秒（2 秒間隔で 90 回のチェック）待ちます。再起動、サービスの状態、ヘルスチェックのいずれかが失敗した場合は、以前のバイナリとユニットを自動的に復元します。
9. 種類ごとに最新 10 件のバックアップを保持し、結果を /var/lib/aeronyx/upgrade-status.json に記録します。

ノードにアクティブなセッションがある場合、ビルドは実行されますが、その後アップグレードは Active sessions appeared during compilation. Enter maintenance mode, drain sessions, and run the upgrade again. で停止します。Nodeboard の Settings で Maintenance Mode をオンにし、アクティブセッションが 0 になるまで待ってから、同じコマンドを再実行してください。再ビルドではキャッシュが再利用されます。

今ステージングし、後で再起動する

./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 は選択したバイナリで設定を検証し、アクティブセッションがちょうど 0 でない限り実行を拒否します。PROMOTE BINARY の入力を求め、現在のバイナリをその隣にバックアップし、バイナリを入れ替えて再起動します。180 秒以内にサービスが正常にならない場合は、以前のバイナリを復元します。置き換えるのはバイナリのみで、systemd ユニットは置き換えません。

再起動後

次の順に確認してください。

1. systemctl is-active aeronyx-server が active を返す。ユニットは Type=notify のため、active はプロセスが準備完了を報告したことを意味します。起動には、systemd が断念するまで最大 300 秒かかる場合があります。
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 として報告します。（health --json の runtime.git_commit はチェックアウトのコミットです。）
5. 最初の数回のゴシップラウンドの後、discovery_readiness.peer_quorum.quorum_ready が true である。
6. リレーノードの場合：relay-probe --two-hop --json が ok を報告する。
7. Nodeboard で、ハートビートが最新であり、Rust Runtime に新しいバージョンが表示され、再起動が Alerts / Events の下に表示されている。作業が完了したら Maintenance Mode をオフにします。
8. journalctl -u aeronyx-server --since "15 min ago" に、繰り返し発生するエラーがない。

Nodeboard での表示

Nodeboard は、ノードの署名付きハートビートとセッションレポートを受信します。Nodeboard が自らホスト上でコマンドを実行することはありません。Nodeboard で選択した操作はキューに入れられ、ノードが次のハートビートでそれを実行します。

ノード詳細には Operator Runbook カードもあり、検出されたリポジトリパスに対応する health、status、logs、ステージングアップグレードのコマンドをコピーできます。

出力に含まれる内容

status、health、relay-probe、relay-smoke、mailbox-probe は集計値のみを出力します：件数、状態、時間、理由コードです。秘密鍵、登録コード、クライアントのパブリック IP、宛先、DNS の内容、ペイロード、メッセージの平文は出力しません。クライアントの鍵を含むセッション記録は、これらの出力ではなく Nodeboard で確認できます。Nodeboard オペレーターコンソールガイドを参照してください。サポートのために出力を共有する場合は、ホストのアドレスや認証情報ではなく、JSON とそのタイムスタンプを共有してください。

よくある質問

問題がありそうなときに最初に実行すべきコマンドは何ですか？

root として ./deploy/node/aeronyx-node.sh status --repo-dir "$PWD" を実行してください。サービスの状態、ローカルのヘルス、ディスカバリー、推奨される次のステップが表示され、ホストは変更されません。

ヘルスチェックが「config missing」や Git の警告で失敗するのはなぜですか？

root で実行していないか、誤ったリポジトリを指定している可能性があります。/etc/aeronyx と /var/lib/aeronyx は root 専用で、--repo-dir を指定しない場合、スクリプトはサービスの実行元のチェックアウトではなく /opt/aeronyx/AeroNyx を確認します。

relay-probe と relay-smoke の違いは何ですか？

relay-probe は合成された不透明なエンベロープを 1 つ送信し、リレー経路がトラフィックを受け入れることのみを示します。relay-smoke は実際のクライアントとして動作し、暗号化されたテストメッセージ 1 件について、署名付きの終端受領証と、メールボックスからの完全な取り出しおよび受信確認を検証します。

relay-smoke がアクティブセッション 0 を要求するのはなぜですか？

カウンターの変化を自身のテストセッションに帰属させるため、アイドル状態のノードでのみ実行されます。Nodeboard で Maintenance Mode をオンにし、アクティブセッションが 0 になるまで待ってから実行してください。

ユーザーを切断せずにアップグレードできますか？

ユーザーが接続中でも、--no-restart でアップグレードをビルドしてステージングできます。新しいバージョンへの切り替えには再起動が必要なため、Maintenance Mode でノードをドレインしてから upgrade --skip-pull を実行してください。

以前のバージョンに戻すにはどうすればよいですか？

失敗したアップグレードは自動的にロールバックされます。後でロールバックするには、/var/lib/aeronyx/releases/ 内のバックアップのいずれかを指定して promote-binary を使用します。アクティブセッションが 0 である必要があり、昇格したバイナリが正常でない場合は以前のバイナリを復元します。