ZeroTier يظهر ONLINE لكن ACCESS_DENIED: أين تُصلح ذلك؟
ONLINE يصف الاتصال بالبنية الجذرية؛ ACCESS_DENIED يصف العضوية في شبكة واحدة. الإصلاح يقع على جانب المتحكم.
يبلغ ZeroTier عن الحالة ONLINE على مستوى الخدمة وعن ACCESS_DENIED على مستوى الشبكة، وهذا ليس تناقضًا. الأول عبارة عن المسار بين عميلك والبنية التي تنسق الاكتشاف. والثاني عبارة عن قائمة أعضاء شبكة واحدة. اقرأهما منفصلين، وسيدلك اجتماعهما على مكان البحث بالتحديد.
ما الذي يقيسه ONLINE
يبلغ أمر الحالة عمّا إذا كانت الخدمة المحلية تملك مسارًا عاملًا إلى الخوادم الجذرية التي تنسق اكتشاف الأقران. ولا يقول شيئًا عن أي شبكة بعينها، ولا عمّا إذا كان متحكم قد اعتمد هذا الجهاز. لذلك يبلغ تثبيت جديد على اتصال عامل عن ONLINE فورًا، قبل أن يأذن به أحد في أي مكان.
تعامل مع ONLINE كعبارة عن التمديدات، ومع حالة كل شبكة كعبارة عن العضوية. واستخدام أحدهما لتفسير الآخر هو مبدأ معظم هذا الالتباس.
ما الذي يطلبه منك ACCESS_DENIED
في شبكة خاصة يحتفظ المتحكم بقائمة أعضاء. والعقدة الغائبة عن تلك القائمة، أو المدرجة دون إذن، تتلقى ACCESS_DENIED مع عدم وصول أي إعداد يتجاوز المصافحة الأساسية. الإصلاح على جانب المتحكم ويحتاج إلى عنوان العقدة لا إلى اسم الجهاز، لذا طابق العنوان في مخرجات عميلك مع قيد العضوية وأذن لذلك القيد.
إعادة تثبيت العميل هي الخطوة الأولى الخاطئة، لأن التثبيت الجديد يجلب هوية جديدة ولم يعد الإذن القديم ينطبق عليها. وإذا كانت الشبكة عامة، فالحالة نفسها تشير إلى شرط مختلف، لذا اسأل مالك المتحكم ما إذا كانت الشبكة خاصة قبل طلب الموافقة. ذلك السؤال وحده يحدد بقية المحادثة.
نص الحالة فرع لا حكم
كل حالة تضيّق الفحص التالي، وقراءتها كرسالة فشل واحدة هي ما يحول إصلاحًا يستغرق دقيقتين إلى عصر كامل من إعادة التثبيت. NOT_FOUND يعني أن المعرّف الذي كتبته غير موجود لدى ذلك المتحكم، فلم يصل السؤال عن العضوية بعد. REQUESTING_CONFIGURATION يعني أن العقدة وصلت إلى المتحكم وتنتظر إعدادًا لا يصل، وهذا يشير إلى المسار لا إلى الإذن. OK يعني أن العضوية والإعداد في مكانهما، لذا السؤال التالي هو العنوان المخصص ثم الخدمة نفسها.
أمران يفصلان كل هذا، وكلاهما يقرأ العميل نفسه. ويسرد مرجع ZeroTier CLI سلاسل حالة كل شبكة كما يعيدها العميل. الأمر الأول هو عرض الخدمة والثاني لكل شبكة:
zerotier-cli status
zerotier-cli listnetworks
احتفظ بنص الحالة عندما تطلب المساعدة من المسؤول. أمر انضمام محلي طبع تأكيدًا يثبت فقط أن الطلب قُبل محليًا، وهي حقيقة مختلفة عن القبول في الشبكة.
العضوية تنتمي إلى هوية
ملفات هوية العميل هي ما يتعرف عليه المتحكم، لذا فإن نسخ إعداد إلى جهاز آخر أو مسح الهوية أثناء إعادة التثبيت ينتج عضوًا لم يره المتحكم قط. ولهذا أيضًا حذف سجل عضو يختلف عن إلغاء الإذن به. العقدة المصرح لها والتي لا تزال تعمل تستمر في المحاولة، والسجل الذي حُذف بدلًا من سحبه يمكن أن يعود كطلب جديد من العنوان نفسه.
عند إخراج جهاز من الخدمة، اسحب إذنه أولًا وتأكد من أن القيد يعكس تلك الحالة قبل أن تحذف أي شيء. الترتيب هو الفرق بين إزالة نظيفة وعودة غامضة.
تحقق بعد التغيير
أعد قراءة قيد الشبكة بدلًا من الأمر الذي أجرى التغيير. أربعة أسئلة تغطي النتيجة، وأي واحد منها يمكن أن يكون خاطئًا بينما تبدو الأخرى صحيحة:
zerotier-cli listnetworks
ip -br addr show
ping -c 2 10.147.20.5
ip route get 10.147.20.5
الأول يطبع العضوية والعنوان المخصص لكل شبكة، والثاني يبين ما إذا كانت واجهة قد تلقت ذلك العنوان فعلًا. والأخيران يثبتان أن قرينًا في الشبكة يجيب وأي واجهة تحمل الحركة. سجّل أي أمر أجاب عن أي سؤال، ليبدأ الشخص التالي من دليل لا من ذاكرة.
إذا كانت العضوية OK والعنوان موجودًا لكن الأقران لا تجيب، فقد انتقلت المشكلة إلى التوجيه أو إلى سياسة القرين نفسه. أخرج نص الحالة من تلك المحادثة، فقد أدى عمله بالفعل. سجل العضوية والمسار موضوعان منفصلان، وكلما أسرع الفصل بينهما قصر التحقيق.