AeroNyx 分散型プライバシーノードのインストールと登録

これは新しい AeroNyx ノード向けのサポート済み本番フローです。リポジトリ内の唯一の運用エントリーを使い、Nodeboard のワンタイムコードでノード ID を結び、systemd サービスを作成します。完了と判定する前に、ローカルデータプレーン、backend heartbeat、署名済み discovery、公開プールを検証します。プロセスが active であるだけではネットワーク参加の証明になりません。

ノード運用コンソール: app.aeronyx.network

オープンソース: github.com/AeroNyxNetwork/AeroNyx

開始前の確認

安定したパブリックアドレスを持つ専用 Linux ホストを使用します。クラウドとホストの firewall、上流ネットワークで必要なポートを確認し、管理 API を公開インターネットへ直接出さないでください。

1. ワンタイム登録コードを作成する

登録するのはノード ID、能力、運用上の所有関係であり、ユーザー内容ではありません。コードは短時間だけ有効で、一度しか使えません。

1. Nodeboard にサインインします。
2. Registration Codes で対象オペレーター用の短期コードを作成します。
3. ノード名と ISO 3166-1 alpha-2 の地域コードを決めます。
4. コードを ticket、画面キャプチャ、shell history、公開 AI 会話へ残しません。

2. 公式運用スクリプトを取得する

aeronyx-node.sh は Linux のグローバルコマンドではなく、公式 AeroNyx Rust リポジトリに含まれます。新規ホストでは main を取得し、リポジトリルートから実行します。

sudo install -d -m 0755 /opt/aeronyx
sudo git clone --branch main --single-branch \
  https://github.com/AeroNyxNetwork/AeroNyx.git \
  /opt/aeronyx/AeroNyx
cd /opt/aeronyx/AeroNyx
git rev-parse HEAD

既存ディレクトリへ clone を重ねないでください。tracked worktree が clean の場合だけ fast-forward します。ローカル変更がある本番ノードでは commit-pinned isolated upgrade を使います。

cd /opt/aeronyx/AeroNyx
git fetch origin main
git checkout main
git pull --ff-only origin main
./deploy/node/aeronyx-node.sh plan --repo-dir "$PWD" --branch main

3. 計画を確認して quickstart を実行する

例の名前と国コードを実環境に置き換えます。--public-vpn は明示的 opt-in です。省略したノードも登録・管理できますが、公開プライバシーネットワークの pool には入りません。対話モードはコード入力を隠し、解決済み計画を表示して確認を求めます。

cd /opt/aeronyx/AeroNyx
sudo ./deploy/node/aeronyx-node.sh quickstart \
  --node-name "Berlin1" \
  --region "DE" \
  --public-vpn

自動化では bounded stdin の 1 行で秘密を渡し、計画承認後だけ --yes を使います。匿名 pipe により子プロセス argv へコードを載せません。

read -r -s -p 'Nodeboard registration code: ' AERONYX_NODE_CODE; echo
printf '%s\n' "${AERONYX_NODE_CODE}" | \
  sudo ./deploy/node/aeronyx-node.sh quickstart \
    --registration-code-stdin \
    --node-name "Berlin1" \
    --region "DE" \
    --public-vpn \
    --yes
unset AERONYX_NODE_CODE

install と upgrade はホスト単位の deployment lock を共有し、二重実行を防ぎます。--allow-dirty と --skip-admission-check は通常経路ではなく、明示した緊急保守または隔離復旧にだけ使います。

4. ネットワーク参加を証明する

既定の admission gate は最大 120 秒待ち、必要な証拠が揃った場合だけ completed になります。導入後は次の read-only コマンドで再検証できます。

cd /opt/aeronyx/AeroNyx
./deploy/node/aeronyx-node.sh status
./deploy/node/aeronyx-node.sh health --json
systemctl is-active aeronyx-server

• /api/vpn/health が ok で、listener、TUN、forwarding、NAT、DNS、egress が利用可能。
• 登録ノードに新しい backend policy timestamp があり、署名 management heartbeat の往復が完了。
• discovery status と snapshot に検証済み署名 descriptor があり、gossip round が完了。
• 公開ノードは正確な backend UUID、visibility=public、VPN capability、online 状態で public pool に存在。
• Nodeboard の名前、地域、visibility、capacity、heartbeat がノードと一致。

private ノードは意図的に public pool を要件としませんが、local health、登録 heartbeat、署名 discovery は必要です。初回起動が遅い場合は --admission-timeout 240 で待機時間を延ばし、検査自体を外さないでください。

公開ノードとブラインドリレーの選択

公開プライバシー出口、ChatRelay、no-exit OnionMiddle は別々の選択です。8422 peer API の public endpoint が到達可能で、config validation と安全な restart 条件を満たした後にだけブラインドリレー能力を広告します。

cd /opt/aeronyx/AeroNyx
./deploy/node/aeronyx-node.sh chat-relay --enable-chat-relay --dry-run
sudo ./deploy/node/aeronyx-node.sh chat-relay --enable-chat-relay --restart
./deploy/node/aeronyx-node.sh onion-middle --enable-onion-middle --dry-run
sudo ./deploy/node/aeronyx-node.sh onion-middle --enable-onion-middle --restart
./deploy/node/aeronyx-node.sh relay-probe --two-hop --json

helper は server.toml をバックアップし、対象フィールドだけ変更して検証します。active sessions があれば restart を拒否します。新規ノードは fresh reachability と path-proof evidence を蓄積するため、設定済み capability は即時 route eligibility を意味しません。two-hop probe には互いに異なる 3 つの routeable node が必要で、不足時は blocked が正しい結果です。

日常運用と安全なアップグレード

候補を先に build・validate して restart せず stage し、承認済み maintenance window で正式に更新します。本番で手動 git pull 後に binary を直接置換しないでください。

cd /opt/aeronyx/AeroNyx
sudo ./deploy/node/aeronyx-node.sh upgrade \
  --build-priority live \
  --build-jobs auto \
  --no-restart

sudo ./deploy/node/aeronyx-node.sh upgrade \
  --build-priority live \
  --build-jobs auto

workflow は build 後、promotion 前、restart 直前に active sessions を再確認し、取得不能なら fail closed します。config と systemd unit を検証し、旧 binary/unit を保存して atomic promotion を行い、再起動後の health が失敗すれば rollback します。upgrade-status.json には運用メタデータだけを記録します。

AI 支援インストールの契約

Codex、Claude Code などの terminal agent は実行できますが、無制限の root として推測せず、制約されたノード運用ツールとして動作しなければなりません。

1. 公式 repository、branch、checkout、current commit を確認する。
2. 変更前に plan を実行して表示する。
3. 登録コードは hidden prompt または bounded stdin だけで渡す。
4. 既存 ID と config を保持し、/etc/aeronyx の永続ファイルを上書きしない。
5. restart 前に active sessions を確認し、信頼できる値がなければ停止する。
6. local health、backend heartbeat、public reachability、署名 discovery、Nodeboard を検証する。
7. warning、blocked、rollback を正直に報告し、systemd active だけで成功と言わない。

プライバシー境界

ノードと Nodeboard が扱えるのは運用に必要な集約証拠だけです。リレーは内容を読めず、運用 telemetry をユーザー履歴へ変換してはいけません。

許可される集約運用データ

• CPU、memory、disk、fd、conntrack、packet drops
• IP pool capacity、max connections、pps、bps、active session count
• heartbeat、version、capability、peer quorum、relay proof status

収集・出力してはいけないデータ

• client public IP activity、destination、DNS、domain、URL、browsing history
• packet/message plaintext、chat peer、social graph、MemChain plaintext
• private key、registration code、voucher secret、wallet-level traffic、識別可能な credential

関連資料

• 分散型ノードの運用とヘルスチェック
• Nodeboard オペレーターコンソールガイド
• ノード discovery と検証済み暗号化 relay 基盤