ما هو Tailscale وكيف يعمل؟

ما هو Tailscale؟

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

هذا الفصل هو جوهر التصميم بالكامل. مستوى البيانات نظير إلى نظير ومشفّر بين العقد. أما مستوى التحكم فهو خدمة يديرها Tailscale نيابةً عنك. تنشأ كل الأسئلة المهمة حول Tailscale، بما فيها الأسئلة الحساسة المتعلقة بالثقة، من هاتين الحقيقتين. إذا كنت قد أنشأت بالفعل شبكة VPN باستخدام WireGuard يدوياً على VPS، فإن Tailscale يوفّر النفق نفسه، مع تولّي توزيع المفاتيح واجتياز الجدار الناري نيابةً عنك.

كيف يعمل Tailscale؟

تُسمّى شبكتك الخاصة من العقد tailnet. تحدث أربعة أمور عندما ينضم جهاز إليها.

1. تبدأ خدمة tailscaled، وتُنشئ زوج مفاتيح WireGuard، وتحفظ حالتها في /var/lib/tailscale/tailscaled.state. يبقى المفتاح الخاص على ذلك الجهاز. وتوضح Tailscale ذلك بصياغة مباشرة: «المفتاح الخاص لا يغادر عقدته أبداً».
2. تسجّل العقدة الدخول إلى خادم التنسيق، وترفع مفتاحها العام، بالإضافة إلى العناوين التي تعتقد أنّه يمكن الوصول إليها عبرها. وتصف Tailscale هذا الخادم بأنه «صندوق إسقاط مشترك للمفاتيح العامة».
3. يرسل خادم التنسيق خريطة شبكة تتضمن المفتاح العام، وعنوان tailnet، واسم الجهاز، ونقاط النهاية المحتملة لكل عقدة مسموح لهذه العقدة بالوصول إليها.
4. تحاول كل زوج من العقد بعد ذلك إنشاء نفق WireGuard مباشر بينهما. وعندما يفشل ذلك، تمرر الحزم عبر relay بدلاً من ذلك.

تحصل كل عقدة على عنوان ثابت من 100.64.0.0/10، وهو نطاق carrier-grade NAT الممتد من 100.64.0.0 إلى 100.127.255.255. تستخدم Tailscale هذا النطاق لأنّه محجوز لبنية مزوّدي الخدمة، ولذلك نادراً ما يتعارض مع العناوين الخاصة التي تستخدمها خوادمك مسبقاً. يظهر النفق على Linux كواجهة باسم tailscale0.

يعمل تنفيذ WireGuard داخل tailscaled في userspace، وليس في وحدة kernel. لذلك يبدأ Tailscale في بيئات افتراضية للحاويات تتعذر فيها sudo modprobe wireguard مع Operation not supported. ويعني ذلك أيضاً أنّ الحد الأقصى لمعدل النقل على جهاز معيّن يكون أقل من WireGuard في kernel. وهذا أحد المقايضات التي يتناولها Tailscale مقارنةً بـ WireGuard العادي.

يخبرك أمران بموقعك الحالي.

tailscale ip -4
tailscale status

يطبع tailscale status سطراً واحداً لكل عقدة، ويكون العمود الأخير هو المهم.

100.101.102.103  web-1      you@  linux  -
100.101.102.104  db-1       you@  linux  active; direct 198.51.100.24:41641
100.101.102.105  ci-runner  you@  linux  active; relay "fra"

يعني direct متبوعاً بعنوان ومنفذ أنّ الجهازين وجدا مساراً إلى بعضهما وأنّ حركة الشبكة تنتقل بينهما مباشرةً. ويعني relay "fra" أنّها تمر عبر relay تابع لـTailscale في Frankfurt. ويعني - عدم وجود جلسة نشطة مع تلك العقدة حالياً، وهذا أمر طبيعي.

ما الذي يستطيع خادم التنسيق رؤيته وما لا يستطيع رؤيته

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

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

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

كيف يتصل خادمان خلف جدارَي حماية مختلفين مباشرةً

تتيح NAT (ترجمة عناوين الشبكة) لعدة أجهزة مشاركة عنوان عام واحد. يكون لدى VPS عادةً عنوان عام خاص به، لكن الأجهزة الأخرى التي تريد ضمها إلى tailnet لا تملك غالباً عنواناً عاماً: مثل خادم منزلي، أو build runner على شبكة مكتب، أو جهاز خلف جدار حماية لدى مزود لا يمكنك تعديل إعداداته.

يبحث Tailscale عن مسار باستخدام تقنيات مبنية على معياري STUN (أدوات اجتياز الجلسات لـ NAT) وICE. يرسل كل عقدة حزمة UDP صغيرة إلى خادم STUN، ويتعرف على العنوان العام والمنفذ اللذين خصصهما الموجّه لذلك المقبس. ترسل العقدتان هذه العناوين المرشحة إلى خادم التنسيق، الذي يمررها إلى الطرف الآخر. ثم تبدأ العقدتان بإرسال الحزم إلى بعضهما في الوقت نفسه. يرى كل موجّه حزمة صادرة أولاً، فينشئ تعييناً ويقبل الرد الوارد من العنوان نفسه. لذلك لا يحتاج أي من الطرفين إلى قاعدة واردة في جدار الحماية.

المنافذ محددة. تستخدم أنفاق WireGuard المباشرة UDP مع منفذ مصدر تكون قيمته الافتراضية 41641. يعمل STUN عبر UDP على المنفذ 3478 للوصول إلى خوادم الترحيل الخاصة بـ Tailscale. يستخدم اتصال التحكم وأي بيانات مُرحّلة HTTPS عبر TCP على المنفذ 443. في معظم الحالات لا تفتح أي منفذ وارد، لكن في الشبكات التي تستخدم NAT معقداً، يزيد السماح بالاتصالات الواردة عبر UDP على المنفذ 41641 من احتمال إنشاء اتصال مباشر.

tailscale netcheck

اقرأ سطرين من ذلك التقرير. يعني UDP: true أن UDP يغادر الجهاز على الإطلاق، ويعني UDP: false أن كل اتصال من هذه العقدة سيُرحّل. ويعني MappingVariesByDestIP: true أن الموجّه يخصص منفذاً عاماً مختلفاً لكل وجهة، لذلك لا يمكن تطبيق توقع العنوان المذكور أعلاه، وتبقى هذه العقد عادةً متصلة عبر الترحيل.

عندما يستخدم Tailscale مرحّل DERP بدلاً من المسار المباشر

DERP، أي مرحّل مخصص ومشفّر للحزم، هو الخيار الاحتياطي. يشغّل Tailscale مرحّلات في مناطق كثيرة يمكن الوصول إليها عبر TCP 443، وترسل العقدة التي لا تستطيع إنشاء مسار مباشر حزم WireGuard الخاصة بها عبر أحد هذه المرحّلات.

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

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

tailscale ping db-1

تعود الردود الأولى مع via DERP(fra)، ثم يعرض سطر لاحق شيئاً مثل via 198.51.100.24:41641. يشير هذا التغيير إلى الترقية إلى نفق مباشر. إذا لم يتغير أبداً، فنفّذ tailscale netcheck على الطرفين. يظل المسار المرحّل صالحاً للعمل. لكنه يضيف زمن انتقال، لأن كل حزمة تسلك مساراً التفافياً عبر جهاز ثالث.

ضم خادم VPS إلى tailnet

يغطي سكربت التثبيت Ubuntu وDebian.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

يطبع sudo tailscale up عنوان URL. افتحه وسجّل الدخول، وستظهر العقدة في وحدة تحكم الإدارة. ثم تأكد من عودة daemon للعمل بعد إعادة التشغيل، لأن هذه هي الخطوة التي يتجاوزها كثيرون.

sudo systemctl is-enabled tailscaled
tailscale status

من المفترض أن يطبع is-enabled القيمة enabled، وأن يعرض tailscale status العقدة الجديدة مع عنوانها 100.x. إذا أنشأت الخادم باستخدام سكربت، فلن يفيدك عنوان URL تفاعلي. أنشئ auth key في وحدة تحكم الإدارة ومرّره مع tag يحدد نوع هذا الجهاز.

sudo tailscale up --auth-key=tskey-auth-REPLACE-ME --advertise-tags=tag:server

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

يوجد إعدادان مهمان عند إدارة مجموعة من الأجهزة. تنتهي صلاحية مفاتيح العقد بعد 180 يوماً افتراضياً (اعتباراً من August 2026)، وعند انتهاء صلاحية المفتاح «تتوقف الاتصالات من نقطة النهاية المحددة وإليها عن العمل» حتى يسجّل أحد الدخول مجدداً. لذلك افتح صف الجهاز في وحدة تحكم الإدارة واختر Disable Key Expiry على الخوادم غير المراقبة. يوفّر MagicDNS، المفعّل افتراضياً في tailnets التي أُنشئت في 20 October 2022 أو بعده، اسماً لكل عقدة مثل db-1.yak-bebop.ts.net، ويُحل هذا الاسم بواسطة stub resolver على 100.100.100.100. استخدم الأسماء بدلاً من العناوين، لأن العقدة التي يُعاد بناؤها تحصل على عنوان جديد وتحتفظ باسمها.

إذا فشل التثبيت نفسه عند استخدام apt أو المستودع، فتغطي أخطاء تثبيت Tailscale الشائعة على Ubuntu الإصلاحات اللازمة.

الوصول إلى خدمة مرتبطة بـlocalhost

هنا تصبح tailnet مفيدة، وهنا يواجه المستخدمون المشكلة. لا يجعل الانضمام إلى tailnet خدمة loopback قابلة للوصول.

ss -tlnp | grep 3000

إذا عرض هذا الأمر 127.0.0.1:3000، فإن socket يقبل فقط الحزم التي يكون عنوان وجهتها 127.0.0.1. يصل الطلب من عقدة أخرى موجهاً إلى عنوان 100.x الخاص بهذه العقدة، لذلك لا يجد kernel شيئاً يستمع إليه على هذا العنوان ويرد بإعادة ضبط TCP. يعرض العميل Connection refused. النفق يعمل بصورة سليمة. المشكلة في listener.

يوجد حلان صحيحان. اربط الخدمة بعنوان tailnet الخاص بالعقدة، وبذلك تبقى خارج الواجهة العامة من دون وجود proxy بينها وبين العميل: مرّر --bind 100.101.102.104 أو الخيار المكافئ في ملف الإعداد، وانشر المنفذ للحاوية بصيغة -p 100.101.102.104:3000:3000. أو اترك الخدمة على loopback وضع Tailscale أمامها.

tailscale serve 3000

يعمل ذلك على تمرير الطلبات إلى http://127.0.0.1:3000 ويتيحها داخل tailnet باستخدام اسم ts.net عبر HTTPS، بعد تمكين شهادات HTTPS لـtailnet. وتبقى الخدمة خاصة بعقدك. أما النسخة العامة من الفكرة نفسها فهي Funnel، وتوضح Tailscale serve مع funnel أي الخيارين تحتاج إليه.

لهدفين مرتبطين صفحات مستقلة. للوصول إلى شبكة خاصة كاملة لا توجد عليها Tailscale، تحتاج إلى موجّه subnet على VPS، ولإرسال حركة الإنترنت الصادرة من عقدة عبر عقدة أخرى، تحتاج إلى عقدة exit.

إغلاق المنافذ التي لم تعد تحتاج إليها

بعد أن يتمكن كل مسؤول من الوصول إلى الخادم عبر tailnet، لا يعود للمنفذ العام 22 أي استخدام. هذه هي الفائدة العملية: لا يمكن تنفيذ هجمات التخمين بالقوة الغاشمة على منفذ مغلق، وتتوقف سجلاتك عن الامتلاء بمحاولات الاتصال.

ترتيب الخطوات مهم. أضف وصول tailnet، وتأكد من أنك تستطيع تسجيل الدخول عبره من جلسة ثانية، ثم أزل القاعدة العامة.

sudo ufw allow in on tailscale0
sudo ufw status verbose

بعد ذلك، احذف قاعدة SSH العامة وأعد الاتصال باستخدام اسم MagicDNS. انتبه إلى ما يفعله ufw allow in on tailscale0 فعلياً: فهو يثق بكل ما يصل عبر النفق، لذلك يصبح ملف سياسة Tailscale هو آلية التحكم في الوصول بدلاً من ufw. اكتب السياسة مع مراعاة ذلك.

تحذير لمن يشغّل الحاويات. ينشئ منفذ Docker المنشور قواعد NAT خاصة به ويتجاوز ufw، لذلك لا يؤدي ufw deny إلى إغلاقه. يشرح تجاوز منافذ Docker المنشورة لـ ufw هذه الآلية. يؤدي النشر على عنوان tailnet، كما سبق، إلى تجنب هذه المشكلة.

ما الذي يحميه Tailscale، وما الذي لا يحميه

من المهم توضيح ذلك مباشرة، لأن الخطاب التسويقي يطمس هذا الحد الفاصل.

المحمي: تُشفَّر حركة الشبكة بين عقدتين من طرف إلى طرف باستخدام WireGuard، ولا يستطيع أي relay وسيط قراءتها. لا تغادر المفاتيح الخاصة الجهاز الذي أنشأها. لا تحتاج العقد إلى منفذ عام وارد، لذلك لا يوجد شيء على 22 أو 5432 ليفحصه الإنترنت. تُحدَّد صلاحية الوصول بين العقد بواسطة ملف سياسة، وليس بواسطة أي شخص يعرف عنواناً.

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

هناك إجابتان عن خطر توزيع المفاتيح. الأولى هي tailnet lock، الذي يطلب من العقد الموثوقة الحالية توقيع عقدة جديدة تشفيرياً قبل أن تقبلها العقد الأخرى. ويتجاهل مستوى التحكم الذي يضيف عقدة من دون توقيع صالح. تنشئ وحدة تحكم الإدارة السطر tailscale lock init الدقيق لعقد التوقيع، ويمكن لكل عقدة تأكيد ما تراه.

tailscale lock status

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

هناك إعداد افتراضي يجب إصلاحه في اليوم الأول. يُصدِر tailnet الجديد بإعداد متساهل: "يتيح ملف سياسة tailnet الافتراضي الاتصال بين جميع الأجهزة داخل tailnet." وما إن تضيف قسم acls حتى يتغير النموذج إلى الرفض افتراضياً، ولا تمر إلا القواعد التي تضعها.

{
  "tagOwners": {
    "tag:server": ["autogroup:admin"]
  },
  "acls": [
    {"action": "accept", "src": ["autogroup:member"], "dst": ["tag:server:22"]}
  ]
}

تسمح هذه السياسة لأعضاء tailnet بالوصول إلى SSH على الخوادم الموسومة، ولا تسمح بأي شيء آخر. أضف قاعدة لكل خدمة بدلاً من إبقاء wildcard، لأن wildcard يعني أن مفتاح حاسوب محمول مسروقاً يتيح الوصول إلى قاعدة بياناتك.

أوضاع الفشل والعبارات التي ستظهر لك

tailscale status يعرض دائماً relay. لم تنشئ العقدتان مساراً مباشراً قط. شغّل tailscale netcheck على الطرفين. يعني UDP: false أن حركة UDP الصادرة محجوبة، ولذلك لا يمكن أن يعمل إلا relay. يعني MappingVariesByDestIP: true وجود NAT صارم، وغالباً ما يؤدي السماح بحركة UDP الواردة على المنفذ 41641 في الطرف الذي تتحكم فيه إلى حل المشكلة.

اختفت عقدة كانت تعمل لعدة أشهر. انتهت صلاحية node key الخاصة بها بعد فترة 180 يوماً الافتراضية. تظهر الآلة منتهية الصلاحية في وحدة تحكم الإدارة، ويعيدها تشغيل sudo tailscale up على الآلة إلى العمل. عطّل انتهاء صلاحية المفاتيح على الخوادم حتى لا تتكرر المشكلة.

تظهر الـpeers في القائمة، لكن تنتهي مهلة الاتصالات. الاتصال يعمل، لكن policy تمنع حركة المرور. افحص قسم acls بحثاً عن قاعدة تغطي هذا المصدر والوجهة والمنفذ. تُسقط الحزمة المرفوضة بدلاً من الرد عليها، ولذلك تحصل على انتهاء مهلة بدلاً من Connection refused.

لا تُحل أسماء MagicDNS. يفشل ping db-1 بينما يعمل ping 100.101.102.104. استبدل شيء ما /etc/resolv.conf، ولذلك لا تصل الاستعلامات إلى stub resolver على 100.100.100.100. افحص cat /etc/resolv.conf بحثاً عن 100.100.100.100، وتحقق من أي مكوّن آخر على الآلة يكتب ذلك الملف. هذه المشكلة من الفئة نفسها التي ينتمي إليها تعطل DNS داخل نفق WireGuard.

يرفض tailscale up الوسم الذي تحدده. لم يُعرَّف الوسم ضمن tagOwners في policy file. أضفه هناك، ثم شغّل الأمر مرة أخرى.

FAQ

هل Tailscale شبكة VPN أم شبكة mesh؟

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

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

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

هل أحتاج إلى فتح منافذ في جدار الحماية من أجل Tailscale؟

يكاد ألا يكون ذلك ضرورياً للاتصالات الواردة. توضح إرشادات Tailscale الخاصة أن «معظم الوقت، لا تحتاج إلى فتح أي منافذ في جدار الحماية». في الاتصالات الصادرة، تحتاج العقدة إلى TCP 443 لخادم التنسيق والمرحّلات، إضافةً إلى UDP 3478 من أجل STUN. تستخدم الأنفاق المباشرة UDP مع منفذ مصدر افتراضي هو 41641. السماح بالاتصالات الواردة إلى UDP 41641 اختياري، ولا يساعد إلا في نجاح الاتصالات المباشرة على الشبكات الصعبة.

لماذا لا تستطيع العقد الأخرى الوصول إلى خدمتي على المنفذ 3000؟

تحقق أولاً من عنوان الربط باستخدام ss -tlnp. يرفض المستمع على 127.0.0.1:3000 الاتصالات الموجّهة إلى عنوان tailnet ‏100.x الخاص بالعقدة، لأن socket هذا يقبل وجهة loopback فقط، ويرى العميل الخطأ Connection refused. اربط الخدمة بعنوان tailnet، أو شغّل tailscale serve 3000 للعمل كـ proxy لها. إذا كان المستمع يعمل بالفعل على 0.0.0.0 وانتهت مهلة الاتصال بدلاً من رفضه، فالسبب هو قاعدة سياسة أو جدار حماية على المضيف، وليس عنوان الربط.

هل ينبغي أن أشغّل Headscale بدلاً من خادم التنسيق الخاص بـ Tailscale؟

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