તમે સભ્ય કાઢી નાખો છો, પૃષ્ઠ બંધ કરો છો, અને એક દિવસ પછી એ જ ઉપકરણ પાછું આવે છે. આ કન્સોલની કોઈ ખામી નથી. ઉપકરણ હજી ઓનલાઇન હોય અને હજી જોડાવા માટે વિનંતી કરતું હોય ત્યારે નોંધ કાઢી નાખો ત્યારે આ જ થાય છે.

બે ક્રિયાઓ એકબીજાની બાજુમાં રહે છે અને જુદાં જુદાં કામ કરે છે. એક પ્રવેશ નક્કી કરે છે, અને બીજી ફક્ત યાદી ગોઠવે છે.

પાછી આવતી નોંધથી શરૂ કરો

નેટવર્ક ખોલો અને પાછી આવેલી એન્ટ્રી જુઓ. તેનું node ID, તેનું છેલ્લું સરનામું અને ફરી ક્યારે દેખાયું તેનો સમય નોંધો. તેને તમે નિવૃત્ત કરવા માંગતા હતા તે ઉપકરણ સાથે સરખાવો. દર્શાવેલ નામ એ છે જે કોઈએ લખ્યું હોય, અને સરનામું આગલી જોડાણ વખતે બદલાઈ શકે છે.

node ID એ સ્થિર ઓળખકર્તા છે. નેટવર્ક ID નેટવર્કનું નામ આપે છે, તેથી તે કહે છે કે તમે કઈ યાદી વાંચી રહ્યા છો અને તેમાં કયું ઉપકરણ છે તે વિશે કંઈ કહેતું નથી. બંને નોંધો, પછી node ID ને તમે નિવૃત્ત કરવા માંગતા હતા તે મશીન સાથે મેળવો.

આ સરખામણી ખોટી થાય તો તમે કામ કરતું મશીન દૂર કરશો જ્યારે અનિચ્છનીય એક વિનંતી કરતું રહેશે. પછી યાદી એક દિવસ સાચી લાગે છે. કોઈને ધ્યાન ન પડે તેટલો આ સમય પૂરતો છે, અને સમસ્યા બરાબર એ જ છે.

કાઢી નાખતા પહેલાં રદ કરો

પહેલાં કંટ્રોલર જે વર્કફ્લોને સમર્થન આપે છે તેના દ્વારા અધિકૃતતાની સ્થિતિ બદલો. તે ક્ષણથી, જોડાવાનો પ્રયાસ ચૂપચાપ પ્રવેશ પુનઃસ્થાપિત કરવાને બદલે બિન-અધિકૃત તરીકે દેખાય છે, અને વિનંતી અદૃશ્યને બદલે દૃશ્યમાન બને છે.

કાઢી નાખવું પછી આવે છે, ક્યારેય તેના બદલે નહીં. અધિકૃત સભ્યની નોંધ દૂર કરવાથી રદ કરવા માટે કંઈ બચતું નથી. ઉપકરણ ફરી પૂછે છે, અને કંટ્રોલર તેને નવું ગણે છે.

તમે હજી નિયંત્રિત કરો છો તેવા મશીન માટે નેટવર્ક છોડવું નિવૃત્તિનો ઉપયોગી ભાગ છે. તે ખોવાયેલા ઉપકરણ વિશેના વ્યવસ્થાપકના નિર્ણયનો વિકલ્પ નથી. તમે હવે નિયંત્રિત ન કરતા ક્લાયન્ટને જે કહેવામાં આવ્યું હોય તે અવગણી શકે છે.

બે ક્રિયાઓ ક્યાં રહે છે

હોસ્ટ કરેલા કંટ્રોલર પર સભ્ય યાદી બંને ક્રિયાઓ આપે છે અને તેમને અલગ પાડવા પૂરતા સ્પષ્ટ રીતે લેબલ કરે છે. સ્વયં-હોસ્ટ કરેલા કંટ્રોલર પર એ જ ભેદ API માં અને સ્થાનિક રૂપરેખાંકનમાં દેખાય છે, અને ગૂંચવણ સામાન્ય રીતે ત્યાંથી જ શરૂ થાય છે.

# list members with authorization state
curl -s -H "X-ZT1-Auth: $TOKEN" \
  "http://127.0.0.1:9993/controller/network/$NETWORK_ID/member" | jq 'to_entries[] | {id: .key, authorized: .value.authorized}'

# deauthorize one member by node id, then confirm
curl -s -X POST -H "X-ZT1-Auth: $TOKEN" -d '{"authorized": false}' \
  "http://127.0.0.1:9993/controller/network/$NETWORK_ID/member/$NODE_ID"

સભ્ય ક્યારેય ખરેખર બિન-અધિકૃત હતો કે નહીં તે બતાવવા માટે આ બે કૉલ પૂરતા છે. જે નોંધ authorized: true સાથે વારંવાર પાછી આવે છે તે ક્યારેય રદ થઈ નહોતી; તે ફક્ત કાઢી નાખવામાં આવી હતી.

યાદીમાંથી નહીં, સ્રોતમાંથી ખાતરી કરો

ગોઠવેલી સભ્ય યાદી પ્રવેશની ચકાસણી નથી. ઉપકરણ પહેલાં જે સ્રોત વાપરતું હતું તેને તે જ ઉપકરણ પરથી અથવા તેના જૂના સરનામાવાળા મશીન પરથી અજમાવો અને ખાતરી કરો કે જોડાણ નિષ્ફળ જાય છે. પછી ખાતરી કરો કે મંજૂર કરેલો વિકલ્પ હજી કામ કરે છે.

તે પરીક્ષણમાં રૂટ અને સેવા પરવાનગીઓનો સમાવેશ કરો. ZeroTier સભ્યને અધિકૃત કરી શકે છે અને તેમ છતાં તેને સંચાલિત રૂટ સુધી પહોંચવા દેતું નથી. એપ્લિકેશન પરવાનગી પણ એ જ રીતે નિષ્ફળ જઈ શકે છે. સભ્ય યાદીમાંથી બંને એકસરખા દેખાય છે.

zerotier-cli listnetworks
ip route show | grep zt
ping -c 3 10.144.0.5

સ્વયં-હોસ્ટ કરેલા કંટ્રોલર માટે તેની ઓળખ અને રૂપરેખાંકનનો સુસંગત બેકઅપ રાખો. પહેલાની સ્થિતિમાં પાછું જતું પુનઃસ્થાપન જૂની અધિકૃતતા પણ સાથે લાવી શકે છે, અને સભ્ય યાદી નિવૃત્તિ પહેલાં જેવી જ દેખાશે.

જૂની ઓળખ ક્યાંય પહોંચી શકતી નથી અને નોંધ ગઈ છે ત્યારે નિવૃત્તિ પૂર્ણ થાય છે. આ ક્રમમાં કરો અને સભ્ય પાછો આવવાનું બંધ કરશે.

સંબંધિત લેખો