هل Tailscale آمن؟ شرح نموذج الثقة والمخاطر

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

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

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

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

Tailscale عبارة عن VPN شبكي مبني على WireGuard، وهو البروتوكول نفسه الذي يمكنك إعداده يدوياً على VPS يستضيفه بنفسك ويشغّل 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) لديك هي ما يفرضه مزود الهوية. وتكون إجراءات سحب الوصول عند مغادرة شخص ما هي ما ينفذه مزود الهوية. إذا تعرّض حساب لدى مزود الهوية للتصيد، يصبح حساباً في شبكة tailnet، ولا يحتاج المهاجم إلى مهاجمة WireGuard: يكفيه إضافة جهاز ليحصل على كل ما تسمح به سياستك لذلك المستخدم.

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

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

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

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

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

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

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

tailscale up --force-reauth

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

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

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 المنافذ، وزمن الاستجابة إلى أقرب المُرحِّلات. يبيّن ذلك أيّاً من السببين تواجهه. إذا كان النظير متصلاً مباشرة بالفعل وما زال معدل النقل أقل من المتوقع، فالمُرحِّل ليس سبب المشكلة، ويكون عدم تطابق MTU للمسار هو السبب المعتاد وراء بطء WireGuard.

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

توجّه عقدة الخروج كل حركة جهاز ما على الإنترنت العام عبر جهاز آخر في 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 بأكملها. تنطبق بوابة الموافقة نفسها على مسارات الشبكات الفرعية، لذلك تظل الآلة التي تعلن عن نطاق خاص غير فعّالة إلى أن يقبله مسؤول، وهذه هي العقبة الأولى في الإعلان عن شبكة خاصة إلى tailnet من VPS.

والآن نصل إلى مسألة الثقة. تُشفَّر حركة المرور من حاسوبك المحمول إلى عقدة الخروج. ثم تغادر الآلة بصفتها حركة إنترنت عادية، حاملة عنوان 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 هو شبكة mesh الأخرى التي توفر مستوى تحكم قابلاً للاستضافة الذاتية، كما أن تشغيل خادم NetBird على VPS تملكه ينقل قرار التسجيل نفسه إلى أجهزة تملكها.

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

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

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

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

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

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

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

1. شغّل tailscale status على أحد الأجهزة واقرأ قائمة الأقران. الجهاز الذي لا تستطيع تحديد هويته هو بالضبط الحالة التي صُممت موافقة الأجهزة لمنعها.
2. شغّل tailscale lock status لمعرفة ما إذا كان tailnet lock مفعّلاً، ثم قرّر ما إذا كانت كلفة توقيع كل جهاز جديد تستحق ذلك في tailnet الخاص بك.
3. افتح وحدة تحكم الإدارة وسجّل كل جهاز تم تعطيل انتهاء صلاحية مفتاحه، إضافة إلى كل مفتاح مصادقة قابل لإعادة الاستخدام لا يزال موجوداً. كلاهما بيانات اعتماد بلا مؤقت انتهاء.
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 يضيف قواعده الخاصة وقد يعرّض منفذاً كنت تظن أنه مغلق.