Ejecutar y comprobar un nodo de AeroNyx

Este manual de operaciones cubre los comandos de uso diario para un nodo de AeroNyx registrado: estado, comprobación de salud, registros, pruebas de relé y de buzón, actualizaciones seguras, reversión y qué comprobar después de un reinicio. Todos los comandos están en el repositorio del nodo (deploy/node/aeronyx-node.sh y el binario aeronyx-server) y se muestran con las opciones que acepta el código.

Si todavía no ha instalado un nodo, empiece por Instalar y registrar un nodo de AeroNyx.

Antes de empezar

Ejecute todo desde un shell de root (sudo -i). El directorio de configuración /etc/aeronyx y el directorio de estado /var/lib/aeronyx tienen el modo 700, por lo que los comandos de estado, comprobación de salud, validación y relé no pueden leerlos como otro usuario.

Cámbiese al repositorio desde el que se ejecuta realmente el servicio y páselo con --repo-dir en cada comando del script. Sin --repo-dir, el script supone /opt/aeronyx/AeroNyx.

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

En los nodos instalados con el comando de Nodeboard, esto muestra /root/open/AeroNyx.

Comandos de un vistazo

Estado

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

status muestra, en este orden:

1. systemctl status aeronyx-server (últimas 20 líneas)
2. un resumen de la API local de salud (http://127.0.0.1:8421/api/vpn/health) y de la API de estado del operador (http://127.0.0.1:8421/api/operator/status)
3. la preparación del descubrimiento local desde http://127.0.0.1:8422/api/discovery/status: anuncio de ChatRelay y quórum de pares
4. el estado del último flujo de actualización desde /var/lib/aeronyx/upgrade-status.json
5. una recomendación para el operador: operator_status, operator_title, operator_detail y operator_next_step

La recomendación procede de la comprobación de salud. Su estado es uno de los siguientes:

Comprobación de salud

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

La comprobación de salud lee archivos, systemd y los endpoints locales; nunca modifica el host. Cada comprobación muestra [PASS], [WARN] o [FAIL], después una línea [SUMMARY] pass=… warn=… fail=… y luego una línea de JSON. Use --json-only para mostrar solo el JSON. El comando termina con un estado distinto de cero si alguna comprobación falla.

Qué comprueba: el repositorio, el Cargo.lock versionado y el binario de la versión; la validación de la configuración con aeronyx-server validate; los archivos de registro y de claves; la unidad systemd, la política de reinicio y el endurecimiento; la memoria, el disco y los puertos 51820 y 8421; el reenvío IP y la NAT; el endpoint local de salud; el descubrimiento; y las copias de seguridad de versiones.

Campos JSON principales:

Puede leer directamente los endpoints locales sin procesar:

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

Registros

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

Estos comandos envuelven journalctl -u aeronyx-server -n <lines> --no-pager (160 líneas de forma predeterminada) y journalctl -u aeronyx-server -f. Use journalctl directamente para intervalos de tiempo, por ejemplo journalctl -u aeronyx-server --since "1 hour ago".

Pruebas de relé y de buzón

Estos comandos responden a preguntas distintas. No considere que una sonda sintética superada demuestra una entrega real.

relay-probe (sintética)

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

Envía un sobre BlindRelay sintético, aleatorio y opaco desde este nodo a un par ChatRelay descubierto e informa solo de los cambios en los contadores. --two-hop lo envía a través de un salto intermedio hasta un nodo terminal. El status del resultado es ok, attention, blocked o error, y two_hop_readiness explica qué falta cuando no es posible una ruta de dos saltos. Lee la caché de pares y la clave del nodo, por lo que necesita root. No es tráfico de usuarios y no demuestra la entrega en el buzón. fleet-smoke ejecuta una comprobación sintética similar en varios nodos públicos que usted indica con --endpoints.

relay-smoke (autenticada, de extremo a extremo)

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

relay-smoke actúa como un cliente real contra el nodo de este host. Abre dos sesiones de corta duración con identidades desechables y completa el protocolo de enlace de producción, fijado a la clave de este nodo. Envía un mensaje aleatorio de 48 bytes, cifrado de extremo a extremo, por la ruta de relé multisalto autenticada. Después verifica el acuse terminal firmado para esa solicitud concreta, recupera el mensaje del buzón de este nodo, lo descifra, lo confirma y comprueba que el buzón queda vacío y que las sesiones están cerradas.

Se niega a empezar salvo que se superen todos los controles:

Notas:

• Debe ejecutarse como root en el propio nodo. Lee /etc/aeronyx/server.toml y la clave del nodo, y solo acepta direcciones de bucle local (--server, valor predeterminado 127.0.0.1:51820; --health-url, valor predeterminado http://127.0.0.1:8421/api/vpn/health).
• --timeout-seconds establece la ventana de la prueba: de 5 a 120 segundos, 30 de forma predeterminada.
• Cero sesiones activas significa que un nodo que da servicio a usuarios de la VPN debe vaciarse primero. Active el modo de mantenimiento en Nodeboard y espere a que las sesiones lleguen a cero.
• Las dos sesiones de prueba son sesiones reales del protocolo, por lo que pueden aparecer brevemente en Sessions de Nodeboard.
• Una prueba superada tiene "status": "passed", con terminal_receipt_observed, entry_mailbox_round_trip_verified, entry_mailbox_ack_verified y e2e_ciphertext_verified todos en true, y session_cleanup es explicit_authenticated_close. terminal_replica_cleanup es node_ttl_managed: confirmar en el nodo de entrada no elimina la copia que conserva el nodo terminal, que caduca por sí sola.
• Cualquier control fallido, error o campo ausente es una prueba fallida, no un éxito parcial.

mailbox-probe (desde el lado del cliente)

./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 comporta como una aplicación: usa claves desechables, construye su propia ruta cebolla a partir de los descriptores firmados recopilados de los nodos --seed y envía HTTP sin cifrar a la API entre pares pública del nodo de entrada, sin sesión VPN. Ejecuta el ciclo de vida completo del buzón anónimo en el nodo de destino: ticket_issue, lease_create, put, pull_one, ack y un pull_one final. Comprueba que los bytes recuperados coinciden y que después el buzón queda vacío. Una prueba superada informa "status": "verified" y el número de saltos.

• --seed se puede repetir. Sin --entry, la ruta tiene un salto.
• Un ID de nodo es la clave pública del nodo en 64 caracteres hexadecimales. En un nodo que usted opera, ./target/release/aeronyx-server pubkey -c /etc/aeronyx/server.toml lo muestra.
• El destino debe tener activado el buzón anónimo ([memchain.chat_relay.anonymous_mailbox] enabled = true); está desactivado de forma predeterminada.
• --work-bits (12 de forma predeterminada) debe ser al menos el ajuste de trabajo de tickets del destino. --timeout-seconds se aplica a cada solicitud (20 de forma predeterminada).
• No lee archivos locales del nodo, por lo que puede ejecutarse desde cualquier máquina que tenga el binario. Demuestra la custodia de un elemento opaco, no que un destinatario pueda descifrarlo.

Actualizar de forma segura

Use el flujo de actualización, no git pull seguido de systemctl restart:

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

Qué hace:

1. Adquiere un bloqueo de despliegue y se niega a ejecutarse si hay archivos versionados modificados en el checkout (--allow-dirty lo anula).
2. Obtiene main (o compila un commit exacto en un checkout aislado con --commit <40-hex SHA>).
3. Compila con la cadena de herramientas de Rust fijada por el repositorio. La prioridad live (la predeterminada) y --build-jobs auto usan aproximadamente la mitad de las CPU para que el nodo en ejecución siga dando servicio.
4. Valida /etc/aeronyx/server.toml con el nuevo binario. El archivo de configuración nunca se sobrescribe.
5. Hace una copia de seguridad del binario que realmente está en ejecución en /var/lib/aeronyx/releases/.
6. Comprueba las sesiones activas después de la compilación y de nuevo justo antes del reinicio. Si hay alguna, o si no se puede leer el recuento mientras el servicio está en ejecución, se detiene sin cambiar de versión.
7. Actualiza las unidades systemd, coloca el nuevo binario y reinicia el servicio.
8. Espera hasta 180 segundos (90 comprobaciones, con 2 segundos de separación) a que la salud local informe ok desde el commit que acaba de compilar. Si fallan el reinicio, el estado del servicio o la comprobación de salud, restaura automáticamente el binario y las unidades anteriores.
9. Conserva las 10 copias de seguridad más recientes de cada tipo y registra el resultado en /var/lib/aeronyx/upgrade-status.json.

Si el nodo tiene sesiones activas, la compilación se ejecuta igualmente y después la actualización se detiene con Active sessions appeared during compilation. Enter maintenance mode, drain sessions, and run the upgrade again. Active Maintenance Mode en Settings de Nodeboard, espere a que las sesiones activas lleguen a cero y vuelva a ejecutar el mismo comando. La recompilación reutiliza la caché.

Preparar ahora, reiniciar más tarde

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

--no-restart compila, valida y hace la copia de seguridad, y después instala el nuevo binario en disco sin reiniciar. A partir de entonces, status informa upgrade_staged. El proceso en ejecución mantiene la versión anterior. Cualquier reinicio posterior, incluido un reinicio del sistema o un reinicio automático tras un fallo, arranca el nuevo binario.

Para hacer el cambio en una ventana de mantenimiento, vacíe el nodo y vuelva a ejecutar la actualización sin obtener cambios, de modo que cambie exactamente a lo que preparó, con la comprobación de sesiones, la espera de salud y la reversión:

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

No use --force. Reinicia aunque haya sesiones activas o se desconozca el número de sesiones, y desconecta a los usuarios.

Revertir manualmente

La actualización se revierte automáticamente cuando la nueva versión no consigue arrancar o informar de un buen estado. Para volver más tarde a una versión anterior, promueva uno de los binarios guardados:

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 valida la configuración con el binario elegido y se niega a ejecutarse salvo que las sesiones activas sean exactamente cero. Le pide que escriba PROMOTE BINARY, hace una copia de seguridad del binario actual junto a él, sustituye el binario y reinicia. Si el servicio no está en buen estado en 180 segundos, restaura el binario anterior. Solo sustituye el binario, no las unidades systemd.

Después de cualquier reinicio

Compruebe lo siguiente en orden:

1. systemctl is-active aeronyx-server devuelve active. La unidad es Type=notify, por lo que active significa que el proceso informó de que está listo; el arranque puede tardar hasta 300 segundos antes de que systemd desista.
2. ./deploy/node/aeronyx-node.sh status --repo-dir "$PWD" muestra operator_status=ok, o una advertencia que usted entiende.
3. ./deploy/node/aeronyx-node.sh health --repo-dir "$PWD" --json termina con "success":true y local_vpn_health.status es ok.
4. El commit en ejecución es el que pretendía: curl -s http://127.0.0.1:8421/api/vpn/health lo indica como runtime.git_commit. (El runtime.git_commit de health --json es el commit del checkout).
5. discovery_readiness.peer_quorum.quorum_ready es true después de las primeras rondas de difusión.
6. En los nodos de relé: relay-probe --two-hop --json informa ok.
7. En Nodeboard, el latido es reciente, Rust Runtime muestra la nueva versión y el reinicio aparece en Alerts / Events. Desactive el modo de mantenimiento cuando haya terminado.
8. journalctl -u aeronyx-server --since "15 min ago" no tiene errores repetidos.

Cómo aparece esto en Nodeboard

Nodeboard recibe el latido firmado y los informes de sesión del nodo. No ejecuta comandos en el host por sí mismo; las acciones que usted elige allí se ponen en cola y el nodo las ejecuta en su siguiente latido.

El detalle del nodo también tiene una tarjeta Operator Runbook con comandos copiables de health, status, logs y de actualización preparada para la ruta del repositorio detectada.

Qué contienen las salidas

status, health, relay-probe, relay-smoke y mailbox-probe muestran solo valores agregados: recuentos, estados, tiempos y códigos de motivo. No muestran claves privadas, códigos de registro, IP públicas de clientes, destinos, contenido DNS, cargas útiles ni texto sin cifrar de mensajes. Los registros de sesión con claves de cliente son visibles en Nodeboard, no en estas salidas; consulte la Guía de la consola de operador Nodeboard. Cuando comparta una salida para obtener soporte, comparta el JSON y su marca de tiempo, no direcciones del host ni credenciales.

Preguntas frecuentes

¿Qué comando debo ejecutar primero cuando algo parece ir mal?

Ejecute ./deploy/node/aeronyx-node.sh status --repo-dir "$PWD" como root. Muestra el estado del servicio, la salud local, el descubrimiento y el siguiente paso recomendado, y no modifica el host.

¿Por qué la comprobación de salud falla con "config missing" o advertencias de Git?

Probablemente no es root o está apuntando al repositorio equivocado. /etc/aeronyx y /var/lib/aeronyx son solo para root y, sin --repo-dir, el script comprueba /opt/aeronyx/AeroNyx en lugar del checkout desde el que se ejecuta el servicio.

¿Cuál es la diferencia entre relay-probe y relay-smoke?

relay-probe envía un sobre opaco sintético y solo demuestra que una ruta de relé acepta tráfico. relay-smoke actúa como un cliente real: verifica un acuse terminal firmado y una recuperación y confirmación completas del buzón para un mensaje de prueba cifrado.

¿Por qué relay-smoke dice que necesita cero sesiones activas?

Atribuye los cambios en los contadores a sus propias sesiones de prueba, por lo que solo se ejecuta en un nodo inactivo. Active el modo de mantenimiento en Nodeboard, espere a que las sesiones activas lleguen a cero y después ejecútelo.

¿Puedo actualizar sin desconectar a los usuarios?

Puede compilar y preparar una actualización con --no-restart mientras hay usuarios conectados. Cambiar a la nueva versión requiere un reinicio, así que vacíe el nodo con el modo de mantenimiento y después ejecute upgrade --skip-pull.

¿Cómo vuelvo a la versión anterior?

Una actualización fallida se revierte automáticamente. Para revertir más tarde, use promote-binary con una de las copias de seguridad de /var/lib/aeronyx/releases/; requiere cero sesiones activas y restaura el binario anterior si el promovido no está en buen estado.