ZeroTier ONLINE mas ACCESS_DENIED: onde corrigir?
ONLINE descreve o contacto com a infraestrutura root; ACCESS_DENIED descreve a pertença a uma rede. A correção fica do lado do controlador.
ZeroTier reporta ONLINE ao nível do serviço e ACCESS_DENIED ao nível da rede, e o par não é uma contradição. O primeiro é uma afirmação sobre o caminho entre o seu cliente e a infraestrutura de coordenação. O segundo é uma afirmação sobre a lista de membros de uma rede. Leia-os separadamente e a combinação diz-lhe exatamente onde procurar.
O que o ONLINE mede
O comando de estado reporta se o serviço local tem um caminho funcional até aos servidores root que coordenam a descoberta de peers. Não diz nada sobre uma rede individual, nem sobre se um controlador aprovou este dispositivo. Uma instalação nova numa ligação funcional reporta portanto ONLINE de imediato, antes de alguém a ter autorizado em qualquer lugar.
Trate o ONLINE como uma afirmação sobre a canalização e o estado por rede como uma afirmação sobre a pertença. Usar um para explicar o outro é onde começa a maior parte desta confusão.
O que o ACCESS_DENIED lhe pede
Numa rede privada o controlador mantém uma lista de membros. Um nó ausente dessa lista, ou listado mas não autorizado, recebe ACCESS_DENIED sem qualquer configuração além do handshake básico. A correção está do lado do controlador e precisa do endereço do nó e não do nome da máquina, por isso compare o endereço na saída do cliente com a entrada de membro e autorize essa entrada.
Reinstalar o cliente é o primeiro passo errado, porque uma instalação nova traz uma identidade nova e a autorização antiga deixa de se aplicar a ela. Se a rede for pública, o mesmo estado aponta para outra condição, por isso pergunte ao proprietário do controlador se a rede é privada antes de pedir aprovação. Essa única pergunta decide o resto da conversa.
O texto de estado é um ramo, não um veredicto
Cada estado estreita a verificação seguinte, e é lê-los como uma única mensagem de falha que transforma uma correção de dois minutos numa tarde inteira de reinstalações. NOT_FOUND significa que o identificador que escreveu não existe nesse controlador, portanto a questão da pertença ainda não foi alcançada. REQUESTING_CONFIGURATION significa que o nó chegou ao controlador e aguarda uma configuração que não chega, o que aponta para o caminho e não para a autorização. OK significa que a pertença e a configuração estão no lugar, portanto a pergunta seguinte é o endereço atribuído e depois o próprio serviço.
Dois comandos separam tudo isto, e ambos leem o mesmo cliente. A referência da CLI do ZeroTier lista as cadeias de estado por rede que eles devolvem. O primeiro comando é a vista do serviço e o segundo é por rede:
zerotier-cli status
zerotier-cli listnetworks
Guarde o texto de estado quando pedir ajuda ao administrador. Um comando join local que imprimiu uma confirmação prova apenas que o pedido foi aceite localmente, o que é um facto diferente de ser admitido.
A pertença pertence a uma identidade
São os ficheiros de identidade do cliente que o controlador reconhece, por isso copiar uma configuração para outra máquina ou apagar a identidade durante uma reinstalação produz um membro que o controlador nunca viu. É também a razão pela qual eliminar um registo de membro é diferente de revogar a sua autorização. Um nó autorizado que continua em execução continua a tentar, e um registo eliminado em vez de revogado pode voltar como um novo pedido a partir do mesmo endereço.
Quando retira um dispositivo, revogue primeiro e confirme que a entrada reflete esse estado antes de remover o que quer que seja. A ordem é a diferença entre uma remoção limpa e um reingresso misterioso.
Verifique depois da alteração
Releia a entrada de rede em vez do comando que fez a alteração. Quatro perguntas cobrem o resultado, e qualquer uma delas pode estar errada enquanto as outras parecem certas:
zerotier-cli listnetworks
ip -br addr show
ping -c 2 10.147.20.5
ip route get 10.147.20.5
O primeiro imprime a pertença e o endereço atribuído para cada rede, e o segundo mostra se uma interface recebeu realmente esse endereço. Os dois últimos provam que um peer na rede responde e qual interface transporta o tráfego. Anote qual comando respondeu a qual pergunta, para que a próxima pessoa comece pela evidência e não pela memória.
Se a pertença for OK e o endereço estiver presente mas os peers não responderem, o problema passou para o encaminhamento ou para a política do próprio peer. Retire o texto de estado dessa conversa, porque já fez o seu trabalho. O registo de pertença e o caminho são assuntos separados, e quanto mais cedo forem separados, mais curta fica a investigação.