ينبغي أن تظل حاوية Tailscale الدائمة هي الجهاز نفسه في وحدة تحكم إدارة Tailscale بعد إعادة تشغيل ZimaOS أو تعديل التطبيق. لكن في سلسلة النقاش المصدرية من سبتمبر 2025، لم يكن ذلك يحدث: فقد كانت كل إعادة تشغيل أو إعادة نشر تنشئ عقدة Tailscale أخرى، رغم أن ملف Compose كان يربط بالفعل /var/lib/tailscale إلى AppData الدائم في ZimaOS.
النتيجة النهائية للمصدر مهمة لأنها تضيق نطاق السبب. قال صاحب المنشور الأصلي إن التخزين الدائم كان مضبوطًا بشكل صحيح بالفعل؛ وكان حذف متغير البيئة الخاص بمفتاح المصادقة المزوَّد باستمرار هو التغيير الوحيد المطلوب. بعد ذلك، استمرت هوية عقدة Tailscale.
يحتاج Tailscale إلى حالة جهاز دائمة
يخزّن Tailscale هوية العقدة والمفاتيح وحالة الاتصال ضمن دليل الحالة الخاص به. في Docker، يُضبط المسار عادةً باستخدام:
TS_STATE_DIR=/var/lib/tailscaleإذا كان هذا الدليل موجودًا داخل نظام ملفات الحاوية القابل للتخلص منه فقط، فإن إعادة إنشاء الحاوية تنشئ هوية Tailscale جديدة.
المصدر كان يربط دليل الحالة بالفعل
تضمّن ملف Compose الأصلي:
/DATA/AppData/tailscale:/var/lib/tailscaleإلى جانب TS_STATE_DIR=/var/lib/tailscale، وشبكة المضيف، NET_ADMIN, NET_RAW، وإتاحة /dev/net/tun. نظريًا، كان من المفترض أن يحافظ ذلك على الحالة.
مفتاح المصادقة مخصص للتسجيل، وليس بالضرورة لكل عملية إعادة تشغيل
كما تضمّن ملف Compose TS_AUTHKEY عند كل بدء للحاوية. أوضح أحد أعضاء المجتمع أن إعادة المصادقة قد تنشئ جهازًا جديدًا عندما لا تتم إعادة استخدام حالة العقدة الحالية كما هو متوقع.
اقترح المجيب استخدام مفتاح مصادقة قابل لإعادة الاستخدام وغير مؤقت عند التشغيل الأول، والانتظار حتى تظهر العقدة في وحدة تحكم الإدارة، ثم إزالة سطر مفتاح المصادقة وإعادة النشر، بحيث تصبح حالة الجهاز المحفوظة هي مصدر الهوية.
أكّد صاحب المنشور الأصلي أن إزالة مفتاح المصادقة أصلحت مشكلته
يوضح الرد النهائي للمصدر أن عناصر الاستمرارية الأخرى كانت موجودة بالفعل، ولم يكن يلزم سوى حذف متغير البيئة الخاص بمفتاح المصادقة. بعد ذلك، ظل اسم الجهاز محفوظًا عبر عمليات إعادة التشغيل.
هذا التأكيد أقوى من تخمين عام بشأن الصلاحيات. في هذا التثبيت تحديدًا، كانت المصادقة المتكررة هي المحفّز العملي.
يوفّر Tailscale الحالي TS_AUTH_ONCE
يمكن لعمليات نشر Tailscale الحديثة باستخدام Docker استعمال TS_AUTH_ONCE=true. عندما تكون الحالة الدائمة موجودة بالفعل، فهذا يمنع الحاوية من فرض تسجيل دخول آخر في كل مرة تبدأ فيها.
راجع معلمات حالة Tailscale الحالية في Docker والمصادقة قبل إعادة استخدام ملف Compose من عام 2025 دون تغيير.
استخدم مجلد مضيف مخصصًا للحالة
يسهّل مجلد مضيف مخصص، مثل مجلد AppData/الحالة الخاص بـ Tailscale، التحقق من بقاء مفاتيح الجهاز بعد إعادة النشر. كما أوصى المجيب في المصدر بالتأكد من أن المجلد قابل للكتابة من قِبل العملية التي تخزن حالة Tailscale.
الأذونات مهمة لأن وحدة التخزين قد تُركَّب بشكل صحيح، بينما تظل العملية غير قادرة على تحديث ملفاتها. في هذه الحالة، قد يتصرف Tailscale كما لو أن الجهاز لا يملك حالة قابلة لإعادة الاستخدام.
تجنب مفاتيح المصادقة المؤقتة لخادم دائم
يدعم Tailscale العقد المؤقتة المصممة لتكون مؤقتة عمدًا. وهذا مفيد لمهام CI قصيرة الأجل أو الحاويات القابلة للتخلص منها، لكنه عكس ما يحتاج إليه خادم ZimaOS دائم.
عند إنشاء بيانات اعتماد، تحقق من توافقها مع دورة الحياة المقصودة. ينبغي للخادم المنزلي المستمر عادةً الاحتفاظ بالهوية نفسها إلى أن تلغيها أو تستبدلها عمدًا.
TS_HOSTNAME لا يحدد هوية الجهاز
استخدمت الحاوية المصدرية TS_HOSTNAME=zimaos . يتحكم هذا الإعداد في الاسم الودود المعروض على شبكة tailnet، لكن الحفاظ على سلسلة اسم المضيف نفسها لا يحافظ على هوية الجهاز التشفيرية. يمكن لجهازين موثَّقين حديثًا محاولة استخدام أسماء متشابهة مع بقائهما عقدتين منفصلتين.
اختبر إعادة التشغيل وإعادة نشر التطبيق
حدثت المشكلة الأصلية بعد إعادة تشغيل نظام التشغيل بالكامل وبعد تعديلات على تطبيق ZimaOS. لذلك، يجب أن ينجح الإصلاح الصحيح في الحالتين:
- إعادة تشغيل حاوية Tailscale؛
- تحرير التطبيق وإعادة نشره دون تغيير وحدة تخزين الحالة؛
- إعادة تشغيل ZimaOS؛
- تحقق من بقاء الجهاز نفسه متصلًا بالإنترنت في وحدة تحكم إدارة Tailscale.
إذا ظهرت نسخة مكررة بعد حدث واحد فقط من هذين الحدثين، فقارن ما يحدث لمجلد الحالة أثناء عملية دورة الحياة المحددة تلك.
الأسئلة الشائعة حول Tailscale المستمر
لماذا أُنشئ جهاز Tailscale جديد بعد كل إعادة تشغيل؟
في الحالة المصدرية، كان مجلد الحالة موجودًا بالفعل، وكانت إعادة استخدام مفتاح المصادقة هي المشكلة العملية المتبقية.
ما المسار الذي يجب أن يبقى محفوظًا؟
المسار الذي يضبطه TS_STATE_DIRعادةً /var/lib/tailscale داخل الحاوية.
هل يجب أن يبقى TS_AUTHKEY في البيئة إلى الأبد؟
ليس بالضرورة. أصلح المستخدم في المصدر مشكلة العقد المكررة بإزالته بعد التسجيل، كما يوفر Tailscale الحالي أيضًا TS_AUTH_ONCE.
هل يحافظ TS_HOSTNAME على هوية العقدة؟
لا. حالة جهاز Tailscale المخزنة هي التي تحافظ على الهوية.
