Autorisé dans ZeroTier mais sans adresse ? Deux réglages distincts
Approuver un membre et lui attribuer une adresse sont deux réglages. Lisez le pool, le mode d'attribution et l'état appliqué du client avant d'inventer une IP.
ZeroTier affiche le membre comme OK, le réseau est joint, et il n'y a toujours aucune adresse à pinguer. Cette combinaison ressemble à un bug et c'est généralement une configuration coupée en deux : approuver un membre est un interrupteur, lui attribuer une adresse en est un autre. Un réseau peut accepter un appareil et ne jamais lui attribuer quoi que ce soit, parce que le pool ou le mode d'attribution n'a jamais été configuré.
Lisez les deux côtés avant de modifier l'un ou l'autre. La réponse est visible à deux endroits, et un seul d'entre eux se trouve sur le contrôleur.
Autorisation et attribution sont deux interrupteurs différents
L'autorisation répond à la question de savoir si ce nœud peut participer au réseau. L'attribution d'adresses répond à ce que le réseau lui donne une fois qu'il participe, et cette réponse vient d'un pool d'adresses plus un mode d'attribution. Aucun des deux réglages n'implique l'autre. L'un est une permission, l'autre une allocation.
La configuration d'un contrôleur comporte généralement une route gérée, une plage d'adresses et le mode qui décide si l'attribution automatique est utilisée. Copier un identifiant de réseau depuis un autre environnement apporte l'adhésion et rien de cette configuration.
C'est pourquoi un appareil peut paraître sain dans la liste des membres alors que sa colonne d'adresse attribuée reste vide. Le contrôleur l'a accepté et n'a rien à donner. Les deux affirmations sont vraies en même temps.
| Layer | What it decides | Where it is configured |
|---|---|---|
| Membership | Whether the node may join | Member authorization on the network |
| Pool | Which addresses exist to hand out | Network address range |
| Assignment mode | Whether they are handed out automatically | Network v4/v6 assignment settings |
Lire l'état effectif du membre
Demandez au client ce qu'il a réellement reçu plutôt que ce que le contrôleur avait l'intention de donner. La liste simple montre les colonnes d'état et d'adresse, et la forme JSON montre la configuration réseau que le client a appliquée, y compris les adresses et les routes gérées.
zerotier-cli listnetworks
zerotier-cli -j listnetworks | jq '.networks[] | {nwid, status, assignedAddresses}'Comparez les deux sorties pour le même identifiant de réseau, pas pour les adaptateurs physiques qui apparaissent dans la liste propre au système d'exploitation. Une ligne qui signale OK avec un ensemble d'adresses vide confirme la lacune d'attribution et non une panne de connectivité. Lire la mauvaise ligne est l'autre moitié de cette erreur.
Un état ACCESS_DENIED renvoie à l'autorisation, et c'est une autre réparation. Si la commande ne peut pas lire du tout le jeton d'authentification local, le problème vient des permissions locales et non d'un rejet du contrôleur, et la correction se fait sur la machine où vous êtes assis.
Quand le client ignore ce que le contrôleur envoie
Le client a ses propres réglages qui décident si la configuration gérée est appliquée. Un profil qui désactive les adresses gérées, les routes gérées ou la gestion de la route par défaut écartera ce que le réseau envoie, et la liste des membres continuera de paraître correcte du côté du contrôleur.
Ces indicateurs n'affectent que le nœud local. Les modifier ne change pas ce que reçoivent les autres membres et ne répare pas un pool qui n'a jamais été défini.
Le diagnostic a donc deux branches : soit le contrôleur n'a aucune adresse à donner, soit le client a refusé celle qu'on lui a donnée. Elles mènent à des réparations différentes sur des machines différentes. La sortie JSON les distingue, car l'adresse est soit absente de la configuration du réseau, soit présente et manquante dans l'état appliqué du client.
Que réparer au lieu d'inventer une adresse
Saisir une adresse statique arbitraire est la troisième option tentante et la pire. Une adresse aléatoire peut entrer en collision avec un autre nœud, se trouver hors des routes que le réseau propage, ou tomber dans une plage que les règles du pare-feu traitent différemment. Elle cache aussi le pool manquant à quiconque regardera le réseau ensuite. Réparez plutôt l'attribution, et laissez le contrôleur et le client s'accorder sur le résultat.
Demandez à l'administrateur ce que le réseau est censé distribuer, puis vérifiez que le pool couvre la plage prévue et que le mode d'attribution est activé. Rejoignez le réseau après le changement au lieu d'attendre que le client trouve de lui-même immédiatement une nouvelle configuration.
Dès qu'une adresse apparaît, testez ce dont vous aviez réellement besoin : un pair, un service ou un sous-réseau derrière une passerelle. Atteindre un LAN derrière un membre demande du routage et du transfert au-delà de l'adhésion, et l'accès général à Internet demande un nœud de sortie, donc une adresse fonctionnelle est le début de ce test et non sa fin.