حذف شدہ 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

اپنے میزبان کنٹرولر کے لیے اس کی شناخت اور ترتیب کا مسلسل بیک اپ رکھیں۔ پچھلی حالت میں واپس جانے والی بحالی پرانی اجازت بھی ساتھ لا سکتی ہے، اور رکن فہرست ریٹائرمنٹ سے پہلے جیسی ہی دکھے گی۔

ریٹائرمنٹ تب مکمل ہوتی ہے جب پرانی شناخت کہیں نہ پہنچ سکے اور ریکارڈ جا چکا ہو۔ یہ کام اسی ترتیب سے کریں، رکن واپس آنا بند کر دے گا۔