Instalar y registrar un nodo descentralizado de privacidad AeroNyx

Este es el flujo de producción compatible para un nodo nuevo. Usa el único punto de entrada operativo del repositorio, vincula la identidad del nodo mediante un código efímero de Nodeboard, instala systemd y verifica el plano de datos local, el heartbeat del backend, el descubrimiento firmado y el pool público antes de declarar éxito. Un proceso active no demuestra por sí solo que el nodo se haya unido a la red de privacidad AeroNyx.

Consola de operación: app.aeronyx.network

Código abierto: github.com/AeroNyxNetwork/AeroNyx

Antes de comenzar

Usa un host Linux dedicado con dirección pública estable. Comprueba firewall cloud, firewall del host y red del proveedor. La API de administración no debe exponerse directamente a Internet.

1. Crear un código de registro de un solo uso

Se registran identidad, capacidades y relación operativa del nodo, no contenido de usuarios. El código dura poco y solo puede consumirse una vez.

1. Inicia sesión en Nodeboard.
2. Abre Registration Codes y crea un código breve para la cuenta operadora prevista.
3. Define nombre del nodo y región ISO 3166-1 alpha-2.
4. No pongas el código en tickets, capturas, historial del shell ni conversaciones públicas con IA.

2. Obtener el script oficial de operación

aeronyx-node.sh no es un comando global de Linux: forma parte del repositorio Rust oficial de AeroNyx. En un host nuevo, obtiene main y ejecútalo desde la raíz del repositorio.

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

No clones encima de un directorio existente. Haz fast-forward solo si el tracked worktree está limpio; para un nodo de producción con cambios locales usa una actualización aislada fijada por commit.

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. Revisar el plan y ejecutar quickstart

Sustituye el nombre y país del ejemplo. --public-vpn es opt-in explícito: sin él el nodo se registra y administra, pero no entra en el pool público de la red de privacidad. El modo interactivo oculta el código, muestra el plan resuelto y pide confirmación.

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

La automatización debe enviar el secreto por una sola línea bounded stdin y usar --yes únicamente tras aprobar el plan. El pipe anónimo evita incluirlo en argv de procesos hijos.

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

Instalación y actualización comparten un deployment lock del host. No uses --allow-dirty ni --skip-admission-check como atajos normales; quedan para mantenimiento de emergencia o recuperación aislada y explícita.

4. Demostrar la admisión en la red

El admission gate predeterminado espera hasta 120 segundos y solo marca completed cuando reúne las pruebas aplicables. Después, estos comandos de solo lectura permiten repetir la verificación.

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 devuelve ok: listener, TUN, forwarding, NAT, DNS y egress están operativos.
• El nodo registrado tiene un policy timestamp reciente del backend: terminó el heartbeat de gestión firmado.
• Discovery status y snapshot contienen un descriptor firmado validado y una ronda gossip completada.
• Un nodo público aparece con UUID exacto, visibility=public, capacidad VPN y estado online en el pool público.
• Nombre, región, visibilidad, capacidad y heartbeat de Nodeboard coinciden con el nodo.

Un nodo privado no debe aparecer en el pool público, pero sí aprobar salud local, heartbeat registrado y discovery firmado. Para un primer arranque lento amplía a --admission-timeout 240; no elimines las pruebas.

Roles públicos y de relay ciego opcionales

La salida pública de privacidad, ChatRelay y OnionMiddle sin salida son decisiones distintas. Anuncia relay ciego solo cuando el endpoint público 8422 sea alcanzable, la configuración valide y el reinicio sea seguro.

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

El helper respalda server.toml, cambia únicamente el campo previsto, valida y rechaza reiniciar con active sessions. Un nodo nuevo necesita evidencia fresca de alcance y path proof: configurar una capacidad no lo vuelve routeable de inmediato. El two-hop probe requiere tres nodos distintos y routeable; con menos debe responder blocked.

Operación diaria y actualizaciones seguras

Construye y valida primero el candidato sin reiniciar, y actualiza en una ventana de mantenimiento aprobada. No hagas git pull manual seguido de reemplazo directo del binario de producción.

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

El flujo vuelve a comprobar active sessions tras compilar, antes de promotion y justo antes de reiniciar; si no puede obtener el contador, falla cerrado. Valida config y systemd, conserva binario y units anteriores, promociona de forma atómica y revierte si falla la salud posterior. upgrade-status.json contiene solo metadatos operativos.

Contrato de instalación asistida por IA

Codex, Claude Code u otro agente terminal puede ejecutar el flujo, pero debe actuar como herramienta operativa restringida, no improvisar por disponer de root.

1. Confirmar repositorio oficial, branch, checkout y commit actual.
2. Ejecutar y mostrar plan antes de cambiar el host.
3. Pasar el código solo por prompt oculto o bounded stdin.
4. Conservar identidad y configuración; no sobrescribir archivos persistentes de /etc/aeronyx.
5. Comprobar active sessions antes de reiniciar y detenerse si el dato no es fiable.
6. Validar salud local, heartbeat backend, alcance público, discovery firmado y Nodeboard.
7. Informar warning, blocked y rollback; no confundir systemd active con éxito.

Límite de privacidad

El nodo y Nodeboard solo pueden tratar evidencia operativa agregada. El relay debe permanecer ciego y la telemetría no puede convertirse en historial del usuario.

Datos operativos agregados permitidos

• CPU, memoria, disco, fd, conntrack y packet drops
• capacidad del pool IP, max connections, pps, bps y número de sesiones activas
• heartbeat, versión, capacidades, peer quorum y estado relay proof

Datos que nunca se recopilan ni muestran

• actividad de IP pública del cliente, destinos, DNS, dominios, URL o historial
• plaintext de paquetes/mensajes, interlocutores, grafo social o plaintext de MemChain
• claves privadas, códigos de registro, voucher secrets, tráfico wallet o credenciales identificables

Referencias relacionadas

• Operación y salud de nodos descentralizados
• Guía de la consola Nodeboard
• Descubrimiento de nodos y relay cifrado verificado