تشغيل موجّه شبكة فرعية في Tailscale على VPS

ما الذي يفعله موجّه الشبكة الفرعية في Tailscale

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

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

عندما تحتاج VPS إلى العمل كموجّه لشبكة فرعية

الحالة الشائعة هي شبكة خاصة منحك إياها موفّر الخدمة مسبقاً. لدى VPS عنوان عام وواجهة ثانية على مقطع خاص، بينما لا تملك الخوادم الأخرى على ذلك المقطع أي عنوان عام: قاعدة بيانات على 10.0.0.20، ووجهة نسخ احتياطي على 10.0.0.30. ثبّت Tailscale على إحدى خوادم VPS، وأعلن 10.0.0.0/24، وسيتمكن حاسوبك المحمول من الوصول إلى تلك العناوين الخاصة مباشرةً. لا يتغير أي شيء آخر على المقطع، وتظل قاعدة البيانات بلا عنوان عام. إذا كان ما تحتاجه من ذلك المقطع هو تطبيق ويب واحداً على منفذ واحد، فإن الإعلان عن النطاق كاملاً يتجاوز المطلوب، وفي هذه الحالة يضع Tailscale serve HTTPS على ذلك المنفذ الواحد بدلاً من ذلك. وينطبق المنطق نفسه على daemon يرتبط عمداً بـlocalhost فقط، مثل تشغيل dsh دون واجهة تفاعلية تحت systemd، حيث يحل عنوان tailnet على خادم VPS محل نفق SSH الذي كنت ستبقيه مفتوحاً للوصول إلى واجهته.

الحالة الأخرى هي وجود شبكة في الجهة البعيدة من VPS. قد تكون شبكة LAN (شبكة محلية) منزلية أو مكتبية خلف موجّه خاص بها، أو مجموعة من الأجهزة التي لا يمكنها تشغيل Tailscale إطلاقاً، مثل محوّل مُدار أو NAS قديم ببرامج ثابتة مقفلة. يصبح أحد صناديق Linux على تلك الشبكة موجّه الشبكة الفرعية لكل ما يوجد عليها. لا يحتاج الموجّه المنزلي الموجود أمامه إلى أي منفذ مُعاد توجيهه لهذا الغرض، ويوضح كيف يعبر Tailscale NAT دون فتح منفذ على الموجّه سبب نجاح ذلك ومتى ينتقل إلى استخدام relay. في المنزل، يكون ذلك الصندوق غالباً آلة افتراضية صغيرة على hypervisor تشغّله مسبقاً، وتُعد مقارنة تكلفة Proxmox host في المنزل مع VPS مستأجر المسألة التي ينبغي حسمها قبل أن تقرر في أي طرف من النفق يجب أن تعيش خدماتك.

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

ثبّت Tailscale وتحقق أولاً من المسار المحلي

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

يكتشف البرنامج التوزيعة، ويضيف مستودع حزم Tailscale، ويثبّت الأمر tailscale والخدمة الخفية tailscaled، ثم يفعّل الخدمة. تحقّق من ذلك باستخدام systemctl is-active tailscaled، الذي يفترض أن يطبع active.

قبل أي شيء آخر، تأكد من أن VPS يستطيع الوصول إلى الشبكة التي تخطط للإعلان عنها.

ip route show
ping -c3 10.0.0.20

يجب أن يعرض ip route show النطاق الخاص على واجهة فعلية، مثل 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5. إذا فشل اختبار ping هنا، أي على جهاز التوجيه نفسه، فلن تصلح أي راية في Tailscale المشكلة. تكون المشكلة في إعداد شبكة VPS أو في جدار ناري على المضيف الهدف. أصلح ذلك أولاً، لأن كل اختبار لاحق يعتمد عليه.

فعِّل إعادة توجيه IP واجعلها مستمرة بعد إعادة التشغيل

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

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

تحقق من ذلك باستخدام sysctl net.ipv4.ip_forward، الذي يجب أن يطبع net.ipv4.ip_forward = 1.

غالباً ما ينفّذ المستخدمون هذه الخطوة بشكل جزئي. يعمل sudo sysctl -w net.ipv4.ip_forward=1 فوراً، لكنه يختفي عند الإقلاع التالي. لذلك يعمل موجّه الشبكة الفرعية لأسابيع، ثم يتوقف في الصباح التالي لإعادة التشغيل بعد ترقية kernel. والجزء المربك هو أن شيئاً لا يبدو معطلاً. ما يزال tailscale status يعرض العقدة متصلة، وما تزال وحدة تحكم الإدارة تعرض أن المسار معتمد، وما يزال العملاء يحتفظون بالمسار مثبتاً. تصل الحزم إلى VPS، ثم تسقطها kernel من دون تسجيل أي شيء. إن كتابة القيم في /etc/sysctl.d/99-tailscale.conf هي ما يعيدها بعد إعادة التشغيل.

إذا أعلنت عن المسارات بينما لا تزال إعادة التوجيه معطّلة، فسيحذّرك tailscale up في ذلك الوقت. في Linux يكون السطر قريباً من Warning: IP forwarding is disabled, subnet routing/exit nodes will not work.. اقرأ ناتج ذلك الأمر بدلاً من تجاوزه بالتمرير.

أعلن عن المسارات

sudo tailscale up --advertise-routes=10.0.0.0/24

على VPS سجّل الدخول إليه مسبقاً ضمن tailnet، غيّر الإعداد مباشرةً بدلاً من ذلك:

sudo tailscale set --advertise-routes=10.0.0.0/24

استخدم tailscale set في كل تغيير لاحق. تؤدي إعادة تشغيل tailscale up مع علامة واحدة إلى إعادة تعيين العلامات التي لم تكررها، وتتوقف واجهة CLI وتعرض خطأ يفيد بأن تغيير الإعدادات بهذه الطريقة يتطلب ذكر جميع العلامات غير الافتراضية. يغيّر tailscale set إعداداً واحداً ويُبقي بقية الإعدادات كما هي.

تُدرج عدة نطاقات في قائمة واحدة مفصولة بفواصل ومن دون مسافات: --advertise-routes=10.0.0.0/24,192.168.50.0/24. يجب أن يكون كل إدخال عنوان شبكة بصيغة CIDR (التوجيه بين النطاقات غير الصنفية، بصيغة 10.0.0.0/24). إذا كتبت عنوان المضيف الخاص بك بالخطأ، 10.0.0.5/24، فسيُرفض لأن البتات التي تأتي بعد البادئة ليست صفراً، وتذكر رسالة الخطأ البادئة التي يُرجح أنك تقصدها. لإيقاف الإعلان، عيّن قائمة فارغة باستخدام sudo tailscale set --advertise-routes=.

اعتماد المسار في وحدة تحكم المسؤول

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

اعتمده من صفحة Machines في وحدة تحكم المسؤول. يظهر VPS مع شارة شبكة فرعية. افتح صفه، وابحث عن قسم الشبكات الفرعية، ثم حرّر إعدادات المسار، وحدد المسار، واحفظ التغييرات.

يُطبَّق الاعتماد على كل بادئة على حدة. إذا أعلنت 10.0.0.0/24 اليوم و192.168.50.0/24 في الشهر المقبل، فستصل البادئة الجديدة من دون اعتماد، بينما تواصل البادئة القديمة العمل. يبدو المسار المعتمد والمسار المتجاهَل متطابقين من جهة VPS، لذلك تحقّق من وحدة التحكم قبل تصحيح أي شيء آخر.

يمكنك تجاوز الخطوة اليدوية باستخدام كتلة autoApprovers في ملف سياسة tailnet:

{
  "autoApprovers": {
    "routes": {
      "10.0.0.0/24": ["tag:subnet-router"]
    }
  }
}

ثم شغّل العقدة باستخدام تلك العلامة، sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router، وسيُعتمد المسار لحظة الإعلان عنه. يجب أن تكون العلامة موجودة أولاً في قسم tagOwners من ملف السياسة نفسه. يفيد إعداد ذلك إذا كنت تعيد إنشاء VPS باستخدام برنامج نصي، لأن العقدة التي أُعيد إنشاؤها تُعد عقدة جديدة، وتبدأ مساراتها من دون اعتماد مرة أخرى.

لماذا تتجاهل عملاء Linux المسار من دون --accept-routes

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

يعني قبول مسار شبكة فرعية كتابة إدخالات في جدول التوجيه لدى العميل. في Android وiOS وmacOS وtvOS وWindows، يتولى عميل Tailscale ذلك تلقائياً. أما في Linux فلا يفعل ذلك، لأن جهاز Linux يكون غالباً خادماً أو موجهاً ضبط أحدهم جدول توجيهه عمداً، وقد يؤدي إدراج /24 تعلّمه من الشبكة بصمت إلى تعطيل حركة المرور التي يعالجها الجهاز مسبقاً. لذلك يجب تفعيل هذا الخيار صراحةً على كل عميل Linux:

sudo tailscale set --accept-routes

ثم تحقّق من مكان تثبيت المسار:

ip route show table 52
ip route get 10.0.0.20

لا يضع Tailscale على Linux المسارات المقبولة في جدول التوجيه الرئيسي. بل يضعها في جدول التوجيه 52، ويثبّت قواعد للسياسات تظهر باستخدام ip rule show ضمن نطاق الأولوية من 5210 إلى 5270، وتوجّه الحزم غير المطابقة إلى ذلك الجدول. لذلك لن يعرض ip route show بمفرده 10.0.0.0/24 أبداً، وقد يستنتج القارئ الذي يتحقق من هذا الأمر فقط أن --accept-routes لم يفعل شيئاً. أما ip route show table 52 فهو الأمر الذي يعرض الحالة الفعلية، ويجب أن يعرض النطاق المعلن على tailscale0.

توجد حالة استثناء مهمة. إذا كانت عقدة Linux هذه موجهاً ثانياً للشبكة الفرعية لشبكتها المحلية، فإن --accept-routes يجعلها ترسل حركة المرور الخاصة بشبكتها المتصلة مباشرةً عبر الموجه الآخر بدلاً من إرسالها عبر واجهتها هي. في الموجه الاحتياطي ضمن زوج عالي التوافر، اترك --accept-routes معطلاً واكتفِ بالإعلان عن المسار.

وضع الفشل: جهازا توجيه يعلنان عن نطاقات متداخلة

يمكن لجهازي توجيه للشبكات الفرعية الإعلان عن نطاقات متطابقة، وهذه هي طريقة عمل زوج التوافر العالي: يعلن كل جهاز توجيه عن البادئات نفسها تماماً، ويمكن للعملاء التحويل من أحدهما إلى الآخر عند الفشل. كما يُسمح بتداخل النطاقات ذات أطوال البادئات المختلفة، ويختار Tailscale المطابقة الأكثر تحديداً. عندما يعلن جهاز التوجيه A عن 10.0.0.0/24 ويعلن جهاز التوجيه B عن 10.0.0.0/16، تمر حركة الشبكة المتجهة إلى 10.0.0.20 عبر A.

ما يفاجئ المستخدمين هو السلوك عندما يصبح A غير متصل. لا يعود Tailscale إلى المسار الأقل تحديداً، لأن جهاز التوجيه غير المتصل لا يستطيع سحب إعلانه، ويستمر العملاء في تفضيل البادئة الأكثر تحديداً. تتوقف حركة الشبكة المتجهة إلى 10.0.0.20، بينما تستمر حركة الشبكة المتجهة إلى 10.0.1.20، التي يغطيها /16 الخاص بـB وحده، عبر B. يبدو العَرَض كأن جزءاً من الشبكة الخاصة متوقف، لكن السبب هو عقدة واحدة غير متصلة ما زالت تحتفظ بالبادئة الأكثر تحديداً. إذا أردت التحويل عند الفشل، فاجعل جهاز التوجيه الذي يعلن النطاق الأوسع يعلن أيضاً عن البادئات الأضيق، حتى يغطي كلاهما العناوين نفسها.

يحدث التداخل الآخر بالقرب من العميل. عندما تكون متصلاً بشبكة فندق في 192.168.1.0/24، بينما يعلن جهاز توجيه الشبكة الفرعية لديك عن 192.168.1.0/24، يتنافس المساران على الوجهات نفسها، ويعتمد المسار الفائز على المنصة. في Linux، أضف قاعدة قبل قاعدة Tailscale الخاصة به، بحيث تستخدم العناوين المحلية الجدول الرئيسي:

sudo ip rule add to 192.168.1.0/24 priority 2500 lookup main

هذه القاعدة غير دائمة وتختفي عند الإقلاع التالي. الحل الفعلي هو اختيار نطاق خاص لن تصادفه في الشبكات الأخرى. يُعد 192.168.0.0/24 و192.168.1.0/24 من القيم الافتراضية في معظم أجهزة التوجيه المنزلية، لذلك اختر نطاقاً داخل 10.0.0.0/8 عن قصد. يؤدي التعارض نفسه إلى تعطيل شبكة VPN عادية من WireGuard تهيئها يدوياً، للسبب نفسه: يفوز المسار المحلي الأكثر تحديداً، ولذلك لا تدخل حركة الشبكة إلى النفق.

وضع الفشل: يحل DNS الاسم إلى عنوان لا يغطيه أي مسار

يصعب تصحيح هذا النوع من الأعطال، لأن أياً من المكونات لا يبلغ عن خطأ. يُحل الاسم بنجاح، لكن تنتهي مهلة الاتصال.

لنفترض أن db.internal.example.com يُحل إلى 10.0.5.20 عبر خادم الأسماء الخاص بك، وأنك أعلنت عن 10.0.0.0/24. ينجح الاستعلام، لأن تحليل DNS (نظام أسماء النطاقات) والتوجيه عبر IP خطوتان منفصلتان، ولا تتحقق أي منهما من الأخرى. بعد ذلك، لا تعثر الحزمة المتجهة إلى 10.0.5.20 على مسار مطابق في tailnet، فتخرج عبر البوابة الافتراضية للعميل وتختفي.

يفصل أمران بين الجزأين:

nslookup db.internal.example.com
ip route get 10.0.5.20

إذا أعاد الاستعلام عنواناً، لكن ip route get لم يستجب باستخدام dev tailscale0، فالاسم صحيح والمسار مفقود على هذا العميل. على عميل Linux، تأكد أولاً من تشغيل --accept-routes، لأن مسار الشبكة الفرعية لا يُثبَّت من دونه، حتى عندما تغطي بادئة معتمدة العنوان بالفعل. إذا كان قيد التشغيل، ولا تغطي أي بادئة معتمدة العنوان، فأعلن عن نطاق يغطيه، إما 10.0.0.0/16 أو بادئة صريحة ثانية، ثم اعتمد البادئة الجديدة في وحدة التحكم.

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

NAT المصدر، وروابط الموقع إلى الموقع

افتراضياً، يعيد موجّه الشبكة الفرعية كتابة عنوان مصدر كل حزمة مُمرَّرة إلى عنوانه الخاص. يُسمّى ذلك SNAT، أي ترجمة عنوان شبكة المصدر. ويُستخدم لكي تعمل الردود دون إجراء أي تغيير على الشبكة الخاصة: ترد قاعدة البيانات على 10.0.0.20 إلى VPS، لأنها تعرف أصلاً كيفية الوصول إليه. لكن قاعدة البيانات سترى كل اتصال من tailnet وكأنه صادر من VPS، لذلك لن توفّر قواعد الجدار الناري حسب المصدر وسجلات الوصول معلومات مفيدة.

عطّل ذلك على Linux عندما تريد الحفاظ على عنوان العميل الحقيقي في tailnet:

sudo tailscale set --snat-subnet-routes=false

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

رابط الموقع إلى الموقع هو اتصال ينفّذ فيه موجّهان للشبكة الفرعية ذلك في الوقت نفسه، إذ يعلن كل منهما عن شبكته الخاصة ويقبل شبكة الموجّه الآخر:

sudo tailscale up --advertise-routes=10.0.0.0/24 --snat-subnet-routes=false --accept-routes

نفّذ الأمر المطابق على الموجّه الآخر باستخدام نطاقه الخاص. يجب أن يكون النطاقان مختلفين. إذا توقفت عمليات النقل الكبيرة بينما يعمل ssh وping بشكل سليم، فالسبب هو MSS، أي الحد الأقصى لحجم المقطع، وهو أكبر جزء من البيانات تحمله حزمة TCP. تجعل النفقات الإضافية للنفق الحزم المُمرَّرة أكبر من قدرة إحدى الوصلات الوسيطة، ويحل تصغير MSS هذه المشكلة:

sudo iptables -t mangle -A FORWARD -o tailscale0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

احفظ تلك القاعدة باستخدام iptables-persistent، وإلا فستختفي عند الإقلاع التالي.

الصيانة التي تحافظ على تشغيله

يعتمد انتهاء صلاحية مفتاح هذا الجهاز على طريقة تسجيل الدخول إليه. تكون صلاحية المفتاح معطّلة افتراضياً منذ لحظة وسم العقدة والمصادقة عليها لأول مرة، إذا شغّلتها تحت tag كما في مثال autoApprovers أعلاه. لذلك لا تحتاج هذه الإعدادات إلى أي إجراء هنا. أما العقدة التي سجّلت الدخول إليها بصفتك أنت، فتتبع مدة انتهاء صلاحية المفاتيح في tailnet. تكون هذه المدة 180 يوماً افتراضياً في tailnet جديدة، ويمكن ضبطها على قيمة من 1 إلى 180 يوماً، اعتباراً من أكتوبر 2026. عندما تنتهي صلاحية مفتاح subnet router كهذا، تتوقف الاتصالات من خلاله وإليه، ويصبح النطاق المعلن بأكمله غير قابل للوصول، من دون ظهور أي تغيير في الإعدادات يفسّر ذلك. إذا سجّلت الدخول إلى router بصفتك مستخدماً، عطّل انتهاء صلاحية المفتاح من القائمة الموجودة في نهاية صفه ضمن صفحة Machines في وحدة تحكم الإدارة، ثم دوّن أنك فعلت ذلك.

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

قواعد الوصول هي النصف الآخر. في tailnet بالإعداد الافتراضي، يمكن لكل جهاز تملكه الوصول إلى جميع أجهزتك الأخرى، لذلك يعمل route المعتمد مباشرة. بعد كتابة سياسة ACL، يجب أن يغطي جانب الوجهة في القاعدة النطاق الخاص، إما بذكره بالاسم أو باستخدام wildcard *. فهذا wildcard يتضمن subnet routes المعتمدة، لأن 10.0.0.20 ليس عنواناً في tailnet، ولا تغطيه القواعد المكتوبة باستخدام عناوين tailnet أو tags.

أخيراً، حدّد ما إذا كنت تقبل باستخدام خادم تنسيق لا تديره بنفسك. إنّ control plane في Tailscale خدمة مستضافة. تبقى مفاتيحك على أجهزتك، لكن الحساب وملف السياسات يكونان هناك. ما يمكن فعله فعلياً باستخدام control plane مخترق أو بيانات تسجيل دخول لهوية مسروقة هو الجزء الذي يجب حسمه قبل منحه مساراً إلى شبكتك الخاصة، وتوضح نموذج الثقة في Tailscale موضع هذا الحد. نادراً ما تكون التكلفة سبب التخلي عنه، لأن الخطة المجانية تغطي ما يصل إلى ستة مستخدمين مع عدد غير محدود من أجهزتهم الخاصة، مع أنّ subnet router الذي تشغّله ضمن tag يُحتسب بطريقة مختلفة عن ذلك الذي سجّلت الدخول إليه بحسابك. بعد ذلك، تُحتسب الفاتورة بحسب عدد الأشخاص لا الأجهزة، ولذلك من المفيد معرفة ما سيدفعه منزل أو فريق مكوّن من خمسة أشخاص فعلياً بعد انتهاء الخطة المجانية قبل إضافة الحساب الذي يتجاوز بك الحد. يتيح لك تشغيل Headscale، وهو خادم Tailscale للتحكم تستضيفه بنفسك إبقاء ذلك على VPS الخاص بك، مقابل تحمّل صيانته. ويتمثل الرد الآخر على القلق نفسه في التخلي أيضاً عن عملاء Tailscale، إذ يضع استضافة خادم NetBird VPN بنفسك طبقة التنسيق وعملاء الشبكة mesh الخاصين بها على جهاز واحد تتحكم فيه. يستخدم كلاهما WireGuard في الأساس، ولذلك فإن الأجزاء التي تتغير عند التبديل هي التي توازنها مقارنة NetBird وTailscale: من يدير control plane، وكيف تكتب قاعدة الوصول التي تغطي نطاقك الخاص، وكيف تُرحّل حركة الشبكة عندما يتعذر على الأقران الاتصال مباشرة. إذا كنت لا تزال تختار بين هذا النموذج وملف إعداد تكتبه يدوياً، فإن مقارنة WireGuard وTailscale تشرح ما توفره طبقة التنسيق وما تكلفه.

FAQ

ما الفرق بين موجّه الشبكة الفرعية وعقدة الخروج؟

يعلن موجّه الشبكة الفرعية عن نطاق من العناوين الخاصة، لذلك يمكن لأجهزة tailnet الوصول إلى أجهزة لا تشغّل Tailscale. تعلن عقدة الخروج عن نفسها كمسار إلى الإنترنت بالكامل، لذلك يرسل الجهاز كل حركة الشبكة عبر العنوان العام لتلك العقدة. يمكن لخادم VPS واحد أن يؤدي الدورين. وهما خياران منفصلان، --advertise-routes و--advertise-exit-node، ويحتاج كل منهما إلى موافقة مستقلة في وحدة تحكم الإدارة.

لماذا يتجاهل عميل Linux لديّ مسار الشبكة الفرعية المُعلن؟

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

توقفت شبكتي الفرعية عن العمل بعد إعادة التشغيل. ما الذي تعطل؟

غالباً إعادة توجيه IP. لا تبقى القيمة التي تضبطها باستخدام sysctl -w بعد إعادة التشغيل، لذلك اكتبها في /etc/sysctl.d/99-tailscale.conf وتحقق منها باستخدام sysctl net.ipv4.ip_forward. إذا كانت إعادة التوجيه مفعّلة وما زال النطاق غير قابل للوصول، فتحقّق من العقدة في وحدة تحكم الإدارة. تنتهي صلاحية المفتاح في الموجّه الذي سجّل الدخول كمستخدم بعد 180 يوماً افتراضياً. وقد يبدو موجّه الشبكة الفرعية الذي انتهت صلاحية مفتاحه كأنه مشكلة في الشبكة، لا مشكلة في الحساب. أما الموجّه الذي شغّلته باستخدام وسم، فتكون مدة صلاحية مفتاحه معطّلة افتراضياً. لذلك ابحث عن سبب آخر في هذه الحالة.

هل يمكن لموجّهَي شبكة فرعية الإعلان عن النطاق نفسه؟

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

يُحل اسم المضيف، لكن تنتهي مهلة الاتصال. لماذا؟

يُعد حل DNS والتوجيه خطوتين منفصلتين. قد يُحل الاسم إلى عنوان لا يغطيه أي مسار معتمد، ثم تغادر الحزمة عبر البوابة الافتراضية للعميل. شغّل ip route get <address> على العميل. إذا لم تتضمن الإجابة dev tailscale0 على عميل Linux، فتحقق أولاً من تفعيل --accept-routes. إذا كان مفعّلاً، فأعلن عن نطاق يغطي ذلك العنوان، ثم وافق على البادئة الجديدة في وحدة تحكم الإدارة.