Exploiter et vérifier un nœud AeroNyx

Ce guide d'exploitation couvre les commandes courantes d'un nœud AeroNyx enregistré : état, santé, journaux, preuves de relais et de boîte aux lettres, mises à niveau sûres, retour arrière et éléments à vérifier après un redémarrage. Chaque commande se trouve dans le dépôt du nœud (deploy/node/aeronyx-node.sh et le binaire aeronyx-server) et est présentée avec les options que le code accepte.

Si vous n'avez pas encore installé de nœud, commencez par Installer et enregistrer un nœud AeroNyx.

Avant de commencer

Exécutez tout depuis un shell root (sudo -i). Le répertoire de configuration /etc/aeronyx et le répertoire d'état /var/lib/aeronyx ont le mode 700 ; les commandes d'état, de santé, de validation et de relais ne peuvent donc pas les lire sous un autre utilisateur.

Placez-vous dans le dépôt à partir duquel le service s'exécute réellement, et passez-le avec --repo-dir à chaque commande du script. Sans --repo-dir, le script suppose /opt/aeronyx/AeroNyx.

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

Sur les nœuds installés avec la commande de Nodeboard, cela affiche /root/open/AeroNyx.

Aperçu des commandes

État

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

status affiche, dans l'ordre :

1. systemctl status aeronyx-server (20 dernières lignes)
2. un résumé de l'API locale de santé (http://127.0.0.1:8421/api/vpn/health) et de l'API d'état de l'opérateur (http://127.0.0.1:8421/api/operator/status)
3. la disponibilité locale de la découverte depuis http://127.0.0.1:8422/api/discovery/status : annonce ChatRelay et quorum de pairs
4. le dernier état du processus de mise à niveau depuis /var/lib/aeronyx/upgrade-status.json
5. une recommandation à l'opérateur : operator_status, operator_title, operator_detail et operator_next_step

La recommandation provient de la vérification de santé. Son état est l'un des suivants :

Santé

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

La vérification de santé lit des fichiers, systemd et les points de terminaison locaux ; elle ne modifie jamais l'hôte. Chaque vérification affiche [PASS], [WARN] ou [FAIL], puis une ligne [SUMMARY] pass=… warn=… fail=…, puis une ligne JSON. Utilisez --json-only pour n'afficher que le JSON. La commande se termine avec un code de sortie non nul si une vérification échoue.

Ce qu'elle vérifie : le dépôt, le Cargo.lock suivi et le binaire de version ; la validation de la configuration avec aeronyx-server validate ; les fichiers d'enregistrement et de clés ; l'unité systemd, la politique de redémarrage et le durcissement ; la mémoire, le disque et les ports 51820 et 8421 ; le transfert IP et le NAT ; le point de terminaison local de santé ; la découverte ; et les sauvegardes de versions.

Principaux champs JSON :

Vous pouvez lire directement les points de terminaison locaux bruts :

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

Journaux

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

Ces commandes encapsulent journalctl -u aeronyx-server -n <lines> --no-pager (160 lignes par défaut) et journalctl -u aeronyx-server -f. Utilisez directement journalctl pour des plages horaires, par exemple journalctl -u aeronyx-server --since "1 hour ago".

Preuves de relais et de boîte aux lettres

Ces commandes répondent à des questions différentes. Ne considérez pas la réussite d'une sonde synthétique comme une preuve de remise réelle.

relay-probe (synthétique)

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

Envoie une enveloppe BlindRelay opaque, aléatoire et synthétique de ce nœud vers un pair ChatRelay découvert et ne rapporte que les variations des compteurs. --two-hop l'envoie via un saut intermédiaire vers un nœud terminal. Le status du résultat vaut ok, attention, blocked ou error, et two_hop_readiness explique ce qui manque lorsqu'un chemin à deux sauts n'est pas possible. La commande lit le cache des pairs et la clé du nœud ; elle nécessite donc root. Il ne s'agit pas de trafic utilisateur et cela ne prouve pas la remise dans une boîte aux lettres. fleet-smoke exécute une vérification synthétique similaire sur plusieurs nœuds publics que vous indiquez avec --endpoints.

relay-smoke (authentifié, de bout en bout)

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

relay-smoke se comporte comme un véritable client face au nœud de cet hôte. Il ouvre deux sessions de courte durée avec des identités jetables et effectue la poignée de main de production, épinglée sur la clé de ce nœud. Il envoie un message aléatoire de 48 octets, chiffré de bout en bout, par le chemin de relais multisaut authentifié. Il vérifie ensuite le reçu terminal signé correspondant exactement à cette requête, récupère le message dans la boîte aux lettres de ce nœud, le déchiffre, en accuse réception, puis vérifie que la boîte aux lettres est vide et que les sessions sont fermées.

Il refuse de démarrer tant que toutes les conditions ne sont pas remplies :

Remarques :

• Il doit s'exécuter en tant que root sur le nœud lui-même. Il lit /etc/aeronyx/server.toml et la clé du nœud, et n'accepte que des adresses de bouclage (--server, par défaut 127.0.0.1:51820 ; --health-url, par défaut http://127.0.0.1:8421/api/vpn/health).
• --timeout-seconds définit la fenêtre de preuve : de 5 à 120 secondes, 30 par défaut.
• Zéro session active signifie qu'un nœud qui sert des utilisateurs VPN doit d'abord être vidé. Activez le Maintenance Mode dans Nodeboard et attendez que le nombre de sessions tombe à zéro.
• Les deux sessions de test sont de véritables sessions de protocole ; elles peuvent donc apparaître brièvement dans Sessions de Nodeboard.
• Une réussite comporte "status": "passed", terminal_receipt_observed, entry_mailbox_round_trip_verified, entry_mailbox_ack_verified et e2e_ciphertext_verified tous à true, et session_cleanup vaut explicit_authenticated_close. terminal_replica_cleanup vaut node_ttl_managed : l'accusé de réception sur le nœud d'entrée ne supprime pas la copie détenue par le nœud terminal, qui expire d'elle-même.
• Toute condition non remplie, toute erreur ou tout champ manquant constitue une preuve en échec, et non une réussite partielle.

mailbox-probe (côté client)

./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 se comporte comme une application : il utilise des clés jetables, construit sa propre route en oignon à partir de descripteurs signés collectés auprès des nœuds --seed, et envoie des requêtes HTTP simples à l'API entre pairs publique du nœud d'entrée, sans session VPN. Il exécute le cycle de vie complet de la boîte aux lettres anonyme sur le nœud cible : ticket_issue, lease_create, put, pull_one, ack et un dernier pull_one. Il vérifie que les octets récupérés correspondent et que la boîte aux lettres est vide ensuite. Une réussite indique "status": "verified" et le nombre de sauts.

• --seed peut être répété. Sans --entry, la route comporte un seul saut.
• Un identifiant de nœud est la clé publique hexadécimale de 64 caractères du nœud. Sur un nœud que vous exploitez, ./target/release/aeronyx-server pubkey -c /etc/aeronyx/server.toml l'affiche.
• La boîte aux lettres anonyme doit être activée sur la cible ([memchain.chat_relay.anonymous_mailbox] enabled = true) ; elle est désactivée par défaut.
• --work-bits (12 par défaut) doit être au moins égal au paramètre de travail des tickets de la cible. --timeout-seconds s'applique à chaque requête (20 par défaut).
• Il ne lit pas les fichiers locaux du nœud ; il peut donc s'exécuter depuis n'importe quelle machine disposant du binaire. Il prouve la garde d'un élément opaque, et non qu'un destinataire peut le déchiffrer.

Mettre à niveau en toute sécurité

Utilisez le processus de mise à niveau, et non git pull suivi de systemctl restart :

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

Ce qu'il fait :

1. Prend un verrou de déploiement et refuse de s'exécuter si des fichiers suivis de la copie de travail sont modifiés (--allow-dirty passe outre).
2. Récupère main (ou compile un commit exact dans une copie de travail isolée avec --commit <40-hex SHA>).
3. Compile avec la chaîne d'outils Rust épinglée par le dépôt. La priorité live (par défaut) et --build-jobs auto utilisent environ la moitié des processeurs afin que le nœud en cours d'exécution continue de servir.
4. Valide /etc/aeronyx/server.toml avec le nouveau binaire. Le fichier de configuration n'est jamais écrasé.
5. Sauvegarde le binaire réellement en cours d'exécution dans /var/lib/aeronyx/releases/.
6. Vérifie les sessions actives après la compilation, puis à nouveau juste avant le redémarrage. S'il y en a, ou si leur nombre ne peut pas être lu alors que le service tourne, il s'arrête sans changer de version.
7. Met à jour les unités systemd, met en place le nouveau binaire et redémarre le service.
8. Attend jusqu'à 180 secondes (90 vérifications, à 2 secondes d'intervalle) que la santé locale indique ok pour le commit qu'il vient de compiler. Si le redémarrage, l'état du service ou la vérification de santé échoue, il restaure automatiquement le binaire et les unités précédents.
9. Conserve les 10 sauvegardes les plus récentes de chaque type et enregistre le résultat dans /var/lib/aeronyx/upgrade-status.json.

Si le nœud a des sessions actives, la compilation s'exécute quand même, puis la mise à niveau s'arrête avec Active sessions appeared during compilation. Enter maintenance mode, drain sessions, and run the upgrade again. Activez le Maintenance Mode dans Settings de Nodeboard, attendez que le nombre de sessions actives tombe à zéro et relancez la même commande. La recompilation réutilise le cache.

Préparer maintenant, redémarrer plus tard

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

--no-restart compile, valide et sauvegarde, puis installe le nouveau binaire sur le disque sans redémarrer. status indique alors upgrade_staged. Le processus en cours d'exécution conserve l'ancienne version. Tout redémarrage ultérieur, y compris un redémarrage de la machine ou un redémarrage automatique après un plantage, lance le nouveau binaire.

Pour basculer pendant une fenêtre de maintenance, videz le nœud et relancez la mise à niveau sans récupération, afin qu'elle bascule exactement vers ce que vous avez préparé, avec la vérification des sessions, l'attente de santé et le retour arrière :

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

N'utilisez pas --force. Cette option redémarre même lorsque des sessions sont actives ou que le nombre de sessions est inconnu, et déconnecte les utilisateurs.

Revenir manuellement à une version antérieure

La mise à niveau revient automatiquement en arrière lorsque la nouvelle version ne parvient pas à démarrer ou à signaler un état sain. Pour revenir plus tard à une version antérieure, promouvez l'un des binaires sauvegardés :

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 valide la configuration avec le binaire choisi et refuse de s'exécuter tant que le nombre de sessions actives n'est pas exactement zéro. Il vous demande de taper PROMOTE BINARY, sauvegarde le binaire actuel à côté de celui-ci, remplace le binaire et redémarre. Si le service n'est pas en bonne santé dans les 180 secondes, il restaure le binaire précédent. Il ne remplace que le binaire, et non les unités systemd.

Après tout redémarrage

Vérifiez ces points dans l'ordre :

1. systemctl is-active aeronyx-server renvoie active. L'unité est de type Type=notify ; active signifie donc que le processus s'est déclaré prêt ; le démarrage peut prendre jusqu'à 300 secondes avant que systemd n'abandonne.
2. ./deploy/node/aeronyx-node.sh status --repo-dir "$PWD" affiche operator_status=ok, ou un avertissement que vous comprenez.
3. ./deploy/node/aeronyx-node.sh health --repo-dir "$PWD" --json se termine par "success":true et local_vpn_health.status vaut ok.
4. Le commit en cours d'exécution est celui que vous vouliez : curl -s http://127.0.0.1:8421/api/vpn/health l'indique sous runtime.git_commit. (Le runtime.git_commit de health --json est le commit de la copie de travail.)
5. discovery_readiness.peer_quorum.quorum_ready vaut true après les premiers cycles de diffusion (gossip).
6. Pour les nœuds de relais : relay-probe --two-hop --json indique ok.
7. Dans Nodeboard, le signal de présence est récent, Rust Runtime affiche la nouvelle version et le redémarrage apparaît sous Alerts / Events. Désactivez le Maintenance Mode lorsque vous avez terminé.
8. journalctl -u aeronyx-server --since "15 min ago" ne comporte aucune erreur répétée.

Comment cela apparaît dans Nodeboard

Nodeboard reçoit le signal de présence signé et les rapports de sessions du nœud. Il n'exécute pas de lui-même de commandes sur l'hôte ; les actions que vous y choisissez sont mises en file d'attente et le nœud les exécute lors de son signal de présence suivant.

Le détail du nœud comporte également une carte Operator Runbook avec des commandes health, status, logs et de mise à niveau préparée, prêtes à copier pour le chemin de dépôt détecté.

Contenu des sorties

status, health, relay-probe, relay-smoke et mailbox-probe n'affichent que des valeurs agrégées : nombres, états, durées et codes de motif. Ils n'affichent pas de clés privées, de codes d'enregistrement, d'adresses IP publiques de clients, de destinations, de contenus DNS, de charges utiles ni de texte de messages en clair. Les enregistrements de sessions comportant des clés de clients sont visibles dans Nodeboard, et non dans ces sorties ; consultez le Guide de la console d'opérateur Nodeboard. Lorsque vous partagez une sortie pour obtenir de l'aide, partagez le JSON et son horodatage, et non les adresses de l'hôte ou des identifiants.

Questions fréquentes

Quelle commande exécuter en premier lorsque quelque chose semble anormal ?

Exécutez ./deploy/node/aeronyx-node.sh status --repo-dir "$PWD" en tant que root. Elle affiche l'état du service, la santé locale, la découverte et la prochaine étape recommandée, et ne modifie pas l'hôte.

Pourquoi la vérification de santé échoue-t-elle avec « config missing » ou des avertissements Git ?

Vous n'êtes probablement pas root, ou vous pointez vers le mauvais dépôt. /etc/aeronyx et /var/lib/aeronyx sont réservés à root et, sans --repo-dir, le script vérifie /opt/aeronyx/AeroNyx au lieu de la copie de travail à partir de laquelle le service s'exécute.

Quelle est la différence entre relay-probe et relay-smoke ?

relay-probe envoie une enveloppe opaque synthétique et montre seulement qu'un chemin de relais accepte du trafic. relay-smoke se comporte comme un véritable client : il vérifie un reçu terminal signé ainsi qu'une récupération complète dans la boîte aux lettres et un accusé de réception pour un message de test chiffré.

Pourquoi relay-smoke indique-t-il qu'il nécessite zéro session active ?

Il attribue les variations des compteurs à ses propres sessions de test ; il ne s'exécute donc que sur un nœud inactif. Activez le Maintenance Mode dans Nodeboard, attendez que le nombre de sessions actives tombe à zéro, puis exécutez-le.

Puis-je mettre à niveau sans déconnecter les utilisateurs ?

Vous pouvez compiler et préparer une mise à niveau avec --no-restart pendant que des utilisateurs sont connectés. Le passage à la nouvelle version nécessite un redémarrage ; videz donc le nœud avec le Maintenance Mode, puis exécutez upgrade --skip-pull.

Comment revenir à la version précédente ?

Une mise à niveau en échec revient automatiquement en arrière. Pour revenir en arrière plus tard, utilisez promote-binary avec l'une des sauvegardes de /var/lib/aeronyx/releases/ ; cette commande exige zéro session active et restaure le binaire précédent si celui qui a été promu n'est pas en bonne santé.