ما هو Tailscale وكيف يعمل؟ شرح VPN وWireGuard

ما هو Tailscale؟

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

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

كيف تعمل Tailscale؟

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

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

يحصل كل جهاز على عنوان ثابت من 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" أن الحركة تمر عبر مرحّل Tailscale في Frankfurt. ويعني - أنه لا توجد جلسة نشطة مع تلك العقدة حالياً، وهذا أمر طبيعي.

ما يمكن لخادم التنسيق رؤيته وما لا يمكنه رؤيته

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

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

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

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

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

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

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

tailscale netcheck

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

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

يُعد DERP (مرحّل مشفّر مخصّص للحزم) خياراً احتياطياً. يشغّل Tailscale مرحّلات في مناطق عديدة، ويمكن الوصول إليها عبر TCP 443. وترسل العقدة التي لا تستطيع إنشاء مسار مباشر حزم WireGuard الخاصة بها عبر أحد هذه المرحّلات. والاستثناء هو tailnet الذي عيّنت فيه مرحّلات نظيرة، وهي أجهزتك الخاصة التي تعيد توجيه حركة المرور عبر UDP. يجرّب Tailscale هذه المرحّلات أولاً، ولا يعود إلى DERP إلا عند عدم توفر أي منها، وعندها يعرض tailscale status الاتصال على أنه peer-relay.

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

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

tailscale ping db-1

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

ضم VPS إلى شبكة tailnet الخاصة بك

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

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

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

sudo systemctl is-enabled tailscaled
tailscale status

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

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

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

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

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

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

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

ss -tlnp | grep 3000

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

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

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

بعد أن يتمكن كل مسؤول من الوصول إلى الخادم عبر 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، كما سبق، إلى تجنب هذه المشكلة. إذا كان التطبيق يعمل ضمن Docker Compose، فإن استخدام sidecar لـ Tailscale في مكدس Compose يذهب خطوة أبعد، إذ يلغي المنفذ المنشور تماماً ويجعل الوصول إلى الحاوية ممكناً فقط عبر اسمها في tailnet.

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

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

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

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

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

tailscale lock status

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

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

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

تسمح هذه السياسة لأعضاء tailnet بالوصول إلى SSH على الخوادم التي تحمل الوسم، ولا تسمح لهم بالوصول إلى أي شيء آخر. أضف قاعدة لكل خدمة بدلاً من ترك wildcard، لأن wildcard يعني أن سرقة مفتاح جهاز محمول واحد تتيح الوصول إلى قاعدة بياناتك. إذا كنت لا تزال تختار Mesh VPN، فإن طريقة كتابة قواعد مثل هذه من المواضع التي تختلف فيها الخيارات فعلياً، وتقارن NetBird مقابل Tailscale بين نموذجي السياسات، إلى جانب الجهة التي تدير control plane.

أنماط الفشل والنصوص التي ستراها

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

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

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

لا تُحل أسماء MagicDNS. يفشل ping db-1 بينما يعمل ping 100.101.102.104. تأكد أولاً من أن العميل يقبل إعدادات DNS الخاصة بـTailscale: فالعقدة التي بدأت باستخدام --accept-dns=false لا ترسل استعلاماتها إلى محلّل الأسماء الوسيط على 100.100.100.100. ثم افحص cat /etc/resolv.conf وأي شيء آخر على الجهاز يكتب ذلك الملف. في النظام الذي يستخدم systemd-resolved، يكون الملف عادةً رابطاً رمزياً إلى /run/systemd/resolve/stub-resolv.conf، ومن المتوقع ألا يتضمن 100.100.100.100 هناك. عندما يكتب tailscaled الملف مباشرة، فإن عميل DHCP أو أداة أخرى تستبدله، مما يؤدي إلى تعطيل MagicDNS. إذا لم يفسّر أي من ذلك المشكلة، فقد يكون الخلل أيضاً في إعدادات DNS المحلية أو إعدادات DNS على الشبكة. هذه المشكلة من الفئة نفسها التي تنتمي إليها أعطال DNS داخل نفق WireGuard.

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

FAQ

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

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

هل يستطيع 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، لأن ذلك المقبس يقبل وجهة loopback فقط، ويرى العميل Connection refused. اربط الخدمة بعنوان tailnet، أو شغّل tailscale serve 3000 لإنشاء proxy لها. إذا كان المستمع يعمل بالفعل على 0.0.0.0 وانتهت مهلة الاتصال بدلاً من رفضه، فعنوان الربط ليس سبب المشكلة. افحص قواعد السياسة وجدران الحماية على المضيف أولاً، ثم افحص جدران الحماية في الشبكة، وتحقق مما إذا كانت مصادقة أي من الجهازين قد انتهت.

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

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