ZeroTier ONLINE maar ACCESS_DENIED: waar los je dat op?

ZeroTier meldt ONLINE op serviceniveau en ACCESS_DENIED op netwerkniveau, en dat paar is geen tegenspraak. Het eerste is een uitspraak over het pad tussen je client en de coördinatie-infrastructuur. Het tweede is een uitspraak over de ledenlijst van één netwerk. Lees ze apart, en de combinatie vertelt je precies waar je moet zoeken.

Wat ONLINE meet

De statusopdracht meldt of de lokale dienst een werkend pad heeft naar de rootservers die peerdiscovery coördineren. Hij zegt niets over een afzonderlijk netwerk, en niets over de vraag of een controller dit apparaat heeft goedgekeurd. Een nieuwe installatie op een werkende verbinding meldt daarom meteen ONLINE, voordat iemand haar ergens heeft geautoriseerd.

Behandel ONLINE als een uitspraak over de leidingen en de status per netwerk als een uitspraak over lidmaatschap. Het ene met het andere verklaren is waar het grootste deel van deze verwarring begint.

Wat ACCESS_DENIED van je vraagt

Op een privénetwerk houdt de controller een ledenlijst bij. Een node die in die lijst ontbreekt, of er wel in staat maar niet geautoriseerd is, krijgt ACCESS_DENIED zonder enige configuratie buiten de basishandshake. De oplossing zit aan de controllerkant en heeft het nodeadres nodig in plaats van de machinenaam, dus vergelijk het adres in de clientuitvoer met de ledenvermelding en autoriseer die vermelding.

De client opnieuw installeren is de verkeerde eerste stap, want een nieuwe installatie brengt een nieuwe identiteit mee en de oude autorisatie geldt daar niet meer voor. Als het netwerk openbaar is, wijst dezelfde status op een andere toestand, dus vraag de controllereigenaar of het netwerk privé is voordat je om goedkeuring vraagt. Die ene vraag bepaalt de rest van het gesprek.

Statustekst is een vertakking, geen vonnis

Elke status vernauwt de volgende controle, en ze lezen als één foutmelding is wat een oplossing van twee minuten verandert in een middag vol herinstallaties. NOT_FOUND betekent dat de id die je hebt getypt niet bestaat bij die controller, dus de lidmaatschapsvraag is nog niet bereikt. REQUESTING_CONFIGURATION betekent dat de node de controller heeft bereikt en wacht op configuratie die niet komt, wat op het pad wijst en niet op de autorisatie. OK betekent dat lidmaatschap en configuratie gereed zijn, dus is de volgende vraag het toegewezen adres en daarna de dienst zelf.

Twee opdrachten scheiden dit alles, en beide lezen dezelfde client. De ZeroTier CLI-referentie vermeldt de statusstrings per netwerk die ze teruggeven. De eerste opdracht is het dienstbeeld en de tweede is per netwerk:

zerotier-cli status
zerotier-cli listnetworks

Bewaar de statustekst wanneer je de beheerder om hulp vraagt. Een lokaal join-commando dat een bevestiging afdrukte, bewijst alleen dat het verzoek lokaal is geaccepteerd, wat een ander feit is dan toegelaten worden.

Lidmaatschap hoort bij een identiteit

Het zijn de identiteitsbestanden van de client die de controller herkent, dus een configuratie naar een andere machine kopiëren of de identiteit wissen bij een herinstallatie levert een lid op dat de controller nooit heeft gezien. Dat is ook de reden waarom een ledenrecord verwijderen iets anders is dan de autorisatie intrekken. Een geautoriseerde node die nog draait blijft het proberen, en een record dat is verwijderd in plaats van ingetrokken kan terugkomen als een nieuw verzoek vanaf hetzelfde adres.

Wanneer je een apparaat uit gebruik neemt, trek dan eerst de autorisatie in en bevestig dat de vermelding die toestand weergeeft voordat je iets verwijdert. De volgorde is het verschil tussen een schone verwijdering en een mysterieuze hernieuwde toetreding.

Controleer na de wijziging

Lees de netwerkvermelding opnieuw in plaats van de opdracht die de wijziging aanbracht. Vier vragen dekken de uitkomst, en elk daarvan kan fout zijn terwijl de andere er goed uitzien:

zerotier-cli listnetworks
ip -br addr show
ping -c 2 10.147.20.5
ip route get 10.147.20.5

De eerste drukt lidmaatschap en het toegewezen adres per netwerk af, en de tweede laat zien of een interface dat adres echt heeft gekregen. De laatste twee bewijzen dat een peer op het netwerk antwoordt en welke interface het verkeer draagt. Noteer welke opdracht welke vraag beantwoordde, zodat de volgende persoon bij bewijs begint en niet bij geheugen.

Als lidmaatschap OK is en het adres aanwezig is maar peers antwoorden niet, dan is het probleem naar routing of naar het beleid van de peer zelf verschoven. Haal de statustekst uit dat gesprek, want die heeft zijn werk al gedaan. Het lidmaatschapsrecord en het pad zijn aparte onderwerpen, en hoe eerder ze gescheiden worden, hoe korter het onderzoek wordt.