WireGuard أم Tailscale أم Headscale: ماذا تختار؟

WireGuard مقابل Tailscale: الإجابة المختصرة

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

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

ما الذي يقدمه مستوى التحكم فعلياً

لا يتضمن WireGuard العادي آلية لاكتشاف الأجهزة. كل نظير عبارة عن كتلة نصية تكتبها يدوياً: مفتاح عام، وسطر AllowedIPs، وسطر Endpoint إذا كان الوصول إلى ذلك النظير ممكناً. تتطلب إضافة جهاز واحد إلى شبكة تضم عشرة أجهزة تعديل ملفات الإعداد العشرة، لأن كل طرف يحتاج إلى مفتاح الطرف الآخر. لذلك تعتمد معظم إعدادات WireGuard ذاتية الاستضافة على نمط المحور والأطراف: خادم واحد يملك عنوان IP عاماً، وعملاء لا يتصلون إلا به.

يلغي مستوى التحكم الحاجة إلى هذا التعديل اليدوي. يسجّل كل عقدة نفسها مرة واحدة، وتتلقى عنواناً من نطاق 100.64.0.0/10 CGNAT (ترجمة عناوين الشبكة على مستوى مزود الخدمة)، ثم تحصل على المفاتيح العامة للعقد المسموح لها بالوصول إليها. يظل النفق اتصال WireGuard مباشراً بين نظيرين، ولا تمر حركة الشبكة عبر خادم التنسيق. ينقل الخادم بيانات وصفية فقط: الأجهزة الموجودة، والمفتاح الخاص بكل جهاز، والأجهزة التي يُسمح لها بالاتصال ببعضها.

ينتج عن ذلك ثلاث فوائد عملية.

اجتياز NAT. لا يملك حاسوبا محمولان خلف موجهي منزلين مختلفين عنوان IP عاماً مشتركاً يمكنهما استخدامه للاتصال مباشرة. يستخدم Tailscale STUN (أدوات اجتياز الجلسات لـNAT) لاكتشاف العنوان والمنفذ الخارجيين لكل طرف، ثم يرسل الطرفان الحزم في اللحظة نفسها، بحيث يرى كل موجّه تدفقاً صادراً أولاً ويقبل الرد. عند فشل ذلك، تعود حركة الشبكة إلى مرحّل DERP، وهو مرحّل مشفّر تديره Tailscale. تبقى بياناتك مشفّرة من طرف إلى طرف عبر المرحّل، لأن المرحّل لا يملك المفاتيح. شغّل tailscale status، وسيذكر سطر كل نظير direct أو relay. شغّل tailscale netcheck لمعرفة المرحّل الأقرب وما إذا كانت شبكتك تسمح بـUDP أصلاً.

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

السياسة بدلاً من التوجيه. في WireGuard العادي، تكون AllowedIPs جدول التوجيه وقائمة التحكم في الوصول في الوقت نفسه، لذلك يجب التعبير عن عبارة «يُسمح لـalice بالوصول إلى قاعدة البيانات» باستخدام نطاق IP. يحتفظ Tailscale بملف سياسة منفصل تسمّي قواعده المستخدمين والمجموعات والوسوم. يمكن أن تنص قاعدة على أن tag:laptop يُسمح له بالوصول إلى tag:db على المنفذ 5432 ولا شيء غير ذلك، وتظل هذه القاعدة سارية حتى بعد حصول الجهاز على عنوان جديد.

ما الذي تكلّفك إياه طبقة التحكم

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

هناك تكلفة ثانية يسهل إغفالها. يعمل Tailscale كخدمة في كل جهاز، ولذلك يجب عليك إبقاء البرنامج محدّثاً بالتصحيحات في كل جهاز. أما WireGuard العادي على Ubuntu 24.04 فهو وحدة kernel تأتي مع التوزيعة وتتحدّث مع kernel.

التكلفة الثالثة هي الفوترة. اعتباراً من July 2026، تكون خطة Personal مجانية مع عدد غير محدود من الأجهزة لما يصل إلى 6 مستخدمين، وتبلغ تكلفة Standard مبلغ $8 لكل مستخدم شهرياً، بينما تبلغ تكلفة Premium مبلغ $18 لكل مستخدم شهرياً. تبقى الأسرة ضمن الخطة المجانية. أما فريق من عشرة أشخاص فلا يبقى كذلك. يعتمد تجاوز هذا الحد على عدد المقاعد، لا على عدد الأجهزة، ولذلك يجدر قراءة ما تغطيه الخطة المجانية فعلياً قبل دعوة المستخدم السابع.

متى يكون WireGuard العادي هو الخيار المناسب

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

وهو الخيار المناسب أيضاً عندما تريد فهم الطبقة التي تُبنى عليها كل الخيارات الأخرى. يشرح استضافة شبكة WireGuard VPN ذاتياً على VPS إنشاء المفاتيح، وwg0.conf، وتمرير IP، وNAT، وفشل المصافحة. وتستمر كل هذه الآليات في العمل أسفل tailnet. إذا كنت لا تزال توازن بين الخيار الأقدم، يوضّح WireGuard مقابل OpenVPN الحالات الأربع التي يحتفظ فيها OpenVPN بميزة.

التثبيت قصير:

sudo apt update && sudo apt install -y wireguard
sudo modprobe wireguard && echo ok

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

عندما يكون Tailscale هو الخيار المناسب

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

يتم تثبيت العميل باستخدام أمر واحد من أداة التثبيت الرسمية:

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

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

تنجز إعداداتان معظم الوظائف المهمة بعد ذلك. يعلن موجّه الشبكة الفرعية عن شبكة LAN كاملة داخل الشبكة، لذلك لا تحتاج إلى تثبيت العميل على كل جهاز:

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale set --advertise-routes=192.0.2.0/24

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

ترسل عقدة الخروج كل حركة مرور العميل عبر جهاز واحد. وهذا هو سلوك النفق الكامل الذي يقصده معظم الناس بعبارة «VPN»:

sudo tailscale set --advertise-exit-node

يمثل هذا الخيار الجزء السهل. يشرح تحويل VPS إلى عقدة خروج الخطوات اللاحقة: الموافقة على المسار في وحدة تحكم الإدارة، ثم إصلاح سلوك DNS وIPv6 الذي يؤدي بخلاف ذلك إلى خروج حركة المرور من المسار الخطأ. إذا كنت تريد الوصول إلى خدمة ويب واحدة بدلاً من شبكة كاملة، فإن serve وfunnel يضع HTTPS أمام منفذ محلي واحد بدلاً من ذلك، سواء كان متاحاً داخل tailnet فقط أو مفتوحاً على الإنترنت العام.

متى يكون Headscale هو الخيار المناسب

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

sudo tailscale up --login-server https://headscale.example.com

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

لكن ذلك يتطلب عملاً فعلياً. فأنت تدير الآن خدمة HTTPS عامة، ما يعني الحاجة إلى اسم DNS وشهادة وReverse Proxy يمرر ترقيات WebSocket بصورة صحيحة. وتصبح أنت مسؤولاً عن وقت تشغيلها، كما أن توقف خادم التنسيق يعني أن العقد الجديدة لن تتمكن من التسجيل، وأن العقد الحالية لن تتمكن من معرفة التغييرات. كذلك، لا يزال Headscale دون الإصدار 1.0، وقد تضمنت إصداراته الفرعية تغييرات تكسر التوافق؛ لذلك اقرأ سجل التغييرات قبل كل ترقية. يشرح تشغيل Headscale كخادم تحكم Tailscale خاص بك عملية التثبيت، وconfig.yaml، ومفاتيح preauth، والمنافذ التي يجب فتحها.

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

كيفية اتخاذ القرار دفعة واحدة

اسأل عن عدد الأجهزة التي يجب أن تتصل ببعضها. إذا كانت الإجابة هي أنها تتصل جميعاً بالخادم فقط، فإن WireGuard العادي يتطلب برامج أقل لتحقيق النتيجة نفسها.

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

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

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

ما الذي لا يوفّره أيٌّ من الخيارات الثلاثة

لا يعمل أيٌّ منها كجدار ناري. يحدد النفق الحزم التي ينقلها، ولا يحدد الخدمات التي تستمع. يظل الخادم الذي يمكن الوصول إليه عبر النفق قابلاً للوصول من الإنترنت على أي منفذ تركته مفتوحاً. لذلك، اترك قواعد جدار UFW الناري على VPS تؤدي وظيفتها. يضيّق ملف سياسة Tailscale نطاق وصول العقد الأخرى، لكنه لا يؤثر في الواجهة العامة.

لا يوفّر أيٌّ منها مصادقة خاصة بكل خدمة، ولا يوفّر أيٌّ منها سجل تدقيق يوضح ما فعله المستخدم بعد الاتصال. تعامل مع الخيارات الثلاثة كلها على أنها وسائل نقل، وضع فحوصات تسجيل الدخول داخل التطبيق.

FAQ

هل Tailscale مجرد WireGuard مع خطوات إضافية؟

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

هل تمر بياناتي عبر خوادم Tailscale؟

عادةً لا. يتصل النظراء مباشرةً بعضهم ببعض بعد أن يعرّفهم خادم التنسيق، ويعرض tailscale status القيمة direct في أسطر هؤلاء النظراء. عندما يتعذر إنشاء مسار مباشر، تعود حركة الشبكة إلى مرحّل DERP ويظهر السطر بالقيمة relay. وحتى في هذه الحالة، ينقل المرحّل حزم مشفّرة ولا يحتفظ بمفاتيح WireGuard الخاصة بك، لذلك لا يستطيع قراءة محتواها. شغّل tailscale netcheck لمعرفة ما إذا كانت شبكتك تحظر UDP الذي تحتاج إليه الاتصالات المباشرة.

هل يمكنني استخدام Headscale مع تطبيقات Tailscale الرسمية؟

نعم. يتحدث Headscale بروتوكول التحكم نفسه، لذلك تنضم العملاء الرسميون باستخدام sudo tailscale up --login-server https://headscale.example.com. ويمكن أيضاً توجيه تطبيقات سطح المكتب والأجهزة المحمولة إلى خادم تسجيل دخول مخصص، لكن يوجد الإعداد في موضع مختلف على كل منصة، وتكون تطبيقات الأجهزة المحمولة أكثر عرضة للحاجة إلى إصدار محدد. اختبر هاتفاً واحداً قبل ترحيل شبكة كاملة.

هل ما زلت بحاجة إلى فتح منافذ لـTailscale أو Headscale؟

لا يحتاج عميل Tailscale إلى منفذ وارد، لأنه ينشئ اتصالاً صادراً إلى خادم التنسيق ويحافظ على هذا الاتصال مفتوحاً. لكن يحتاج خادم Headscale المستضاف ذاتياً إلى منافذ واردة: المنفذ 443 لبروتوكول التحكم، والمنفذ 80 إذا كنت تستخدم تحدي شهادة HTTP-01، والمنفذ 3478/udp فقط عند تفعيل المرحّل المضمّن. يحتاج WireGuard العادي إلى فتح منفذ الاستماع UDP الخاص به، وعادةً ما يكون 51820، على الخادم وعلى أي جدار ناري منفصل للشبكة يشغّله موفّر الخدمة لديك.

أيّ من الخيارات الثلاثة أسرع؟

تكون سرعة النقل متماثلة، لأن الخيارات الثلاثة تنقل الحزم باستخدام WireGuard. يظهر الفرق في إعداد الاتصال وجودة المسار. يتصل WireGuard العادي مباشرةً في كل مرة عند ضبط Endpoint بشكل صحيح. ويتصل Tailscale وHeadscale مباشرةً في معظم الأوقات، ثم يعودان إلى مرحّل عندما تحظر الشبكة تقنية ثقب NAT، ويضيف المسار المرحّل زمن تأخير. قِس مسارك باستخدام tailscale ping <node>، الذي يوضّح ما إذا كان المسار مباشراً أو مرحّلاً، أو باستخدام iperf3 عبر النفق. إذا كانت القيمة أقل بكثير من سرعة خطك في مسار مباشر، فليس الاختيار بين الخيارات الثلاثة هو سبب المشكلة، بل إن السبب المعتاد هو عدم تطابق MTU للمسار الذي يتصرف بالطريقة نفسها مع مستوى تحكم أو بدونه.