Instalar e registrar um nó descentralizado de privacidade AeroNyx

Este é o fluxo de produção suportado para um nó novo. Ele usa o único ponto de entrada operacional do repositório, vincula a identidade por um código efêmero do Nodeboard, instala systemd e verifica data plane local, heartbeat do backend, discovery assinado e pool público antes de declarar sucesso. Um processo active não prova sozinho que o nó entrou na rede de privacidade AeroNyx.

Console do operador: app.aeronyx.network

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

Antes de começar

Use um host Linux dedicado com endereço público estável. Confirme firewall da nuvem, do host e da rede do provedor. A API de gestão não deve ficar diretamente exposta à Internet.

1. Criar um código de registro de uso único

O registro vincula identidade, capacidades e operador do nó, não conteúdo de usuários. O código expira rapidamente e só pode ser consumido uma vez.

1. Entre no Nodeboard.
2. Abra Registration Codes e gere um código curto para a conta operadora correta.
3. Defina nome do nó e região ISO 3166-1 alpha-2.
4. Não inclua o código em tickets, capturas, histórico do shell ou conversa pública com IA.

2. Obter o script oficial de operação

aeronyx-node.sh não é comando global do Linux; ele pertence ao repositório Rust oficial AeroNyx. Em host novo, obtenha main e execute a partir da raiz do repositório.

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

Não clone sobre diretório existente. Faça fast-forward apenas com tracked worktree limpo; em produção com mudanças locais use upgrade isolado fixado em 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 o plano e executar quickstart

Substitua nome e país do exemplo. --public-vpn é opt-in explícito: sem ele o nó continua registrado e gerenciável, mas não entra no pool público. O modo interativo oculta o código, mostra o plano resolvido e pede confirmação.

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

A automação passa o segredo em uma única linha bounded stdin e usa --yes somente após o plano ser aprovado. O pipe anônimo mantém o código fora do argv dos filhos.

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 e upgrade compartilham um deployment lock do host. Não trate --allow-dirty ou --skip-admission-check como atalhos normais; são apenas para manutenção emergencial ou recuperação isolada aprovada.

4. Provar a admissão na rede

O admission gate padrão espera até 120 segundos e só marca completed quando reúne as evidências aplicáveis. Depois, os comandos read-only abaixo repetem a verificação.

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 retorna ok: listener, TUN, forwarding, NAT, DNS e egress funcionam.
• Policy timestamp recente do backend comprova round trip do heartbeat de gestão assinado.
• Discovery status e snapshot incluem descriptor assinado validado e rodada gossip concluída.
• Nó público aparece com UUID exato, visibility=public, capacidade VPN e status online.
• Nome, região, visibilidade, capacidade e heartbeat no Nodeboard coincidem com o nó.

Nó privado não precisa aparecer no pool público, mas deve passar saúde local, heartbeat registrado e discovery assinado. Para primeiro boot lento use --admission-timeout 240 sem remover verificações.

Papéis públicos e de relay cego opcionais

Saída pública de privacidade, ChatRelay e OnionMiddle sem saída são escolhas separadas. Anuncie relay cego somente quando o endpoint público 8422 estiver acessível, a config for válida e o restart for 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

O helper salva server.toml, altera apenas o campo alvo, valida e recusa restart com active sessions. Nó novo precisa acumular reachability e path-proof recentes; capacidade configurada não significa route eligibility imediata. O two-hop probe exige três nós distintos e routeable; sem eles o resultado correto é blocked.

Operação diária e atualizações seguras

Primeiro build e valide o candidato sem reiniciar; faça a promoção numa janela aprovada. Não execute git pull manual seguido de troca direta do binário de produção.

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

O fluxo verifica active sessions após build, antes de promotion e imediatamente antes do restart; se o contador não estiver disponível, falha fechado. Valida config e systemd, preserva binário/units anteriores, promove atomicamente e faz rollback se a saúde falhar. upgrade-status.json guarda só metadados operacionais.

Contrato de instalação assistida por IA

Codex, Claude Code ou outro agente terminal pode executar o fluxo, mas deve agir como ferramenta operacional limitada, não improvisar por ter root.

1. Confirmar repositório oficial, branch, checkout e commit atual.
2. Executar e exibir plan antes de mudar o host.
3. Passar código apenas por prompt oculto ou bounded stdin.
4. Preservar identidade e config; não sobrescrever arquivos persistentes de /etc/aeronyx.
5. Checar active sessions antes de restart e parar se o valor não for confiável.
6. Validar saúde local, heartbeat backend, alcance público, discovery assinado e Nodeboard.
7. Relatar warning, blocked e rollback; não chamar systemd active de sucesso.

Limite de privacidade

Nó e Nodeboard tratam apenas evidência operacional agregada necessária. O relay permanece cego e a telemetria não pode virar histórico de usuário.

Dados agregados permitidos

• CPU, memória, disco, fd, conntrack e packet drops
• capacidade do pool IP, max connections, pps, bps e número de sessões ativas
• heartbeat, versão, capacidades, peer quorum e status de relay proof

Dados proibidos

• atividade de IP público do cliente, destinos, DNS, domínios, URL ou histórico
• plaintext de pacote/mensagem, interlocutores, grafo social ou plaintext MemChain
• chaves privadas, código de registro, voucher secrets, tráfego wallet ou credencial identificável

Referências relacionadas

• Operação e saúde de nós descentralizados
• Guia do console Nodeboard
• Discovery de nós e relay cifrado verificado