تشغيل موجّه شبكة فرعية في 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 على ذلك المنفذ الواحد بدلاً من ذلك. وينطبق المنطق نفسه على خدمة ترتبط عمداً بـ localhost فقط، مثل dsh التي تعمل دون واجهة تحت إدارة systemd، إذ يحل عنوان tailnet على ذلك الـVPS محل نفق SSH الذي كنت ستبقيه مفتوحاً للوصول إلى واجهتها.

الحالة الأخرى هي وجود شبكة على الجانب البعيد من VPS. قد تكون شبكة LAN منزلية أو مكتبية خلف موجّه خاص بها، أو مجموعة من الأجهزة الموجودة في الرف ولا يمكنها تشغيل Tailscale إطلاقاً، مثل محوّل مُدار أو جهاز NAS قديم ببرنامج ثابت مقفل. يصبح أحد أجهزة Linux على تلك الشبكة موجّه الشبكة الفرعية لكل الأجهزة الأخرى فيها. في المنزل، يكون ذلك الجهاز غالباً آلة افتراضية صغيرة على hypervisor تشغّله مسبقاً، وتُعد مقارنة تكلفة مضيف Proxmox في المنزل مع 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 forwarding والحفاظ عليه بعد إعادة التشغيل

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

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 هي ما يعيدها بعد إعادة التشغيل.

إذا أعلنت عن المسارات بينما forwarding لا يزال معطلاً، فإن tailscale up يحذرك في حينه، بسطر قريب من Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly. اقرأ مخرجات هذا الأمر بدلاً من تجاوزها بالتمرير.

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

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.1.0.20 عملها عبر 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، فالاسم سليم والمسار مفقود. أعلن عن نطاق يغطي العنوان، إما 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، وإلا فستختفي عند الإقلاع التالي.

الصيانة التي تُبقيه قيد التشغيل

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

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

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

أخيراً، حدّد ما إذا كنت تريد خادم تنسيق لا تديره بنفسك. إن مستوى التحكم في Tailscale خدمة مستضافة. تبقى مفاتيحك على أجهزتك، لكن الحساب وملف السياسة موجودان هناك. من المهم تحديد ما يمكن فعلياً أن يفعله شخص إذا تم اختراق مستوى التحكم أو سُرقت بيانات تسجيل الدخول إلى الهوية، قبل أن تمنحه مساراً إلى شبكتك الخاصة. وتوضّح نموذج الثقة في Tailscale موضع هذا الحد. نادراً ما تكون التكلفة سبباً كافياً للابتعاد عنه، لأن الخطة المجانية تغطي ما يصل إلى ستة مستخدمين مع عدد غير محدود من أجهزتهم، مع أن موجّه الشبكة الفرعية الذي تشغّله باستخدام علامة يُحتسب بطريقة مختلفة عن موجّه يسجّل الدخول باسمك. بعد ذلك، تُحتسب الفاتورة بحسب عدد الأشخاص لا الأجهزة، ولذلك يجدر بك معرفة ما تدفعه أسرة أو فريق من خمسة أشخاص فعلياً بعد انتهاء الخطة المجانية قبل إضافة الحساب الذي يتجاوز الحد. يضع تشغيل Headscale، خادم التحكم ذاتي الاستضافة لـTailscale ذلك على VPS تملكه، لكنه يتطلب صيانته. والحل الآخر للمشكلة نفسها هو التخلي عن عملاء Tailscale أيضاً؛ إذ يضع الاستضافة الذاتية لخادم NetBird VPN طبقة التنسيق وعملاء الشبكة الخاصة بها على جهاز واحد تتحكم فيه. إذا كنت لا تزال تختار بين هذا النموذج وملفات الإعداد المكتوبة يدوياً، فإن مقارنة 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، فأعلن عن نطاق يغطي ذلك العنوان، ووافق على البادئة الجديدة في وحدة تحكم الإدارة.