SSD Nodes Learn Hosting plans →
الأدلة Matt Connorبقلم Matt Connor · آخر تحديث في 2026-08-27

كيفية تحويل VPS إلى عقدة خروج في Tailscale

حوّل VPS إلى عقدة خروج في Tailscale بخمس خطوات: ثبّت البرنامج، أعلن المسار، فعّل IP forwarding، وافق عليه من لوحة الإدارة، ثم أصلح DNS وIPv6.

ما الذي يفعله عقدة الخروج في Tailscale

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

بعد تفعيلها، يشفّر حاسوبك المحمول كل حزمة ويرسلها إلى VPS. يطبّق VPS ترجمة عناوين المصدر (source NAT، أي ترجمة عناوين الشبكة)، ثم يرسل الحزمة باستخدام عنوانه العام. ترى مواقع الويب عنوان VPS. ولا ترى شبكة Wi-Fi في المقهى سوى تدفق UDP مشفّر واحد إلى VPS، ولا ترى أي شيء آخر.

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

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

ثبّت Tailscale على VPS

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

يختار برنامج التثبيت مستودع الحزم المناسب لتوزيعتك، ثم يثبّت عفريت tailscaled. بعد ذلك، يطبع tailscale up عنوان URL للمصادقة. افتحه في متصفح، وسجّل الدخول باستخدام الحساب نفسه الذي يستخدمه حاسوبك المحمول، لأن VPS المسجّل الدخول إلى tailnet مختلف لن يتمكن من خدمة حاسوبك المحمول إطلاقاً.

tailscale status
tailscale ip -4

يجب أن يعرض tailscale status الجهازين الآن. يطبع tailscale ip -4 عنوان VPS داخل tailnet، وهو العنوان الذي ستزوّد به العميل لاحقاً.

يحتاج Tailscale إلى جهاز TUN لإنشاء النفق. يكون هذا الجهاز موجوداً في VPS يعمل بتقنية KVM. أما في الخطط المبنية على المحاكاة الافتراضية للحاويات، والتي تشارك نواة المضيف، فقد يكون /dev/net/tun مفقوداً أحياناً، ولا يستطيع tailscaled إنشاء واجهة tailscale0. شغّل ls -l /dev/net/tun قبل المتابعة.

فعِّل تمرير IP، وإلا أسقط VPS كل حزمة

تُسقط آلة Linux أي حزمة لا تكون موجّهة إليها، لأن قيمة net.ipv4.ip_forward تكون 0 افتراضياً. سيقبل exit node حركة الشبكة الخاصة بك ويفك تشفيرها، ثم يتخلص منها. اكتب الإعداد في ملف حتى يبقى بعد إعادة التشغيل.

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

يستخدم tee -a الإلحاق، لذلك يؤدي تشغيل هذه الأسطر مرة ثانية إلى كتابة الإعدادين مرتين. سيظل الإعداد يعمل، لكن سيبدو cat /etc/sysctl.d/99-tailscale.conf غريباً. تحقّق من القيمة الفعلية بدلاً من الوثوق بالملف:

sysctl net.ipv4.ip_forward

يجب أن يطبع net.ipv4.ip_forward = 1. إذا تخطيت هذه الخطوة واستخدمت tailscale up --advertise-exit-node، فسيخبرك العميل بما يلي:

Warning: IP forwarding is disabled, subnet routing/exit nodes will not work.

لا يجري tailscale set --advertise-exit-node هذا التحقق، لذلك لا يعني عدم ظهور مخرجات من set أن التمرير مفعّل. اقرأ قيمة sysctl بنفسك.

لا تحتاج إلى كتابة قاعدة masquerade يدوياً. ينشئ tailscaled سلاسل جدار ناري خاصة به، بأسماء ts-input وts-forward وts-postrouting، وتوجد قاعدة NAT لحركة مرور exit node في ts-postrouting. اعرضها باستخدام sudo iptables-save | grep ts-، أو باستخدام sudo nft list ruleset على نظام يستخدم nftables.

أعلن عن VPS كعقدة خروج

sudo tailscale set --advertise-exit-node

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

changing settings via 'tailscale up' requires mentioning all
non-default flags. To proceed, either re-run your command with --reset or
use the command below to explicitly mention the current value of
all non-default settings:

استخدم set لإجراء التغييرات اللاحقة، ولن تظهر لك هذه الرسالة.

الإعلان هو مجرد عرض. يخبر VPS الآن خادم التنسيق بأنه مستعد للعمل كعقدة خروج. لا يمكن لأي عميل استخدامه بعد.

اعتمد عقدة الخروج الخاصة بـTailscale في وحدة تحكم الإدارة

هذه هي الخطوة الوحيدة التي لا يتبعها أمر. افتح صفحة الأجهزة في وحدة تحكم الإدارة، وابحث عن VPS، ثم افتح قائمة النقاط الثلاث في نهاية صفه، واختر Edit route settings، وفعّل Use as exit node.

إلى أن تفعّل هذا الخيار، تحتفظ طبقة التحكم بالعرض ولا تمنحه لأي جهاز. لا يعرض tailscale exit-node list على حاسوبك المحمول أي شيء، ويستمر مرور الشبكة عبر مساره المعتاد. لا تظهر رسالة خطأ على أي من الجهازين. لا تظهر عقدة الخروج على الإطلاق.

يمكنك اعتماد عقد الخروج تلقائياً بإضافة إدخال إلى ملف سياسة tailnet:

"autoApprovers": {
  "exitNode": ["tag:exit"],
}

يُعتمد الجهاز الذي شُغّل باستخدام --advertise-tags=tag:exit تلقائياً، ما دام tag:exit معرّفاً ضمن tagOwners في ملف السياسة نفسه. يغيّر وضع العلامة الجهة المالكة: يصبح الجهاز الذي يحمل علامة تابعاً لـtailnet بدلاً من حساب المستخدم، وتتغير معه قواعد الوصول المطبقة عليه. بالنسبة إلى VPS واحد، يكون المفتاح أبسط.

اختر عقدة الخروج على حاسوبك المحمول

على عميل Linux:

tailscale exit-node list
sudo tailscale set --exit-node=vps.your-tailnet.ts.net

يعرض exit-node list عقد الخروج المعتمدة في tailnet مع عناوينها. تعني القائمة الفارغة أن خطوة الاعتماد لم تُنفَّذ. في macOS وWindows وiOS وAndroid، يوجد الخيار نفسه في قائمة Exit Node داخل تطبيق Tailscale.

تحقق من العميل، وليس من الخادم مطلقاً:

curl -4 https://ifconfig.me

شغّل الأمر مرة قبل اختيار عقدة الخروج ومرة بعده. يجب أن يتغير العنوان من عنوانك المحلي إلى عنوان IP العام لخادم VPS. لإيقاف استخدام عقدة الخروج:

sudo tailscale set --exit-node=

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

sudo tailscale set --exit-node=<name> --exit-node-allow-lan-access=true

لماذا تتغير إعدادات DNS فور تفعيل exit node

بشكل افتراضي، يستخدم الجهاز الذي يعتمد على exit node عقدة الخروج نفسها كمحلّل DNS (نظام أسماء النطاقات) لكل نطاق. ويتجاوز ذلك خوادم الأسماء العامة وSplit DNS المكوّنة لشبكة tailnet. هذا السلوك مقصود. إذا استمرت الاستعلامات في التوجّه إلى محلّل الشبكة المحلية، فسيظل موجّه الشبكة في المقهى يرى اسم كل موقع تزوره، بينما تكون حركة الشبكة نفسها خاصة. يجب أن تخرج الأسماء والحزم من المكان نفسه.

تظهر إحدى النتائج بوضوح لدى من يشغّلون محلّلاً داخلياً: يتوقف استخدام خادم الأسماء في tailnet الذي تعتمد عليه عند تفعيل exit node. فعّل الخيار Use with exit node لخادم الأسماء هذا من صفحة DNS في وحدة تحكم الإدارة لإعادته إلى الاستخدام.

تستمر أسماء MagicDNS في العمل، لأن عميل Tailscale يجيب عنها محلياً عند 100.100.100.100 قبل وصول أي شيء إلى exit node. تحقق من ذلك باستخدام dig @100.100.100.100 your-vps.your-tailnet.ts.net، أو على عميل يستخدم systemd-resolved باستخدام resolvectl status، حيث تسرد واجهة Tailscale القيمة 100.100.100.100 بوصفها خادم DNS الخاص بها.

إذا عطّلت معالجة DNS في Tailscale باستخدام --accept-dns=false، فسيستمر العميل في استخدام محلّل DNS الذي تعلّمه من الشبكة المحلية. تُمرَّر حركة الشبكة عبر النفق، لكن الاستعلامات لا تُمرَّر عبره، وهذا هو تسرّب DNS نفسه الذي يطال أنفاق WireGuard المُنشأة يدوياً. اترك --accept-dns كما هو ما لم يكن لديك سبب محدد لتغييره.

IPv6 عبر عقدة الخروج

تعلن عقدة الخروج عن المسارين الافتراضيين، 0.0.0.0/0 و::/0. إذا لم يكن لدى VPS مسار IPv6 يعمل إلى الإنترنت، تصل حزم IPv6 عبر النفق وتتوقف هناك. اختبر ذلك على VPS قبل الاعتماد عليه:

ip -6 addr show
curl -6 https://ifconfig.me

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

الجزء الآخر هو إعادة التوجيه. يؤدي ضبط net.ipv4.ip_forward = 1 مع ترك net.ipv6.conf.all.forwarding على القيمة 0 إلى توفير مسار IPv4 يعمل، مع وجود مسار مسدود لـIPv6. يختبر القارئ ذلك على شكل «بعض المواقع بطيئة» بدلاً من ظهور خطأ يمكن البحث عنه. يجب وضع السطرين في ملف sysctl.

هل ينبغي لـVPS الإعلان عن مسارات الشبكة الفرعية أيضاً؟

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

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

أعلن عن شبكة فرعية عندما يشارك VPS شبكة خاصة مع خوادم أخرى تريد الوصول إليها باستخدام عناوينها الخاصة. وافق على المسار في لوحة Edit route settings نفسها، باستخدام مفتاح التبديل الخاص به. سيتجاهل عملاء Linux المسار المعلن حتى تمرر --accept-routes، وهذا أحد الفروق التي يشرحها دليل موجّه الشبكة الفرعية بالتفصيل.

اختر النطاق بعناية. يكون المسار المعلن أكثر تحديداً من المسار الافتراضي لحاسوبك المحمول، لذلك يؤدي الإعلان عن 192.168.1.0/24 من VPS إلى تولّي عناوين شبكة منزلية تستخدم النطاق نفسه، فتنقطع استجابة الأجهزة الموجودة على مكتبك. استخدم نطاقاً اخترته أنت، لا النطاق الذي اختاره موجّه منزلك تلقائياً.

اجعل عقدة الخروج سريعة عبر إعادة توجيه UDP GRO

يمكن لـTailscale 1.54 والإصدارات الأحدث، عند تشغيلها على نواة Linux 6.2 أو أحدث، استخدام إلغاء تحميل للاستقبال يرفع معدل نقل البيانات المُعاد توجيهها. يدمج GRO (إلغاء تحميل الاستقبال العام) الحزم الواردة قبل أن تعالجها النواة واحدةً تلو الأخرى. اعتباراً من August 2026، لا تزال هذه الخطوة يدوية على عقدة الخروج.

sudo apt install -y ethtool
NETDEV=$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")
sudo ethtool -K $NETDEV rx-udp-gro-forwarding on rx-gro-list off

يعرض ip -o route get 8.8.8.8 الواجهة التي تصل فعلياً إلى الإنترنت، لذلك لن تضطر إلى التخمين بين eth0 وens3 وenp1s0. تحقّق باستخدام ethtool -k $NETDEV | grep udp-gro-forwarding، الذي يُفترض أن يعرض الآن on. لا يفيد GRO إلا مساراً سليماً من الأساس. لذلك، إذا بقيت عقدة الخروج بطيئة بعد ذلك، فقِس المسار نفسه بالطريقة التي تستخدمها مع نفق WireGuard عادي أبطأ من الوصلة الموجودة تحته.

يُفقد هذا الإعداد عند إعادة التشغيل. على نظام يشغّل networkd-dispatcher، اجعله تلقائياً:

printf '#!/bin/sh\n\nethtool -K %s rx-udp-gro-forwarding on rx-gro-list off \n' "$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")" | sudo tee /etc/networkd-dispatcher/routable.d/50-tailscale
sudo chmod 755 /etc/networkd-dispatcher/routable.d/50-tailscale

تحقّق أولاً من وجود /etc/networkd-dispatcher/routable.d/. إذا لم يكن موجوداً، فهذا يعني أن الجهاز لا يشغّل networkd-dispatcher. وفي هذه الحالة، تؤدي وحدة systemd صغيرة تشغّل السطر ethtool عند الإقلاع المهمة نفسها.

ما الذي تعنيه سياسة الاستخدام المقبول لدى مزوّدك لحركة الخروج

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

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

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

لماذا تظل حركة الشبكة تخرج عبر اتصالك المحلي

عقدة الخروج معلنة، لكنها غير معتمدة. لا يعرض tailscale exit-node list على العميل أي مخرجات، ولا تسجل أي من الآلتين خطأً. انتقل إلى صفحة Machines وفعّل Use as exit node.

لم يحدد العميل عقدة الخروج. تجعل الموافقة العقدة متاحة لـtailnet. لكن تحديدها إجراء منفصل على كل جهاز. أعد تشغيل sudo tailscale set --exit-node=<name>، ثم تحقق من curl -4 https://ifconfig.me مرة أخرى.

إعادة التوجيه متوقفة. العَرَض محدد: ينجح tailscale ping <vps>، ويكون النفق مفعّلاً بوضوح، لكن تنتهي مهلة كل عنوان خارجي. يعرض sysctl net.ipv4.ip_forward القيمة 0. أصلح ملف sysctl، ثم شغّل sudo sysctl -p /etc/sysctl.d/99-tailscale.conf.

يُسقط جدار ناري الحزم المعاد توجيهها. ينشئ tailscaled سلسلة ts-forward الخاصة به، ويكفي ذلك عادةً على VPS نظيف. لكن الخادم الذي يشغّل ufw أو Docker مسبقاً قد ينتهي بسياسة FORWARD مضبوطة على DROP، مع قواعد مرتبة قبل قواعد Tailscale. لا تخمّن أي قاعدة تسبب المشكلة: شغّل sudo iptables -L FORWARD -n -v أثناء محاولة العميل تحميل صفحة، وراقب العدادات التي تتغير. على خادم يستخدم ufw، يكون الإصلاح المعتاد هو DEFAULT_FORWARD_POLICY="ACCEPT" في /etc/default/ufw، ثم تشغيل sudo ufw reload. افحص أيضاً جدار الشبكة الناري لدى مزود الخدمة من لوحة التحكم، لأنه عنصر تحكم منفصل عن كل ما يعمل على الخادم.

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

متى تتوقف عن استخدام خادم التنسيق المستضاف لدى Tailscale

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

FAQ

لماذا يستمر مرور حركة الشبكة عبر اتصالي المحلي بعد اختيار عقدة الخروج؟

هناك سببان شائعان. قد تكون عقدة الخروج أُعلنت، لكن لم تتم الموافقة عليها: افتح صفحة Machines في وحدة تحكم الإدارة، وابحث عن VPS، واختر Edit route settings، ثم فعّل Use as exit node. الموافقة عبارة عن مفتاح تبديل في وحدة التحكم، ولا ينفذها أي أمر على الخادم. السبب الثاني مختلف: إعادة توجيه IP متوقفة، لذلك يعمل النفق، ويعمل tailscale ping إلى VPS، لكن تنتهي مهلة كل عنوان خارجي. تحقّق باستخدام sysctl net.ipv4.ip_forward، ويجب أن تكون قيمته 1.

هل يجب أن أوافق يدوياً على عقدة الخروج في كل مرة؟

مفتاح التبديل إجراء يُنفّذ مرة واحدة لكل جهاز. إذا كنت تعيد إنشاء VPS كثيراً، فأضف كتلة autoApprovers إلى ملف سياسة tailnet، وتضمّن "exitNode": ["tag:exit"]، وعرّف tag:exit ضمن tagOwners، ثم شغّل العقدة باستخدام --advertise-tags=tag:exit. الجهاز المعلَّم تملكه tailnet بدلاً من حساب المستخدم الخاص بك، ولذلك تتغير قواعد الوصول التي تنطبق عليه أيضاً.

ما خادم DNS الذي يستخدمه الحاسوب المحمول أثناء تفعيل عقدة الخروج؟

يستخدم عقدة الخروج نفسها. يرسل الجهاز الذي يستخدم عقدة خروج جميع استعلامات DNS إليها، وهذا يتجاوز خوادم أسماء DNS العامة والمقسّمة المحددة لـtailnet. ويمنع ذلك الشبكة المحلية من رؤية الأسماء التي تبحث عنها. للاستمرار في تطبيق خادم أسماء tailnet واحد، فعّل Use with exit node له من صفحة DNS في وحدة تحكم الإدارة. تظل أسماء MagicDNS تُحل، لأن عميل Tailscale يجيب عنها محلياً على 100.100.100.100.

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

نعم. sudo tailscale set --advertise-exit-node وsudo tailscale set --advertise-routes=10.0.0.0/24 مستقلان، ولكل منهما مفتاح موافقة خاص به ضمن Edit route settings. يجب تفعيل إعادة توجيه IP على VPS لكليهما. تجنّب الإعلان عن نطاق يطابق شبكة منزلك على الحاسوب المحمول، لأن المسار المُعلن أكثر تحديداً من المسار الافتراضي، فتصبح أجهزتك المحلية غير قابلة للوصول.

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

لا. ينتهي النفق عند VPS، لذلك يغادر traffic الخادم بالشكل الذي يتوقعه الوجهة، وينقله المزوّد بنص واضح حيثما لا يكون الموقع نفسه مشفّراً. تنقل عقدة الخروج نقطة انضمام حركة الشبكة إلى الإنترنت من الشبكة التي تتصل منها إلى الخادم الذي تستأجره. وهي تخفي تصفحك عن شبكة Wi-Fi في المقهى وعن مزوّد خدمة الإنترنت المنزلي، لكنها تعرض التصفح نفسه على مزوّد VPS مع إرفاق اسم حسابك.