ZeroTier arată ONLINE, dar ACCESS_DENIED: unde se repară?

ZeroTier raportează ONLINE la nivel de serviciu și ACCESS_DENIED la nivel de rețea, iar perechea nu este o contradicție. Prima este o afirmație despre calea dintre clientul tău și infrastructura de coordonare. A doua este o afirmație despre lista de membri a unei rețele. Citește-le separat, iar combinația îți spune exact unde să cauți.

Ce măsoară ONLINE

Comanda de stare raportează dacă serviciul local are o cale funcțională către serverele root care coordonează descoperirea peerilor. Nu spune nimic despre o rețea anume și nimic despre faptul că un controller a aprobat acest dispozitiv. De aceea o instalare nouă pe o conexiune funcțională raportează ONLINE imediat, înainte ca cineva să o fi autorizat undeva.

Tratează ONLINE ca o afirmație despre instalație și starea pe rețea ca o afirmație despre apartenență. Folosirea uneia pentru a o explica pe cealaltă este locul unde începe cea mai mare parte a acestei confuzii.

Ce îți cere ACCESS_DENIED

Într-o rețea privată controllerul ține o listă de membri. Un nod care lipsește din acea listă, sau apare dar nu este autorizat, primește ACCESS_DENIED împreună cu nicio configurație dincolo de handshake-ul de bază. Reparația este pe partea controllerului și are nevoie de adresa nodului, nu de numele mașinii, așa că potrivește adresa din ieșirea clientului cu intrarea de membru și autorizează acea intrare.

Reinstalarea clientului este primul pas greșit, pentru că o instalare nouă aduce o identitate nouă, iar autorizarea veche nu se mai aplică ei. Dacă rețeaua este publică, aceeași stare indică o altă condiție, așa că întreabă proprietarul controllerului dacă rețeaua este privată înainte de a cere aprobare. Acea singură întrebare decide restul conversației.

Textul de stare este o ramură, nu o sentință

Fiecare stare îngustează verificarea următoare, iar citirea lor ca un singur mesaj de eroare este ce transformă o reparație de două minute într-o după-amiază plină de reinstalări. NOT_FOUND înseamnă că identificatorul tastat nu există la acel controller, deci întrebarea despre apartenență nu a fost încă atinsă. REQUESTING_CONFIGURATION înseamnă că nodul a ajuns la controller și așteaptă o configurație care nu sosește, ceea ce indică spre cale, nu spre autorizare. OK înseamnă că apartenența și configurația sunt la locul lor, deci următoarea întrebare este adresa atribuită și apoi serviciul în sine.

Două comenzi separă toate acestea, și ambele citesc același client. Referința CLI ZeroTier enumeră șirurile de stare pe rețea pe care le returnează. Prima comandă este vederea serviciului, iar a doua este pe rețea:

zerotier-cli status
zerotier-cli listnetworks

Păstrează textul de stare când ceri ajutor administratorului. O comandă join locală care a tipărit o confirmare dovedește doar că cererea a fost acceptată local, ceea ce este un alt fapt decât admiterea.

Apartenența aparține unei identități

Controllerul recunoaște exact fișierele de identitate ale clientului, așa că copierea unei configurații pe altă mașină sau ștergerea identității în timpul unei reinstalări produce un membru pe care controllerul nu l-a văzut niciodată. Acesta este și motivul pentru care ștergerea unei înregistrări de membru diferă de revocarea autorizării acesteia. Un nod autorizat care încă rulează continuă să încerce, iar o înregistrare ștearsă în loc de revocată poate reveni ca o cerere nouă de la aceeași adresă.

Când scoți un dispozitiv din uz, revocă mai întâi autorizarea și confirmă că intrarea reflectă acea stare înainte de a elimina ceva. Ordinea este diferența dintre o eliminare curată și o reapariție misterioasă.

Verifică după modificare

Recitește intrarea de rețea, nu comanda care a făcut modificarea. Patru întrebări acoperă rezultatul, iar oricare dintre ele poate fi greșită în timp ce celelalte par corecte:

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

Prima tipărește apartenența și adresa atribuită pentru fiecare rețea, iar a doua arată dacă o interfață a primit într-adevăr acea adresă. Ultimele două dovedesc că un peer din rețea răspunde și care interfață transportă traficul. Notează ce comandă a răspuns la ce întrebare, ca următoarea persoană să pornească de la dovezi, nu de la memorie.

Dacă apartenența este OK și adresa este prezentă dar peerii nu răspund, problema s-a mutat la rutare sau la politica peerului însuși. Scoate textul de stare din acea conversație, pentru că și-a făcut deja treaba. Înregistrarea de apartenență și calea sunt subiecte separate, și cu cât sunt separate mai devreme, cu atât ancheta devine mai scurtă.