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

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

ما الذي يكلّفك إياه مستوى التحكم

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

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

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

متى يكون WireGuard العادي هو الخيار الصحيح

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

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

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

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

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

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

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

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

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

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

بعد ذلك، ينفذ إعدادان معظم الوظائف المفيدة. يعلن subnet router عن شبكة 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 حتى تضبط ذلك. إذا كان هذا هو التصميم الذي تريده، يشرح تشغيل subnet router على VPS خطوة الموافقة وإعدادات إعادة التوجيه بالترتيب الذي يتجنب إنشاء مسار يعمل جزئياً.

ترسل exit node حركة الإنترنت العادية للعميل، أي كل ما لا يتجه مسبقاً إلى جهاز آخر في tailnet أو إلى مسار subnet معتمد، عبر جهاز واحد. وهذا هو سلوك full tunnel الذي يقصده الناس عادةً بعبارة "VPN". في Linux، تحتاج إلى إعدادات إعادة توجيه IP نفسها الموضحة أعلاه قبل الإعلان عنها:

sudo tailscale set --advertise-exit-node

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

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

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

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

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

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

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