دقة المصدر واضحة بشكل غير معتاد: لم يكن هذا عطلًا في Docker يؤثر في جميع التطبيقات. كان المستخدم قد ضبط Tailscale باستخدام إعداد عقدة خروج، وبعد ذلك توقفت Jellyfin وعناوين URL للتطبيقات الأخرى عن العمل حتى على الشبكة المحلية. ثم أزال Tailscale، واتصل عبر عنوان IP المحلي لـ ZimaOS، وأفاد بأن كل شيء عاد إلى العمل.
يتوافق هذا السلوك مع وثائق Tailscale الحالية. عند استخدام العميل لعقدة خروج، يُعطَّل الوصول إلى الشبكة المحلية افتراضيًا ما لم يتم تفعيل السماح بالوصول إلى الشبكة المحلية. قبل إعادة تثبيت التطبيقات أو إعادة تشغيل Docker، تحقّق من جدول التوجيه ومن كون العميل يرسل حركة المرور عمدًا عبر عقدة خروج.
فشلت منافذ التطبيقات المباشرة أيضًا
جرّب المستخدم فتح منافذ التطبيقات مباشرة، وقال إن جميعها فشلت باستثناء Tailscale. وهذه إشارة مفيدة: عندما يتعذر الوصول إلى عدة حاويات غير مرتبطة في الوقت نفسه، اختبر طبقات الشبكة والتوجيه المشتركة قبل افتراض أن كل تطبيق تعطل بشكل مستقل.
كان أمر إعادة تشغيل Docker الفاشل مصدر تشتيت
ليس ZimaOS نظام Debian عامًا تنطبق فيه جميع أوامر إدارة الخدمات الواردة في الشروحات المتاحة على الإنترنت. إذا فشلت جميع التطبيقات، فتحقق أولًا من أن الحاويات تعمل فعلًا ومن أن منافذها المنشورة يمكن الوصول إليها من المضيف أو الشبكة المحلية.
تغيّر عقد الخروج المسار الافتراضي للعميل
توجّه عقد الخروج في Tailscale حركة مرور الإنترنت العامة عبر جهاز آخر في شبكة tailnet. وتنص وثائق Tailscale الحالية صراحةً على أن الوصول إلى الشبكة المحلية يكون معطّلًا افتراضيًا أثناء استخدام عقدة خروج.
راجع سلوك عقد الخروج الحالي في Tailscale.
فعّل السماح بالوصول إلى الشبكة المحلية عند الحاجة المقصودة إلى كليهما
توفّر عملاء Tailscale الحاليون خيار السماح بالوصول إلى الشبكة المحلية. وفي العملاء المعتمدين على CLI، يمكن ضبط الخيار المكافئ باستخدام علامة السماح بالوصول إلى الشبكة المحلية عبر عقدة الخروج.
فعّل هذا الخيار فقط عندما تكون الشبكة المحلية موثوقة.
عطّل عقدة الخروج لعزل المشكلة
تتمثل خطوة تشخيص سريعة في اختيار لا شيء بوصفه عقدة الخروج النشطة، ثم إعادة محاولة الوصول إلى عنوان IP المحلي لـ ZimaOS وإلى منفذ تطبيق واحد. إذا عاد الوصول المحلي فورًا، فإن إعداد التوجيه، لا Docker، هو المكان الأهم للتحقيق فيه.
أزال صاحب المنشور الأصلي Tailscale وأكد عودة الخدمة
قال المستخدم إن الكمبيوتر كان ينقطع عن مسار الموجّه أو عنوان IP المحلي عند الاتصال عبر إعداد Tailscale الخاص به. وبعد إزالة تثبيت Tailscale واستخدام عنوان IP المحلي، عادت جميع التطبيقات إلى العمل.
يمثل ذلك تعافيًا مؤكدًا من المصدر، مع أن المستخدم لم يوثّق علامات عقدة الخروج الدقيقة التي تسببت في السلوك غير الصحيح.
ترتيب أفضل لاستكشاف الأخطاء
- افتح لوحة معلومات ZimaOS مباشرةً باستخدام عنوان IP المحلي؛
- تحقق مما إذا كان أحد منافذ التطبيقات يعمل محليًا؛
- عطّل عقدة الخروج النشطة في Tailscale؛
- أعد محاولة الوصول إلى التطبيق محليًا؛
- بعد ذلك فقط افحص سجلات Docker أو التطبيق إذا ظلت المنافذ غير متاحة.
الأسئلة الشائعة حول عدم توفر الخدمة في جميع التطبيقات
هل أدت إعادة تثبيت التطبيقات إلى حل المشكلة المذكورة في المصدر؟
لا. بدأت التطبيقات بالعمل فقط بعد إزالة حالة توجيه Tailscale المسببة للمشكلة.
هل يمكن لعقدة خروج في Tailscale أن تمنع الوصول إلى الشبكة المحلية؟
نعم. تنص وثائق Tailscale الحالية على أن الوصول إلى الشبكة المحلية يكون معطّلًا افتراضيًا أثناء استخدام عقدة خروج، ما لم يفعّل المستخدم الوصول إلى الشبكة المحلية.
هل تأكد أن Docker نفسه كان معطّلًا؟
لا. يشير الحل المذكور في المصدر إلى مشكلة في التوجيه، لا إلى فشل في خدمة Docker.
