عضو ZeroTier المحذوف يعود دائمًا: ألغِ التصريح أولًا

تحذف العضو وتغلق الصفحة، وبعد يوم يعود الجهاز نفسه. هذا ليس خطأً في لوحة التحكم، بل ما يحدث عندما يُحذف السجل والجهاز ما زال متصلًا وما زال يطلب الانضمام.

عمليتان متجاورتان تؤديان مهمتين مختلفتين: إحداهما تقرر الوصول، والأخرى ترتب القائمة فقط.

ابدأ من السجل الذي يعود

افتح الشبكة وانظر إلى المدخل الذي عاد. دوّن معرّف العقدة node ID وآخر عنوان له ووقت ظهوره من جديد، ثم قارن ذلك بالجهاز الذي أردت إحالته إلى التقاعد. اسم العرض هو ما كتبه أحدهم، وقد يتغير العنوان عند الانضمام التالي.

معرّف العقدة هو المعرّف الثابت. معرّف الشبكة يسمّي الشبكة، فهو يخبرك أي قائمة تقرأ ولا يخبرك بشيء عن الجهاز الموجود فيها. سجّل الاثنين، ثم طابق معرّف العقدة مع الجهاز الذي أردت إحالته إلى التقاعد.

إذا أخطأت في هذه المقارنة، فستزيل جهازًا يعمل بينما يواصل الجهاز غير المرغوب فيه الطلب. تبدو القائمة صحيحة ليوم واحد، وهو وقت كافٍ ألا يلاحظ أحد شيئًا، وهذه هي المشكلة بالضبط.

اسحب التصريح قبل أن تحذف

غيّر حالة التصريح أولًا عبر سير العمل الذي يدعمه المتحكم controller. من تلك اللحظة تظهر محاولة الانضمام كغير مصرّح بها بدل أن تعيد الوصول بهدوء، ويصبح الطلب مرئيًا لا خفيًا.

يأتي الحذف بعد ذلك، ولا يأتي بدلًا منه أبدًا. إزالة سجل عضو مصرّح به لا تترك شيئًا لسحبه. يطلب الجهاز مرة أخرى، فيتعامل معه المتحكم كجهاز جديد.

بالنسبة إلى جهاز ما زلت تتحكم فيه، فإن مغادرة الشبكة جزء مفيد من التقاعد، لكنها ليست بديلًا عن قرار المسؤول بشأن جهاز مفقود. العميل الذي لم تعد تتحكم فيه يمكنه تجاهل أي شيء قيل له.

أين توجد العمليتان

على متحكم مستضاف، تعرض قائمة الأعضاء الإجراءين وتسمّيهما بوضوح يكفي للتمييز بينهما. وعلى متحكم مستضاف ذاتيًا، يظهر التمييز نفسه في واجهة 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

بالنسبة إلى متحكم مستضاف ذاتيًا، احتفظ بنسخة احتياطية متسقة من هويته وإعداده. فالاستعادة التي ترجع إلى حالة أقدم قد تعيد تصريحًا قديمًا معها، وستبدو قائمة الأعضاء تمامًا كما كانت قبل التقاعد.

يكتمل التقاعد عندما لا تعود الهوية القديمة قادرة على الوصول إلى أي شيء ويختفي السجل. افعل ذلك بهذا الترتيب يتوقف العضو عن العودة.