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

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

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

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

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

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

هذه هي الخطوة التي لا يقابلها أي أمر. افتح صفحة Machines في وحدة تحكم الإدارة وابحث عن VPS، الذي يجب أن يعرض الآن شارة Exit Node. افتح قائمة ذلك الجهاز، واختر Edit exit node، وحدد مربع Use as exit node، ثم اختر Save.

إلى أن تحدد هذا المربع وتحفظ التغيير، تحتفظ طبقة التحكم بالطلب ولا تمنحه لأي جهاز. لا يعرض 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 يعمل إلى الخارج. إذا أبلغ curl عن "Could not resolve host" بدلاً من ذلك، فالمشكلة في تحليل الأسماء وليست في IPv6. أصلح DNS على VPS ثم أعد الاختبار. عادةً ما تستمر مواقع الويب التي تدعم dual stack في التحميل، لأن العملاء الذين يطبّقون Happy Eyeballs، ومن بينهم curl، يبدؤون محاولة IPv4 بالتوازي عندما لا تتصل محاولة IPv6 بعد انتظار قصير، ثم يحتفظون بالاتصال الذي ينجح أولاً. ينتظر curl مدة 200 milliseconds افتراضياً، لذلك يضيف هذا الانتظار تأخيراً إلى الاتصالات الجديدة بدلاً من التسبب في خطأ. تبقى الوجهات التي لا تدعم إلا 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 شبكة خاصة مع خوادم أخرى تريد الوصول إليها عبر عناوينها الخاصة. وافق على المسار في مربع حواره الخاص، المنفصل عن مربع حوار عقدة الخروج: في صفحة Machines، حدّد VPS، وانتقل إلى قسم Subnets، ثم حدّد Edit لفتح Edit subnet routes، وحدّد المسار، ثم حدّد Save. يتجاهل عملاء Linux المسار المعلن حتى تمرّر --accept-routes، وهذا أحد الفروق التي يغطيها شرح موجّه الشبكة الفرعية بالتفصيل.

اختر النطاق بعناية. بعد الموافقة على المسار، يمكن لحاسوب محمول يقبله (Windows وmacOS وiOS وAndroid تفعل ذلك افتراضياً، أما Linux فيحتاج إلى --accept-routes) إرسال حركة هذا النطاق عبر النفق. إذا وافقت على 192.168.1.0/24 من VPS، وكان حاسوب محمول على شبكة منزلية تستخدم النطاق نفسه، فقد تنتقل عناوين ذلك النطاق إلى النفق، وتصمت الأجهزة الموجودة على مكتبك. استخدم نطاقاً اخترته أنت، لا النطاق الذي اختاره موجّه الشبكة المنزلية لك.

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

يمكن لـTailscale 1.54 والإصدارات الأحدث، عند استخدام نواة Linux بالإصدار 6.2 أو إصدار أحدث، الاستفادة من تفريغ الاستقبال لزيادة معدل نقل البيانات في حركة المرور المُعاد توجيهها. تدمج GRO ‏(generic receive offload) الحزم الواردة قبل أن تعالجها النواة واحدةً تلو الأخرى. وحتى أكتوبر 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 مرتين: تصل من جهة ثم تغادر من الجهة الأخرى. وفي معظم خطط VPS، يُقاس الجزء الخارج فقط. اعتباراً من October 2026، تدرج SSD Nodes حصة كل خطة KVM على أنها نقل صادر، وتتراوح بين 4TB و48TB شهرياً، وتوضح وثائق Vultr أن حركة الدخول لا تُقاس. في حالة التنزيل، يكون الجزء المقاس هو الانتقال من VPS عبر النفق إلى حاسوبك المحمول. وفي حالة الرفع، يكون هو الانتقال من VPS إلى الإنترنت. في كلتا الحالتين، تُحتسب كل حركة توجّهها عبر عقدة الخروج مرة واحدة من الحصة، ويستهلك بث فيديو تتم مشاهدته عبر عقدة خروج حصة أكبر مما يتوقعه معظم الأشخاص. تحقّق من خطتك، لأن المضيف الذي يقيس الاتجاهين يحتسب هذا البث مرتين.

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

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

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

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

FAQ

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

هناك سببان شائعان. أُعلن عن عقدة الخروج، لكن لم تتم الموافقة عليها: افتح صفحة Machines في وحدة تحكم الإدارة، وابحث عن VPS، واختر Edit exit node من قائمته، وحدد Use as exit node، ثم اختر Save. تتم الموافقة من وحدة التحكم، ولا ينفذها أي أمر على الخادم. السبب الثاني مختلف: إعادة توجيه 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 إليها، ويتجاوز ذلك خوادم الأسماء العامة والمقسّمة التي عيّنتها لـ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 exit node في قائمة الجهاز ضمن صفحة Machines، بينما تتم الموافقة على الشبكة الفرعية عبر Edit في قسم Subnets الخاص بالجهاز، حيث يفتح ذلك Edit subnet routes. يحتاج كلاهما إلى تفعيل إعادة توجيه IP على VPS. تجنب الإعلان عن نطاق يطابق شبكة حاسوبك المحمول المنزلية، لأن اعتماد هذا المسار وقبول حاسوبك المحمول له قد ينقل عناوينه بعيداً عن شبكتك المحلية، فتصبح أجهزتك المحلية غير قابلة للوصول.

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

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