நீக்கப்பட்ட 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

நீங்களே வழங்கும் கட்டுப்படுத்திக்கு அதன் அடையாளம் மற்றும் கட்டமைப்பின் சீரான காப்புப்பிரதியை வைத்திருங்கள். முந்தைய நிலைக்குத் திரும்பும் மீட்டமைப்பு பழைய அனுமதியையும் சேர்த்து கொண்டு வரலாம், உறுப்பினர் பட்டியல் ஓய்வுக்கு முன்பு போலவே தெரியும்.

பழைய அடையாளம் எதையும் அடைய முடியாதபோதும் பதிவு போய்விட்டபோதும் ஓய்வு முடிந்தது. இதை இந்த வரிசையில் செய்யுங்கள், உறுப்பினர் திரும்பி வருவது நிற்கும்.