هل Tailscale آمن؟ نموذج الثقة وما يستطيع الخادم فعله

هل Tailscale آمن؟ الإجابة المختصرة

هل Tailscale آمن؟ بالنسبة إلى الجانب الذي يقلق معظم الناس، نعم. خادم التنسيق الذي يدير tailnet لا يحتفظ بالمفاتيح الخاصة التي تشفّر حركة الشبكة، لذلك لا يمكنه قراءة ما ترسله أجهزتك إلى بعضها. توضّح صفحة الأمان في Tailscale ذلك مباشرة: "لا تغادر المفاتيح الخاصة الجهاز أبداً. جميع حركة الشبكة مشفّرة من طرف إلى طرف، دائماً." لكن السؤال المفيد مختلف. إذا اختُرق خادم التنسيق أو أُلزم بأمر قانوني، فلن يحتاج إلى قراءة حزمك. فهو يحدد المفاتيح العامة التي تثق بها أجهزتك، ولذلك يمكنه تسجيل جهاز لم توافق عليه.

يمكن تلخيص نموذج الثقة بجملة واحدة: تحمي التشفيرات البيانات، بينما يحدد مستوى التحكم أعضاء الشبكة. يذكر كل قسم أدناه جهة واحدة يجب أن تثق بها، ويوضح ما تستطيع هذه الجهة فعله فعلياً، ويعرض وسيلة التحكم التي تحد من ذلك. إذا كان المنتج جديداً عليك، فابدأ بقراءة ما هو Tailscale وكيف تعمل شبكته mesh.

يفصل مستوى التحكم عن مستوى البيانات

Tailscale هو VPN شبكي مبني على WireGuard، وهو البروتوكول نفسه الذي يمكنك إعداده يدوياً على خادم WireGuard مستضاف ذاتياً. ينشئ كل جهاز زوج مفاتيح WireGuard الخاص به محلياً. وتصف مقالة Tailscale حول آلية العمل خادم التنسيق بأنه «صندوق إسقاط مشترك للمفاتيح العامة»، وتقول: «لا يغادر المفتاح الخاص عقدته أبداً، تحت أي ظرف».

مستوى البيانات هو حركة المرور المشفّرة بين أجهزتك. تنتقل هذه الحركة مباشرة من جهاز إلى آخر كلما سمحت الشبكة بذلك. أما مستوى التحكم فيشمل كل ما عدا ذلك: الأجهزة التي تنتمي إلى tailnet، والمفتاح العام المرتبط بكل جهاز، وسياسة الوصول، وإعدادات DNS، وقائمة المرحّلات. تشغّل Tailscale مستوى التحكم كخدمة مستضافة. بينما تشغّل مستوى البيانات على أجهزتك الخاصة.

افصل بين المستويين، وستصبح كل مسألة أمنية هنا قابلة للإجابة. التشفير خاصية لمستوى البيانات. أما العضوية فهي قرار يتخذه مستوى التحكم. ولا يمكن لأي مقدار من التشفير أن يحدد الأجهزة المسموح لها بأن تكون نظراء.

ما الذي يمكن لخادم التحكم المخترق فعله؟

لا يمكنه فك تشفير حركة الشبكة لديك. تُنشأ مفاتيح التشفير على أجهزتك، ولا تُرفع إليها مطلقاً. لذلك لا يوجد ما يمكن الاستيلاء عليه أو تسريبه لفتح النفق. وينطبق ذلك أيضاً على حركة الشبكة المُرحّلة، التي سنغطيها لاحقاً.

يمكنه تسجيل عقدة. عندما أعلنت Tailscale عن tailnet lock، وصفت الشركة الخطر بعباراتها الخاصة: يمكن لخادم ضار أن «يستخدم عقدة أُضيفت سراً لإرسال حركة الشبكة إلى عقدك الحالية أو استقبالها منها»، وعندها «لن يهم أن حركة الشبكة مشفّرة، لأن النظير نفسه سيكون ضاراً». يثق جهازك بنظير لأن مستوى التحكم أخبره بأن هذا المفتاح ينتمي إلى tailnet.

يمكنه تغيير الموارد التي يُسمح لأجهزتك بالوصول إليها. توجد سياسة الوصول في مستوى التحكم، وتُوزَّع على العقد. يذكر المستند التقني لـtailnet lock من Tailscale أن tailnet lock «لا يمنع مستوى تحكم مخترقاً من تعطيل الاتصال في شبكتك، مثل عدم توزيع مفاتيح العقد الجديدة، أو توزيع سياسة للتحكم في الوصول تمنع الوصول إلى جميع العقد».

يرى بيانات الاتصال الوصفية في كلتا الحالتين. تسجل سجلات تدفق الشبكة في Tailscale أحداث فتح الاتصال وإغلاقه لكل اتصال بين جهازين. وتذكر الوثائق أن هذه السجلات «لا تحتوي إطلاقاً على أي معلومات عن عمليات العميل أو محتوى حركة الشبكة». لذلك يمكن لمستوى التحكم معرفة أي جهاز من أجهزتك اتصل بجهاز آخر، ووقت حدوث ذلك. لكنه لا يعرف ما تبادلاه.

يتعلق عنصر واحد فقط من هذه القائمة بالتشفير. أما العناصر الأخرى فتتعلق بمن هو عضو وما تنص عليه السياسة. لذلك فإن عناصر التحكم التي تستحق اهتمامك هي التي تنظم تسجيل العقد.

موفّر الهوية هو جذر الثقة في tailnet

لا يحتفظ Tailscale بقاعدة بيانات كلمات مرور خاصة به. وتوضح وثائقه صراحةً عدم وجود كلمات مرور خاصة بـTailscale، وأن تسجيل الدخول يُفوَّض إلى موفّر هوية (IdP) مثل Apple أو Google أو GitHub أو Microsoft أو Okta أو OneLogin أو موفّر OpenID Connect مخصّص.

تعامل مع ذلك باعتباره بياناً أمنياً، لأنه كذلك. كل من يستطيع تسجيل الدخول إلى حسابك في Google أو Microsoft يستطيع تسجيل الدخول إلى tailnet الخاص بك. وتكون المصادقة متعددة العوامل (MFA) هي ما يفرضه IdP. كما تكون إجراءات سحب الوصول عند مغادرة شخص ما هي ما ينفذه IdP. وحساب IdP الذي يُستولى عليه عبر التصيد هو حساب tailnet، ولا يحتاج المهاجم إلى مهاجمة WireGuard: إذ يمكنه إضافة جهاز، ثم يرث الجهاز كل ما تمنحه سياستك لذلك المستخدم.

يفصل بين حساب هوية مسروق وجهاز عامل داخل tailnet الخاص بك عنصران للتحكم: الموافقة على الجهاز وانتهاء صلاحية المفتاح. ويأتي قفل tailnet كعنصر ثالث، إذ يستهدف مستوى التحكم بدلاً من الحساب.

الموافقة على الأجهزة: لا ينضم أي جهاز حتى يوافق شخص

تصف وثائق Tailscale الموافقة على الأجهزة بأنّها ميزة «تتيح لمسؤولي شبكة Tailscale مراجعة الأجهزة الجديدة والموافقة عليها قبل أن تتمكن من الانضمام إلى شبكة Tailscale». يمكن للمالك أو المسؤول أو مسؤول IT الموافقة على الجهاز. يظهر الجهاز الجديد مع شارة «تحتاج إلى موافقة» في صفحة Machines إلى أن يتخذ أحدهم إجراءً بشأنه.

فعّل هذه الميزة، وستتغير نتيجة سيناريو سرقة الحساب. يسجّل المهاجم الدخول، ويسجّل الجهاز نفسه، ثم ينتظر من دون القدرة على الوصول إلى أي شيء. وتظهر بجانبه شارة في وحدة تحكم الإدارة تخبرك بأن جهازاً لا تتعرف إليه يطلب الانضمام. تظل الأتمتة تعمل، لأنّه يمكنك تحديد auth key على أنّه حاصل على الموافقة مسبقاً عند إنشائه، كما يمكن الموافقة على الأجهزة عبر API.

تُعد auth keys وسيلة أخرى للدخول، لذلك تعامل معها على أنّها بيانات اعتماد. وتحذّر وثائق Tailscale بوضوح من النوع المحفوف بالمخاطر: «كن حذراً جداً عند استخدام المفاتيح القابلة لإعادة الاستخدام! قد تكون هذه المفاتيح خطيرة جداً إذا سُرقت. ومن الأفضل حفظها في منتج لخزائن المفاتيح مصمم لهذا الغرض تحديداً.» اعتباراً من August 2026، يتراوح انتهاء صلاحية المفتاح الموثّق بين 1 و90 يوماً، ويؤدي عدم تحديد مدة الانتهاء إلى استخدام الحد الأقصى البالغ 90 يوماً. فضّل استخدام المفاتيح لمرة واحدة، وحددها على أنّها ephemeral للأجهزة التي تنضم وتغادر باستمرار، واحفظ أي مفتاح قابل لإعادة الاستخدام مشفراً باستخدام Ansible Vault أو في secrets manager بدلاً من وضعه في shell script.

انتهاء صلاحية المفتاح: المؤقت الذي يحد من أثر كل خطأ آخر

تنتهي صلاحية مفاتيح العقد، وهذا ما يحوّل الجهاز المسروق أو المنسي إلى مشكلة مؤقتة. توضح وثائق Tailscale أن «النطاقات الجديدة تُضبط افتراضياً بفترة انتهاء صلاحية مدتها 180 يوماً»، وأنه «إذا لم تحدث إعادة المصادقة، تنتهي صلاحية المفاتيح وتتوقف الاتصالات من نقطة النهاية المعنية وإليها عن العمل». يمكنك إعادة مصادقة الجهاز بنفسك:

tailscale up --force-reauth

تحذّر الوثائق من أن هذا «قد يقطع اتصال tailnet، ولذلك لا ينبغي تنفيذه عن بُعد عبر SSH أو RDP من دون وسيلة بديلة لتسجيل الدخول إذا انقطع الاتصال». نفّذه مع إبقاء الوصول عبر وحدة التحكم مفتوحاً، أو من خلال مسار ثانٍ إلى الجهاز، لأنك على وشك قطع الشبكة التي تستخدمها.

تُعد الخوادم الحالة التي يجري فيها تجاوز هذا الإجراء. فالجهاز الذي يجب أن يعيد المصادقة كل 180 يوماً سينقطع عن tailnet عند الساعة 3am عندما لا يكون أحد يراقبه، لذلك يعطّل المسؤولون انتهاء صلاحية المفتاح عليه. وهذا يزيل المؤقت الذي كان سيقطع في النهاية استخدام مفتاح مسروق. ويُعد الجهاز الموسوم الحل الأفضل للخادم، لأن الوسم يربط الجهاز بالآلة بدلاً من شخص، وبذلك يستمر الجهاز في العمل حتى بعد مغادرة ذلك الشخص الشركة. أياً كان قرارك، احتفظ بقائمة بالأجهزة التي عطّلت عليها انتهاء الصلاحية، لأن مفاتيحها تظل صالحة إلى أن تحذف الجهاز.

Tailnet lock: إخراج خادم التنسيق من سلسلة الثقة

يعالج Tailnet lock مشكلة تسجيل الأجهزة مباشرةً. تشرح وثائق Tailnet lock في Tailscale الآلية كما يلي: «عندما تنضم عقدة جديدة إلى tailnet، يتطلب مفتاح العقدة العام توقيعاً من مفتاح Tailnet Lock. يوزّع خادم التنسيق مفتاح العقدة العام الموقّع على العقد النظيرة». تتحقق أجهزتك الحالية من هذا التوقيع قبل قبول أي نظير، ولذلك يُرفض مفتاح عقدة أنشأه مستوى التحكم من تلقاء نفسه.

tailscale lock status
tailscale lock sign nodekey:1abddef1 tlpub:abcdef12

يُفعّل tailscale lock init الميزة، وتحدد عقد التوقيع في تلك اللحظة. يتطلب Tailscale عقدتي توقيع على الأقل عند التهيئة، ويسمح بحد أقصى يبلغ 20 عقدة في tailnet. بعد ذلك، يحتاج كل جهاز جديد إلى توقيع من إحدى هذه العقد. وهذا يضيف تكلفة تشغيلية فعلية: إضافة هاتف تعني تشغيل أمر على حاسوب محمول.

هذه القيود موثقة، وهي أهم من وصف الميزة:

• إذا فقدت سر التعطيل، فلا توجد إمكانية للاسترداد. تقول الوثائق: «إذا فقدت أسرار التعطيل ولم تقدّم أحدها إلى دعم Tailscale، فلا يمكن استرداد tailnet».
• يوجد مفتاح التوقيع على جهاز تملكه، ولذلك يرث مستوى أمان ذلك الجهاز. وتوضح الوثائق صراحةً: «إذا اختُرق الجهاز، يمكن الحصول على المفتاح».
• لا يمكنك تشغيل آليتي التحكم معاً. يوضح Tailscale أن Tailnet lock والموافقة على الأجهزة متعارضان، ولذلك يعني تفعيل أحدهما التخلي عن الآخر.
• يعتمد ذلك على الثقة عند أول استخدام (TOFU). يمر الإعداد الأولي عبر مستوى التحكم، ولا تنتقل نقطة الثقة إلى شبكتك الخاصة إلا بعد إتمام تلك الخطوة الأولى.

يحمي Tailnet lock العضوية. لكنه لا يحمي التوافر، وتوضح الورقة البيضاء ذلك.

هل يكشف الاتصال المُرحَّل حركة شبكة البيانات الخاصة بي؟

لا. عندما يتعذر على جهازين الوصول إلى بعضهما مباشرة، تنتقل حركة الشبكة إلى خادم DERP ‏(Designated Encrypted Relay for Packets). توضّح وثائق Tailscale هذه الخاصية بوضوح: «بما أن المفاتيح الخاصة في Tailscale لا تغادر الجهاز المحلي الذي أنشأها، يستحيل على خادم DERP فك تشفير حركة بياناتك. يمرّر خادم DERP حركة البيانات المشفّرة مسبقاً من جهاز إلى آخر دون فحصها».

لكن المرحّل يقلل السرعة، كما يطّلع على البيانات الوصفية: نقطتا نهاية مشفّرتان، وتوقيت ما يمر بينهما وحجمه. لمعرفة نوع الاتصال المستخدم فعلياً:

tailscale status
tailscale netcheck

يعرض tailscale status كل نظير على أنه اتصال مباشر، ويطبعه بصيغة direct 203.0.113.10:41641، أو اتصال مُرحَّل، ويطبعه بصيغة relay متبوعاً باسم المرحّل، ثم عدّادات البايتات. إذا ظل أحد النظائر متصلاً عبر مرحّل، فهذا يعني أن الطرفين لم يتمكنا من إنشاء مسار مباشر، وغالباً لأن UDP محظور في مكان ما، أو لأن الطرفين موجودان خلف NAT صارم (ترجمة عناوين الشبكة). يوضّح tailscale netcheck ما إذا كان UDP يعمل من ذلك الجهاز أصلاً، وكيف يعيّن NAT المنافذ، وزمن الاستجابة إلى أقرب المرحّلات. ويبيّن ذلك أي السببين هو المؤثر.

تنقل عقدة الخروج حركة المرور الصادرة، ولا تلغيها

توجّه عقدة الخروج كل حركة المرور العامة لجهاز ما على الإنترنت عبر جهاز آخر في tailnet، باستخدام المسارات الافتراضية 0.0.0.0/0 و::/0. في Linux، يعلن الجهاز الذي يوفّر الخدمة عنها، ثم يختار كل عميل استخدامها:

sudo tailscale set --advertise-exit-node
sudo tailscale set --exit-node=100.101.102.103
sudo tailscale set --exit-node=100.101.102.103 --exit-node-allow-lan-access=true
sudo tailscale set --exit-node=

يجب أن يوافق Owner أو Admin أو Network admin على عقدة الخروج في وحدة تحكم الإدارة، كما يجب أن تمنح سياستك الإذن autogroup:internet قبل أن يتمكن أي عميل من استخدامها. الخطوتان مقصودتان: فلا يمكن لجهاز غير معتمَد أن يصبح بهدوء نقطة الخروج لشبكة tailnet بأكملها.

والآن نصل إلى مسألة الثقة. تُشفَّر حركة المرور من حاسوبك المحمول إلى عقدة الخروج. ثم تغادر الجهاز بوصفها حركة مرور عادية على الإنترنت، حاملة عنوان IP الخاص بذلك الجهاز. لذلك يرى مشغّل عقدة الخروج الوجهات التي تتصل بها، وكذلك موفّر الاستضافة الخاص بذلك الجهاز وشبكته الصاعدة. لقد نقلت نقطة المراقبة بدلاً من إزالتها. يكون ذلك مقايضة جيدة عندما تتحكم في الطرف البعيد، وهذا هو سبب تشغيل عقدة الخروج الخاصة بك على VPS، ويكون خياراً سيئاً عندما لا تتحكم فيه.

السياسة الافتراضية هي شبكة مسطحة

يأتي tailnet جديد بسياسة متساهلة. توضّح وثائق التحكم في الوصول لدى Tailscale أن ملف السياسة الافتراضي «يتيح الاتصال بين جميع الأجهزة داخل tailnet». ويمكن لكل جهاز الوصول إلى أي جهاز آخر عبر أي منفذ. هذه شبكة مسطحة. لقد نقلت الشبكة إلى داخل النفق، وهذا يساعد في مواجهة الجهات الخارجية ولا يحميك من حاسوب محمول يتعرض للاختراق.

شدّد السياسة في ملف سياسة tailnet، الذي يقبل قوائم التحكم في الوصول (ACLs) أو grants الأحدث، وكلاهما مكتوب بصيغة JSON تسمح بالتعليقات:

{
  "acls": [
    {"action": "accept", "src": ["group:eng"], "dst": ["tag:prod:22"]},
    {"action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:internet:*"]}
  ]
}

تتيح هذه السياسة لمجموعة واحدة الوصول إلى SSH على خوادم الإنتاج، وتسمح للأعضاء باستخدام exit node، وتمنع كل ما عدا ذلك من خلال عدم تعريفه. تسرد Tailscale أهداف القواعد المتاحة في كل خطة، لذلك تحقّق من ذلك قبل تصميم السياسة بالاعتماد على tags أو autogroups، وراجع ما تتضمنه الخطة المجانية فعلياً. وبالنسبة إلى جهاز يجب ألا يقبل الاتصالات الواردة مطلقاً، مثل هاتف شخصي، فإن tailscale set --shields-up يحظرها على العميل.

ما الذي يتغير عند استضافة طبقة التحكم بنفسك باستخدام Headscale

‏Headscale هو «تطبيق مفتوح المصدر ومستضاف ذاتياً لخادم التحكم في Tailscale». يحدّد ملف README نطاقه بوضوح: «ينفّذ نطاقاً ضيقاً، وهو شبكة Tailscale واحدة (tailnet)، مناسبة للاستخدام الشخصي أو لمؤسسة صغيرة مفتوحة المصدر». تشمل قائمة ميزاته ACLs وgrants، وموجّهات الشبكات الفرعية، وعقد الخروج، وخادم DERP مضمّناً، وTailscale SSH، وTaildrop. إذا كان هذا النطاق الضيق هو العائق، فإن NetBird هو الحل الشبكي الآخر الذي يوفّر طبقة تحكم قابلة للاستضافة الذاتية، كما أن تشغيل خادم NetBird على VPS تملكه بنفسك ينقل قرار التسجيل نفسه إلى عتاد تملكه.

ما يتغير هو هوية الجهة التي يمكنها تسجيل عقدة خبيثة. مع Headscale، يوجد دليل المفاتيح والسياسة على خادمك. لا يحتفظ أي طرف ثالث بقائمة المفاتيح العامة لأجهزتك، ولا يمكن إجبار أي طرف ثالث على تسليم أحدها أو توقيعها.

ما لا يتغير هو مستوى نقل البيانات. ما زلت تستخدم WireGuard نفسه مع التشفير من طرف إلى طرف نفسه، وآلية الرجوع إلى relay نفسها عندما يتعذر إنشاء مسار مباشر. كما أنك تتولى المهام التي كان Tailscale ينفذها: ضمان التشغيل، وتثبيت التصحيحات، والنسخ الاحتياطية، وتأمين الخادم مادياً. يمنح اختراق مضيف Headscale المهاجم بالضبط الصلاحيات التي يمنحها اختراق خادم تنسيق، وهي تسجيل عقدة وتوزيع السياسة. لا يظهر Tailnet lock في قائمة ميزات Headscale، لذلك لا يتوفر هناك الإجراء التعويضي لهذا الخطر المحدد. إذا كان سؤال الملكية هو العامل الحاسم بالنسبة إليك، فإن استضافة طبقة التحكم بنفسك باستخدام Headscale تشرح خطوات الإعداد.

ما الذي يحميك منه Tailscale

• منافذ الاستماع العامة. لا يمكن الوصول إلى خدمة مرتبطة بعنوان في tailnet من الإنترنت، لذلك لا تراها أدوات الفحص التي تستهدف كل VPS على المنفذ 22. الاستثناء هو ما تفعّله بنفسك، لأن Funnel ينشر خدمة tailnet على الإنترنت العام عن قصد. لذلك من المفيد معرفة الحد الفاصل بين serve وfunnel قبل تشغيل أي من الأمرين. أبقِ جدار حماية الخادم مفعّلاً على أي حال، لأن منفذاً منشوراً من Docker ينشئ قواعده الخاصة ويتجاوز ufw على الواجهة العامة.
• تخمين كلمات المرور لحسابات الدخول المكشوفة. لا يوجد ما يمكن استهدافه بمحاولات متكررة عندما لا يستجيب المنفذ إلا داخل النفق. هذا يوفر حماية أقوى من تطبيق تحديد معدل الطلبات على منفذ مفتوح، مع أن تشغيل fail2ban على Ubuntu 24.04 يظل مفيداً على أي خدمة يجب أن تبقى عامة.
• الشبكات غير الموثوقة الواقعة في مسار الاتصال. تكون حركة الشبكة بين أجهزتك مشفّرة من طرف إلى طرف عبر شبكة مقهى أو شبكة LAN مشتركة لدى مزود الخدمة، وتبقى مشفّرة عند تمريرها عبر relay.
• توزيع المفاتيح يدوياً. كل نظير تضيفه يدوياً إلى إعداد WireGuard يمثل احتمالاً لإعادة استخدام عنوان أو لصق المفتاح الخطأ. تتولى الشبكة mesh إدارة هذه التفاصيل نيابةً عنك، وهذا هو معظم الفرق العملي في WireGuard مقارنةً بـ Tailscale.

ما الذي لا يحميك منه Tailscale

• نقطة نهاية مخترقة. تثق tailnet بالأجهزة. تحصل البرمجيات الخبيثة على حاسوب محمول معتمد على النفق، وعناوين tailnet، وكل ما تمنحه سياسة الوصول لذلك المستخدم. هذه أكبر فجوة، ولا يمكن لأي VPN سدّها.
• مسؤول خبيث أو مهمل. يستطيع كل من يمكنه تعديل ملف السياسة منح نفسه صلاحية الوصول إلى أي مورد، كما يستطيع كل من يسيطر على حساب هوية Owner فعل الشيء نفسه. راجع تغييرات السياسة بالطريقة نفسها التي تراجع بها الشيفرة.
• تحليل حركة الشبكة. يرى مزود خدمة الإنترنت (ISP) لديك تدفق UDP مشفراً إلى نقطة نهاية، إضافة إلى التوقيت والحجم. وتعرف سجلات التدفق في Tailscale أيّ أقران تواصلوا ومتى. لا يرى أي منهما المحتوى، لكن وقوع الاتصال نفسه ليس مخفياً، لذلك اقرأ كيف يختلف Tor عن VPN قبل اختيار أداة لهذه المهمة.
• جهاز فقدت السيطرة عليه بالفعل. يُعد انتهاء صلاحية المفتاح إجراءً احتياطياً بطيئاً، مع مدة افتراضية تبلغ 180 يوماً. أما إزالة الجهاز من وحدة تحكم الإدارة فهي الإجراء السريع، لذلك اعرف موضع هذا الزر قبل أن تحتاج إليه.

تحقّق من tailnet الخاص بك

1. شغّل tailscale status على أحد الأجهزة، واقرأ قائمة الأجهزة النظيرة. الجهاز الذي لا تستطيع تحديده بالاسم هو بالضبط الحالة التي صُممت الموافقة على الأجهزة لمنعها.
2. شغّل tailscale lock status لمعرفة ما إذا كان tailnet lock مفعّلاً، ثم قرّر ما إذا كانت كلفة توقيع كل جهاز جديد تستحق ذلك بالنسبة إلى tailnet الخاص بك.
3. افتح وحدة تحكم الإدارة، وسجّل كل جهاز عطِّل انتهاء مفتاحه، إضافة إلى كل auth key قابل لإعادة الاستخدام وما زال موجوداً. كلاهما بيانات اعتماد بلا مؤقت.
4. اقرأ ملف السياسة. إذا كان لا يزال بالإعداد الافتراضي، فيمكن لكل جهاز الوصول إلى كل جهاز آخر عبر كل منفذ، وسيتمكن حاسوب محمول مصاب من الوصول إليها جميعاً.

تحافظ Tailscale على سمعتها في مستوى البيانات، حيث لا يتيح التصميم للمشغّل أي وسيلة لقراءة حركة الشبكة الخاصة بك. تعامل مع هذا الادعاء وفقاً لما توثّقه الشركة المصنّعة، ثم راجع الأجزاء التي تقع ضمن مسؤوليتك: حسابات الهوية، وإعداد الموافقة، وقائمة انتهاء الصلاحية، وملف السياسة. تذكر صفحة أمان Tailscale حصولها على شهادة SOC 2 Type II واستمرار العمل الأمني مع Latacora، وهذا دليل على إجراءاتهم، وليس بياناً عن إعداداتك.

FAQ

هل يستطيع Tailscale قراءة حركة الشبكة الخاصة بي؟

لا. تُشفَّر حركة الشبكة باستخدام مفاتيح WireGuard التي تُنشأ على أجهزتك، وتذكر صفحة الأمان في Tailscale أن «المفاتيح الخاصة لا تغادر الجهاز. وكل حركة الشبكة مشفَّرة من الطرف إلى الطرف دائماً». ينطبق ذلك أيضاً على الاتصالات التي تنتقل احتياطياً عبر مرحّل DERP، لأن المرحّل «يعيد توجيه حركة مشفَّرة مسبقاً من جهاز إلى آخر دون تحليلها»، ولا يحتفظ بأي مفتاح يتيح له فك تشفيرها. ما تراه بنية Tailscale هو البيانات الوصفية: الأجهزة الموجودة، وأيها اتصل بأي جهاز، ومتى حدث ذلك.

ما الذي يمكن لخادم تنسيق Tailscale مخترق أن يفعله فعلياً؟

يمكنه تسجيل عقدة. يصف إعلان tailnet lock الصادر عن Tailscale نفسها خطر إضافة عقدة سراً يمكنها «إرسال حركة الشبكة إلى عقدك الحالية أو استقبالها منها»، ولا يفيد التشفير هنا «لأن النظير نفسه قد يكون خبيثاً». ويمكن لطبقة التحكم المخترقة أيضاً توزيع سياسة تغيّر ما يمكن لأجهزتك الوصول إليه. وتذكر الورقة البيضاء الخاصة بـtailnet lock أن الخادم قد يقطع الاتصال عبر الامتناع عن توزيع مفاتيح العقد الجديدة. لكنه لا يستطيع فك تشفير حركة الشبكة بين أجهزتك الحالية، لأنه لم يحتفظ قط بمفاتيحها الخاصة.

هل تخفي عقدة الخروج تصفحي عن مزود خدمة الإنترنت لدي؟

تخفي الوجهات عن الشبكة التي تتصل منها، بما في ذلك مزود خدمة الإنترنت في منزلك أو المقهى، لأن كل شيء يغادر جهازك كحركة مشفَّرة موجّهة إلى عقدة الخروج. لكنها لا تجعلك مجهول الهوية. بدلاً من ذلك، ترى عقدة الخروج تلك الوجهات، وكذلك مزود الاستضافة والشبكة الوسيطة الخاصة بها، بينما ترى المواقع التي تزورها عنوان IP الخاص بعقدة الخروج. لقد اخترت مراقباً مختلفاً، لذلك اختر مراقباً تثق به فعلاً.

هل Headscale أكثر أماناً من خادم تنسيق Tailscale؟

إنه قرار ثقة مختلف، وليس خياراً أكثر أماناً بالضرورة. باستخدام Headscale، تحتفظ بدليل المفاتيح وبالسياسة، لذلك لا يستطيع طرف خارجي إجبار النظام على تسجيل جهاز في tailnet الخاص بك. لكنك تتحمل أيضاً مسؤولية تشغيل ذلك الخادم: تثبيت التحديثات، وضمان التوافر، والنسخ الاحتياطية، وأمان المضيف نفسه. يمنح مضيف Headscale مخترق المهاجمَ القدرة نفسها على التسجيل التي يمنحها خادم تنسيق مخترق. كما أن tailnet lock ليس مدرجاً ضمن ميزات Headscale، لذلك احمِ ذلك المضيف وفقاً لذلك.

هل ما زلت أحتاج إلى جدار ناري على VPS موجود في tailnet الخاص بي؟

نعم. تظل واجهة الشبكة العامة موجودة، وتبقى أي خدمة مرتبطة بـ0.0.0.0 قابلة للوصول من الإنترنت، سواء كان Tailscale قيد التشغيل أم لا. اربط الخدمات بعنوان tailnet، واحتفظ بسياسة منع افتراضية على الواجهة العامة، وتحقق من منافذ الحاويات المنشورة، لأن Docker يضيف قواعده الخاصة وقد يعرّض منفذاً ظننته مغلقاً.