Installer et enregistrer un nœud de confidentialité décentralisé AeroNyx

Voici le parcours de production pris en charge pour un nouveau nœud. Il utilise l’unique point d’entrée opérateur du dépôt, lie l’identité via un code Nodeboard éphémère, installe systemd et vérifie le plan de données local, le heartbeat backend, la découverte signée et le pool public avant d’annoncer la réussite. Un processus active ne prouve pas à lui seul l’admission au réseau de confidentialité AeroNyx.

Console opérateur: app.aeronyx.network

Code source ouvert: github.com/AeroNyxNetwork/AeroNyx

Avant de commencer

Utilisez un hôte Linux dédié avec adresse publique stable. Vérifiez les pare-feu cloud et hôte ainsi que le réseau du fournisseur. N’exposez pas directement l’API de gestion à Internet.

1. Créer un code d’enregistrement à usage unique

L’enregistrement concerne l’identité, les capacités et l’opérateur du nœud, jamais le contenu utilisateur. Le code expire vite et n’est consommable qu’une fois.

1. Connectez-vous à Nodeboard.
2. Ouvrez Registration Codes et créez un code court pour le compte opérateur visé.
3. Choisissez le nom du nœud et la région ISO 3166-1 alpha-2.
4. Ne placez jamais le code dans tickets, captures, historique shell ou conversation IA publique.

2. Obtenir le script opérateur officiel

aeronyx-node.sh n’est pas une commande Linux globale; il appartient au dépôt Rust officiel AeroNyx. Sur un nouvel hôte, récupérez main et exécutez-le depuis la racine du dépôt.

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

Ne clonez pas par-dessus un répertoire existant. N’effectuez un fast-forward que si le tracked worktree est propre; utilisez une mise à niveau isolée épinglée à un commit si le nœud de production contient des modifications locales.

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. Vérifier le plan et exécuter quickstart

Remplacez le nom et le pays d’exemple. --public-vpn est un opt-in explicite : sans lui, le nœud reste enregistré et administrable mais n’entre pas dans le pool public. Le mode interactif masque le code, montre le plan résolu et demande confirmation.

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

Une automatisation transmet le secret sur une seule ligne bounded stdin et n’utilise --yes qu’après validation du plan. Le pipe anonyme évite de placer le code dans argv des processus enfants.

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

Installation et upgrade partagent un deployment lock hôte. --allow-dirty et --skip-admission-check ne sont pas des raccourcis normaux; réservez-les à une maintenance d’urgence ou reprise isolée explicitement approuvée.

4. Prouver l’admission dans le réseau

L’admission gate attend jusqu’à 120 secondes et ne marque completed que lorsque les preuves applicables sont réunies. Ces commandes en lecture seule permettent de revérifier ensuite.

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 vaut ok : listener, TUN, forwarding, NAT, DNS et egress fonctionnent.
• Un policy timestamp backend récent prouve le round trip du heartbeat de gestion signé.
• Discovery status et snapshot contiennent un descriptor signé validé et un tour gossip terminé.
• Un nœud public figure avec UUID backend exact, visibility=public, capacité VPN et état online.
• Nom, région, visibilité, capacité et heartbeat affichés par Nodeboard correspondent au nœud.

Un nœud privé n’est volontairement pas requis dans le pool public, mais doit valider santé locale, heartbeat enregistré et discovery signé. Un premier démarrage lent peut utiliser --admission-timeout 240 sans supprimer les contrôles.

Rôles publics et relais aveugles optionnels

La sortie publique de confidentialité, ChatRelay et OnionMiddle sans sortie sont trois choix distincts. N’annoncez le relais aveugle qu’après accessibilité de l’endpoint public 8422, validation de la configuration et conditions de redémarrage sûres.

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

Le helper sauvegarde server.toml, ne change que le champ voulu, valide puis refuse de redémarrer en présence d’active sessions. Un nouveau nœud doit accumuler reachability fraîche et path proofs; une capacité configurée n’est pas immédiatement routeable. Le test two-hop exige trois nœuds distincts et doit renvoyer blocked s’ils manquent.

Exploitation courante et mises à niveau sûres

Construisez et validez d’abord le candidat sans redémarrage, puis déployez pendant une fenêtre approuvée. Évitez tout git pull manuel suivi d’un remplacement direct du binaire de production.

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

Le flux recompte les active sessions après compilation, avant promotion et juste avant restart; un compteur indisponible provoque un fail closed. Il valide config et systemd, conserve ancien binaire et units, promeut atomiquement et rollback en cas d’échec santé. upgrade-status.json ne contient que des métadonnées opérateur.

Contrat d’installation assistée par IA

Codex, Claude Code ou un autre agent terminal peut exécuter ce parcours, mais doit agir comme outil opérateur contraint et non improviser parce qu’il possède root.

1. Confirmer dépôt officiel, branch, checkout et commit courant.
2. Exécuter et afficher plan avant tout changement.
3. Transmettre le code uniquement par prompt masqué ou bounded stdin.
4. Préserver identité et config; ne pas écraser les fichiers persistants de /etc/aeronyx.
5. Contrôler active sessions avant restart et s’arrêter si la valeur n’est pas fiable.
6. Valider santé locale, heartbeat backend, accessibilité publique, discovery signé et Nodeboard.
7. Rapporter warning, blocked et rollback; ne pas confondre systemd active et succès.

Frontière de confidentialité

Le nœud et Nodeboard ne traitent que les preuves opérationnelles agrégées nécessaires. Le relay reste aveugle et la télémétrie ne devient jamais un historique utilisateur.

Données agrégées autorisées

• CPU, mémoire, disque, fd, conntrack et packet drops
• capacité pool IP, max connections, pps, bps et nombre de sessions actives
• heartbeat, version, capacités, peer quorum et état relay proof

Données interdites

• activité IP publique client, destinations, DNS, domaines, URL ou historique
• plaintext paquets/messages, interlocuteurs, graphe social ou plaintext MemChain
• clés privées, code d’enregistrement, voucher secrets, trafic wallet ou credential identifiable

Références associées

• Exploitation et santé des nœuds décentralisés
• Guide de la console Nodeboard
• Découverte des nœuds et relais chiffré vérifié