Autorizat în ZeroTier dar fără adresă? Două setări separate
Aprobarea unui membru și atribuirea unei adrese sunt două setări. Citiți pool-ul, modul de alocare și starea aplicată a clientului înainte de a inventa un IP.
ZeroTier arată membrul ca OK, rețeaua este alăturată și totuși nu există nicio adresă de pingat. Această combinație pare un defect și de obicei este o configurație despărțită: aprobarea unui membru este un întrerupător, iar atribuirea unei adrese este altul. O rețea poate accepta un dispozitiv și nu îi poate aloca niciodată nimic, pentru că pool-ul sau modul de alocare nu a fost configurat.
Citiți ambele părți înainte de a schimba oricare dintre ele. Răspunsul este vizibil în două locuri, iar doar unul dintre ele este pe controler.
Autorizarea și alocarea sunt întrerupătoare diferite
Autorizarea răspunde dacă acest nod poate participa la rețea. Alocarea adreselor răspunde ce îi dă rețeaua după ce participă, iar răspunsul vine dintr-un pool de adrese plus un mod de alocare. Niciuna dintre setări nu o implică pe cealaltă. Una este o permisiune, cealaltă este o alocare.
Configurația unui controler conține de obicei o rută administrată, un interval de adrese și modul care decide dacă se folosește alocarea automată. Copierea unui identificator de rețea din alt mediu aduce apartenența și nimic din acea configurație.
De aceea un dispozitiv poate părea sănătos în lista de membri în timp ce coloana adresei alocate rămâne goală. Controlerul l-a acceptat și nu are nimic de dat. Ambele afirmații sunt adevărate în același timp.
| 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 |
Citirea stării efective a membrului
Întrebați clientul ce a primit de fapt, nu ce a intenționat controlerul. Lista simplă arată coloanele de stare și adresă, iar forma JSON arată configurația de rețea pe care clientul a aplicat-o, inclusiv adresele și rutele administrate.
zerotier-cli listnetworks
zerotier-cli -j listnetworks | jq '.networks[] | {nwid, status, assignedAddresses}'Comparați cele două ieșiri pentru același identificator de rețea, nu pentru adaptoarele fizice care apar în lista proprie a sistemului de operare. Un rând care raportează OK cu un set de adrese gol confirmă golul de alocare și nu o defecțiune de conectivitate. Citirea rândului greșit este cealaltă jumătate a acestei greșeli.
O stare ACCESS_DENIED indică înapoi spre autorizare, iar aceea este o altă reparație. Dacă comanda nu poate citi deloc tokenul de autentificare local, problema este permisiunile locale și nu un refuz al controlerului, iar corectarea se face pe mașina la care stați.
Când clientul ignoră ce trimite controlerul
Clientul are propriile setări care decid dacă se aplică configurația administrată. Un profil care dezactivează adresele administrate, rutele administrate sau tratarea rutei implicite va arunca ce trimite rețeaua, iar lista de membri va continua să pară corectă din partea controlerului.
Acele marcaje afectează doar nodul local. Schimbarea lor nu modifică ce primesc ceilalți membri și nu repară un pool care nu a fost niciodată definit.
Așadar diagnosticul are două ramuri: fie controlerul nu are nicio adresă de dat, fie clientul a refuzat adresa primită. Ele duc la reparații diferite pe mașini diferite. Ieșirea JSON le distinge, pentru că adresa fie lipsește din configurația rețelei, fie există și lipsește din starea aplicată a clientului.
Ce să reparați în loc să inventați o adresă
Tastarea unei adrese statice arbitrare este a treia opțiune tentantă și cea mai rea. O adresă aleatoare poate intra în conflict cu alt nod, poate sta în afara rutelor pe care rețeaua le propagă sau poate cădea într-un interval pe care regulile firewall-ului îl tratează diferit. De asemenea, ascunde pool-ul lipsă de oricine se uită apoi la rețea. Reparați mai degrabă alocarea și lăsați controlerul și clientul să cadă de acord asupra rezultatului.
Întrebați administratorul ce ar trebui să distribuie rețeaua, apoi verificați că pool-ul acoperă intervalul dorit și că modul de alocare este activat. Re-alăturați-vă după schimbare în loc să vă așteptați ca clientul să ajungă singur imediat la o configurație nouă.
Odată ce apare o adresă, testați ce aveați nevoie de fapt: un peer, un serviciu sau o subrețea în spatele unei gateway. A ajunge la un LAN din spatele unui membru necesită rutare și forwardare dincolo de apartenență, iar accesul general la internet necesită un nod de ieșire, așa că o adresă funcțională este începutul acelui test, nu sfârșitul.