ഇല്ലാതാക്കിയ ZeroTier അംഗം തിരികെ വരുന്നു: ആദ്യം അനുമതി റദ്ദാക്കുക

അംഗത്തെ ഇല്ലാതാക്കി പേജ് അടയ്ക്കുന്നു, ഒരു ദിവസത്തിനു ശേഷം അതേ ഉപകരണം തിരികെ എത്തുന്നു. ഇത് കൺസോളിലെ ബഗ് അല്ല. ഉപകരണം ഇപ്പോഴും ഓൺലൈനിലിരിക്കെ തുടർന്നും ചേരാൻ ആവശ്യപ്പെടുമ്പോൾ രേഖ ഇല്ലാതാക്കിയാൽ ഇതാണ് സംഭവിക്കുന്നത്.

രണ്ട് പ്രവർത്തനങ്ങൾ അടുത്തടുത്ത് നിലകൊള്ളുന്നു, വ്യത്യസ്ത ജോലികൾ ചെയ്യുന്നു. ഒന്ന് പ്രവേശനം തീരുമാനിക്കുന്നു, മറ്റൊന്ന് പട്ടിക ക്രമീകരിക്കുക മാത്രം ചെയ്യുന്നു.

തിരികെ വരുന്ന രേഖയിൽ നിന്ന് തുടങ്ങുക

നെറ്റ്വർക്ക് തുറന്ന് തിരികെ വന്ന എൻട്രി നോക്കുക. അതിന്റെ 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

സ്വയം ഹോസ്റ്റ് ചെയ്യുന്ന കൺട്രോളറിന് അതിന്റെ ഐഡന്റിറ്റിയുടെയും കോൺഫിഗറേഷന്റെയും സ്ഥിരതയുള്ള ബാക്കപ്പ് സൂക്ഷിക്കുക. മുൻപത്തെ അവസ്ഥയിലേക്ക് പോകുന്ന പുനഃസ്ഥാപനം പഴയ അനുമതിയും കൂടെ കൊണ്ടുവരാം, അംഗ പട്ടിക ഒഴിവാക്കലിന് മുൻപുള്ളതുപോലെ തന്നെ കാണും.

പഴയ ഐഡന്റിറ്റിക്ക് ഒന്നിലും എത്താൻ കഴിയാതെ രേഖ പോയിക്കഴിഞ്ഞാൽ ഒഴിവാക്കൽ പൂർത്തിയാകുന്നു. ഈ ക്രമത്തിൽ ചെയ്യുക, അംഗം തിരികെ വരുന്നത് നിർത്തും.