মুছে ফেলা ZeroTier সদস্য ফিরে আসছে: আগে অনুমোদন প্রত্যাহার করুন

আপনি সদস্য মুছে ফেলেন, পৃষ্ঠা বন্ধ করেন, আর এক দিন পরে সেই ডিভাইসটিই ফিরে আসে। এটি কনসোলের কোনো বাগ নয়। ডিভাইসটি যখন অনলাইনে থাকে এবং তখনও যোগ দেওয়ার অনুরোধ করে, তখনই রেকর্ড মুছলে এটিই ঘটে।

দুটি কাজ পাশাপাশি থাকে এবং ভিন্ন ভিন্ন দায়িত্ব পালন করে। একটি প্রবেশাধিকার নির্ধারণ করে, অন্যটি শুধু তালিকা গুছিয়ে রাখে।

ফিরে আসা রেকর্ড থেকেই শুরু করুন

নেটওয়ার্ক খুলে যে এন্ট্রিটি ফিরে এসেছে সেটি দেখুন। এর node ID, শেষ ঠিকানা এবং আবার কখন দেখা দিয়েছে তা লিখে রাখুন। এটি আপনার অবসরে পাঠানোর কথা থাকা ডিভাইসের সঙ্গে মিলিয়ে দেখুন। প্রদর্শিত নাম যেটি কেউ টাইপ করেছে সেটিই, আর ঠিকানা পরের যোগ দেওয়ার সময় বদলে যেতে পারে।

Node 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

নিজে হোস্ট করা কন্ট্রোলারের জন্য তার পরিচয় ও কনফিগারেশনের একটি সামঞ্জস্যপূর্ণ ব্যাকআপ রাখুন। আগের অবস্থায় ফিরে যাওয়া কোনো পুনরুদ্ধার পুরোনো অনুমোদনও সঙ্গে ফিরিয়ে আনতে পারে, আর সদস্য তালিকা অবসরে পাঠানোর আগের মতোই দেখাবে।

পুরোনো পরিচয় যখন কোনো কিছুতে পৌঁছাতে পারে না এবং রেকর্ডটিও থাকে না, তখনই অবসরে পাঠানো শেষ হয়। এই ক্রমে কাজগুলো করুন, সদস্যটি আর ফিরে আসবে না।