The normal Tailscale Docker app is convenient, but a containerized VPN does not always behave like Tailscale installed directly on a Linux host. The source author wanted a first-class host daemon with a real TUN device so ZimaOS itself could act as a subnet router or exit node and mount resources reachable through the tailnet.
تطبيق Tailscale العادي عبر Docker مريح، لكن شبكة VPN داخل حاوية لا تتصرف دائمًا مثل Tailscale المثبّت مباشرةً على مضيف Linux. أراد مؤلف المصدر برنامج خفيًّا أصليًا على المضيف مع جهاز TUN حقيقي، بحيث يعمل ZimaOS نفسه كموجّه لشبكة فرعية أو عقدة خروج، ويتيح تركيب الموارد التي يمكن الوصول إليها عبر شبكة tailnet. لأن ZimaOS يستخدم جذرًا للقراءة فقط بأسلوب الأجهزة المخصصة ولا يوفّر apt install tailscale مسار، وعبّأ المؤلف Tailscale باعتباره systemd-sysext
امتداد. هذا مشروع مجتمعي، وليس حزمة Tailscale مدعومة من IceWhale، لذا ينبغي تصنيف أوامره ودورة حياته وفقًا لذلك.
لماذا تشغيل Tailscale على المضيف؟ وصف مؤلف المصدر شبكات Docker في مساحة المستخدم بأنها كافية للاتصال العادي، لكنها معقدة بالنسبة إلى التوجيه على مستوى المضيف. ويمكن لبرنامج أصلي استخدام جهاز TUN في النواة مباشرةً والتكامل معsystemctl
، وإعادة توجيه IP، ومسارات الشبكات الفرعية، وسلوك عقدة الخروج.
لماذا يناسب systemd-sysext نظام ZimaOS يضيف systemd-sysext ملفات إضافية إلى مواقع مثل /usr /DATA/AppData/tailscale/.
وقت التشغيل من دون تعديل صورة الأساس غير القابلة للتغيير. حاكى المؤلف تخطيط Buildroot الخاص بـ Tailscale في المنبع وخزّن حالة المصادقة الدائمة ضمن
يوفّر المشروع نصًا لتثبيت المضيف يوفّر مسار البدء السريع في مستودع المجتمع استنساخ المشروع، ثم تشغيل برنامج التثبيت باستخدام sudo، وبعد ذلك المصادقة عبرtailscale up
وبما أن هذا كود من جهة خارجية يعمل بصلاحيات الجذر، راجع المستودع وسجل الإصدارات قبل التنفيذ.
اقرأ مشروع sysext الحالي وملاحظات التثبيت التي تتم صيانتها بدلًا من نسخ إصدار قديم من المنتدى.
يحفظ المشروع حالة العقدة خارج الامتداد القابل للتخلص منه /DATA/AppData/tailscale/ويتيح ذلك بقاء هوية Tailscale عند إعادة إنشاء أو استبدال .raw ملف sysext.
اكتُشفت مشكلة حقيقية في إعادة التشغيل بعد الإصدار الأولي
أبلغ أحد المستخدمين عن أن tailscaled لم يبدأ بعد إعادة التشغيل. أعاد مؤلف المشروع إنتاج المشكلة وشرح هذا الت race: multi-user.target حلّ تبعيات الخدمة قبل systemd-sysext.service كان قد دمج الامتداد، لذا لم تكن وحدة الخدمة موجودة عند إنشاء systemd للهدف.
أضاف الإصدار v1.0.1 مؤقّت مراقبة
أصلح المؤلف مشكلة الت race عند الإقلاع باستخدام مؤقّت صغير وخدمة oneshot مخزّنة في الجذر الدائم ضمن /etc/systemd/system/ويعمل بعد الإقلاع بوقت قصير ويبدأ تشغيل tailscaled بمجرد وجود طبقة تراكب sysext.
أفاد مؤلف المصدر بأنه تحقّق من الإصلاح بعد إعادة تشغيل فعلية.
كانت إعدادات إعادة توجيه IP مسألة منفصلة تتعلق بالاستمرارية
سأل الموضوع أيضًا عمّا إذا كانت إعدادات sysctl الخاصة بموجّه الشبكة الفرعية تستمر بعد إعادة التشغيل. وأوضح المؤلف أن ZimaOS يحفظ /etc من خلال طبقة تراكب مدعومة بتخزين دائم، لذا تبقى الإعدادات ضمن /etc/sysctl.d/ يستمر ويُعاد تطبيقه.
إعدادات إعادة التوجيه هذه مطلوبة لاستخدام موجّه الشبكة الفرعية أو عقدة الخروج، وليست مطلوبة لعميل Tailscale عادي.
تغيّر قيد IPv6 مع نواة ZimaOS
وثّقت وحدة مايو 2026 الأصلية خيارات نواة توجيه سياسات IPv6 المفقودة في ZimaOS 1.6.1/النواة 6.12.25، ما تسبب في تعطيل Tailscale لـ IPv6 النفقي.
بحلول 30 يوليو، حدّث المؤلف الموضوع لأن نواة IceWhale الأحدث وفّرت إمكانات IPv6 المطلوبة. ويتحقق مستودع المشروع الحالي من عمل IPv6 في tailnet على ZimaOS 1.7.0/النواة 6.18.9.
أعِد تشغيل المُثبّت بعد تحديثات ZimaOS
صُمم المشروع لإعادة بناء sysext من الملفات الثنائية الساكنة الرسمية لـ Tailscale، مع الاحتفاظ بحالة المصادقة بشكل منفصل. ويوصي المستودع حاليًا بإعادة تشغيل المُثبّت بعد ترقية ZimaOS.
تعامل مع وحدة مجتمعية ذات صلاحيات الجذر باعتبارها برنامجًا للنظام
تعمل هذه الوحدة مباشرة على مضيف NAS، ويملك مُثبّتها صلاحيات مرتفعة. راجع المصدر وقيَم التجزئة وسلوك التحديث وإلغاء التثبيت قبل نشرها على نظام يحتوي على بيانات مهمة.
أُعيد التحقق من المشروع على ZimaOS 1.7.0
يفيد المستودع الحالي باختبار شامل ناجح على ZimaOS 1.7.0 مع النواة 6.18.9، بما في ذلك استمرار الإعداد بعد إعادة التشغيل وعمل IPv6 في tailnet. وهذا دليل أقوى من المنشور الأصلي في مايو 2026، الذي طُوّر باستخدام ZimaOS 1.6.1.
يعالج Docker وsysext الأصلي احتياجات مختلفة
إذا كنت تحتاج فقط إلى إتاحة تطبيقات محددة للوصول عبر Tailscale، فقد يكون مسار Docker أبسط ويُبقي تعديلات المضيف في حدها الأدنى. ويُعد مسار sysext جذابًا عندما يحتاج مضيف ZimaOS نفسه إلى تركيب موارد tailnet، أو الإعلان عن شبكات LAN الفرعية، أو العمل كعقدة خروج.
لا تستبدل تثبيت Docker العامل لمجرد توفر النهج الأصلي. اختر بناءً على ما إذا كنت تحتاج فعلًا إلى التوجيه على مستوى المضيف.
إلغاء التثبيت والإزالة الكاملة عمليتان مختلفتان
يفصل المشروع المجتمعي عمدًا بين إزالة sysext وحذف حالة Tailscale. إذ يمكن لمسار إلغاء التثبيت المعتاد الاحتفاظ ببيانات العقدة الدائمة، بينما تؤدي الإزالة الكاملة إلى حذف دليل الحالة أيضًا. ويهم هذا الفرق إذا كنت تنوي إعادة التثبيت دون إنشاء هوية أخرى لشبكة tailnet.
لا يزال مراقب الإقلاع جزءًا من التصميم
تشير وثائق المشروع الحالية إلى أن مراقب الإقلاع لا يزال مطلوبًا حتى على ZimaOS 1.7.0، لأن وحدة الخدمة داخل sysext قد تظل تفوّت التجميع الأولي لهدف systemd. أصلحت النواة الأحدث إمكانات IPv6، لكنها لم تصلح مشكلة الترتيب الزمني لخدمة sysext.
الأسئلة الشائعة حول Tailscale الأصلي
هل هذه حزمة Tailscale رسمية من IceWhale؟
لا. إنه مشروع مجتمعي لـ systemd-sysext.
لماذا يُستخدم بدلًا من Docker؟
يستهدف المشروع تشغيل TUN على مستوى المضيف، وموجّه الشبكة الفرعية، وعقدة الخروج، والتكامل المعتاد مع systemd.
هل تم إصلاح مشكلة بدء التشغيل بعد إعادة التشغيل؟
أعاد مؤلف المشروع إنتاج المشكلة وأصدر إصلاحًا يعتمد على مراقب في الإصدار v1.0.1.
هل ما زال لدى IPv6 القيد نفسه في الإصدار 1.6.1؟
يفيد المشروع بأن نواة 6.18.9 الأحدث المستخدمة في ZimaOS 1.7.0 توفر دعم توجيه السياسات المطلوب لـ IPv6.
