قد تظهر حاوية Tailscale على أنها متصلة من دون أن تعمل كموجّه للشبكة الفرعية. في هذا النقاش على ZimaOS في أبريل 2026، كان Tailscale يعمل في Docker باستخدام شبكة المضيف والوضع المميّز و /dev/net/tun كانت موصّلة، ومع ذلك أبلغت وحدة تحكم إدارة Tailscale بأن الجهاز لا يعرِض أي مسارات. كان Navidrome يعمل على الشبكة المحلية، لكن تعذّر الوصول إليه عن بُعد عبر tailnet.
لم ينتهِ النقاش بحل مؤكد من صاحب المنشور الأصلي. بدلًا من ذلك، شارك عضو آخر في المجتمع إعدادًا عمليًا لحاوية BigBear Tailscale أعلنت عن شبكة محلية فرعية بنجاح في بيئة ZimaOS الخاصة به. ويفيد هذا الإعداد كمرجع لاستكشاف الأخطاء وإصلاحها، لكنه لا يُعد ضمانًا مدعومًا من IceWhale لكل حزمة تطبيقات Tailscale.
لا يعني الاتصال بـ Tailscale الإعلان عن مسارات الشبكات الفرعية
كان الإعداد الأصلي قد أتمّ بالفعل مصادقة الجهاز. وكانت المشكلة تتعلق بالتوجيه تحديدًا: إذ أظهرت السجلات قائمة مسارات فارغة، ولم تعرض وحدة تحكم إدارة Tailscale مسار شبكة فرعية للموافقة عليه.
هذا الفرق مهم لأن عقدة Tailscale العادية لا تنضم إلا إلى tailnet. أما موجّه الشبكة الفرعية، فتقع على عاتقه مسؤوليات إضافية: إذ يجب أن يعلن عن بادئة شبكة محلية واحدة أو أكثر، وأن يستوفي متطلبات التوجيه في نظام التشغيل اللازمة لإعادة توجيه الحركة بين tailnet وتلك الشبكة المحلية.
تصف وثائق Tailscale الحالية موجّهات الشبكات الفرعية بأنها بوابات تُعلن عن الشبكات الخاصة لأجهزة tailnet. كما تتطلب تفعيل إعادة توجيه عناوين IP على Linux والموافقة على المسار في وحدة تحكم إدارة Tailscale، ما لم تتولَّ المعتمدون تلقائيًا تتولى السياسة الموافقة تلقائيًا.
توثيق موجّه الشبكات الفرعية في Tailscale
المرجع المجتمعي العملي استخدم TS_ROUTES
استخدم رد TomasSzwed حاوية BigBear Tailscale، وجرى فيه إعداد الشبكة الفرعية من خلال متغيرات البيئة بدلًا من الاعتماد على أمر يدوي يُنفّذ مرة واحدة بعد بدء التشغيل. وشملت الأجزاء المهمة من ذلك المرجع ما يلي:
-
network_mode: host; - الوضع المميّز؛
-
/dev/net/tunالموصّل داخل الحاوية؛ -
TS_USERSPACE=false; -
TS_ROUTES=192.168.2.0/24للشبكة المحلية التي يجري الإعلان عنها؛ -
TS_EXTRA_ARGS=--accept-routesفي إعداد ذلك المستخدم؛ - حالة Tailscale الدائمة ضمن
/var/lib/tailscale.
استخدم بادئة الشبكة المحلية الصحيحة لشبكتك
المثال العملي الذي أُعلن عنه 192.168.2.0/24. ولا تكون هذه القيمة منطقية إلا لشبكة محلية تستخدم تلك الشبكة الفرعية. قد تستخدم شبكة منزلية أخرى 192.168.1.0/24, 10.0.0.0/24، أو بادئة خاصة أخرى.
قد يؤدي الإعلان عن الشبكة الفرعية الخاطئة إلى إنشاء عقدة Tailscale سليمة، لكنها لا تزال غير قادرة على توجيه الوصول إلى خدمات ZimaOS المقصودة. حدّد بادئة الشبكة المحلية الفعلية قبل تعيين TS_ROUTES أو ما يعادله --advertise-routes الخيار.
لا تزال المسارات المُعلنة بحاجة إلى التفعيل
تفصل إرشادات Tailscale الحالية بين إعلان المسار والموافقة عليه. بمجرد أن يعلن موجّه الشبكة الفرعية عن مسار، يجب تفعيل المسار في وحدة تحكم مسؤول Tailscale، ما لم تعتمد سياسة tailnet عليه تلقائيًا.
إذا قالت وحدة تحكم المسؤول إن الجهاز لا يعرِض أي مسارات على الإطلاق، فركّز أولًا على إعداد إعلان المسارات في الحاوية. وإذا ظهر المسار لكن ظلت حركة المرور لا تعمل، فراجع الموافقة على المسار، وسياسة التحكم في الوصول، وإعادة التوجيه، والخدمة الوجهة نفسها.
تغييرات شبكة Docker تؤثر في المسارات التي يمكن للحاوية توجيهها
استخدم صاحب المنشور الأصلي شبكة المضيف، وقام بتركيب جهاز TUN. وفعل المرجع الذي شاركه المجتمع الشيء نفسه. تدعم وثائق Tailscale الحالية أيضًا تشغيل Tailscale داخل Docker، لكن شبكة Docker وتوجيه Tailscale طبقتان منفصلتان، ويجب ضبط كلتيهما بصورة صحيحة.
وثائق Tailscale الخاصة بـ Docker
لا تفترض أن تطبيقي Tailscale في متجر تطبيقات ZimaOS يستخدمان تعريفات حاويات متطابقة. فقد لاحظ صاحب المنشور الأصلي تحديدًا أن المثال المشترك يستخدم حزمة Tailscale من BigBear، بينما كان التثبيت الحالي لديه يستخدم إدخال Tailscale الآخر.
ماذا يعني هذا بالنسبة إلى Navidrome والخدمات المحلية الأخرى
كان الهدف في موضوع المصدر هو الوصول إلى Navidrome من جهاز iPhone دون إعادة توجيه المنافذ العامة. إذا كان Navidrome متاحًا بالفعل على شبكة LAN المحلية، فيمكن لموجّه شبكات فرعية يعمل بصورة صحيحة أن يجعل عنوان LAN هذا متاحًا من أجهزة tailnet المصرّح لها.
ومع ذلك، لا يؤكد الموضوع أن صاحب المنشور الأصلي أكمل التبديل إلى إعداد BigBear أو تمكن بنجاح من الوصول إلى Navidrome بعد ذلك. لذلك توثّق الصفحة مرجعًا عمليًا من المجتمع ونموذجًا للتشخيص، لا حلًا مؤكدًا لذلك التثبيت بعينه.
الأسئلة الشائعة حول توجيه الشبكات الفرعية في Tailscale على ZimaOS
لماذا يقول Tailscale إنه متصل لكنه لا يعرض أي مسارات للشبكات الفرعية؟
الانضمام إلى شبكة tailnet وإعلان مسار لشبكة LAN عمليتان مختلفتان. في الحالة المصدر، نجحت المصادقة، لكن ظلت قائمة المسارات فارغة.
هل يمكن لـ Tailscale داخل Docker أن يعمل كموجّه للشبكة الفرعية على ZimaOS؟
أفاد أحد أعضاء المجتمع بأن ذلك نجح في إعداد ZimaOS الخاص به، وشارك إعدادًا لـ Tailscale من BigBear. يدعم Tailscale نفسه أيضًا توجيه الشبكات الفرعية وعمليات النشر عبر Docker، لكن يظل إعداد تطبيق ZimaOS الدقيق مهمًا.
هل أحتاج إلى الموافقة على المسار في Tailscale؟
وفقًا لسلوك Tailscale الحالي، تحتاج مسارات الشبكات الفرعية المُعلنة عادةً إلى الموافقة في وحدة تحكم المسؤول، ما لم المعتمدون تلقائيًا تتعامل معها السياسة تلقائيًا.
هل أنسخ 192.168.2.0/24 من لقطة الشاشة؟
لا. استخدم الشبكة الفرعية الفعلية لشبكة LAN التي تريد إتاحة الوصول إليها. القيمة الظاهرة في لقطة الشاشة تخص شبكة عضو آخر في المجتمع.
