Tailscale serve أم funnel: أيهما تختار؟

serve وfunnel في Tailscale: من يمكنه الوصول إلى عنوان URL

الفرق بين tailscale serve وtailscale funnel هو الجمهور المستهدف، ولا شيء سواه. يضع serve واجهة أمامية عبر HTTPS (بروتوكول نقل النص التشعبي الآمن) على منفذ محلي، وينشرها إلى tailnet الخاص بك فقط. أما funnel فينشر المنفذ المحلي نفسه إلى كامل الإنترنت العام، عبر خوادم الترحيل التي تديرها Tailscale. يقبل الأمران العلامات والأهداف نفسها. تفصل كلمة واحدة بين لوحة معلومات خاصة وأخرى يمكن للعالم الوصول إليها.

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

ما تحتاج إليه قبل أن يعمل أي من الأمرين

• الإصدار 1.38.3 أو أحدث من Tailscale على VPS، مع تسجيل الدخول إلى tailnet. تحقّق من ذلك باستخدام tailscale version وtailscale status.
• تفعيل MagicDNS. MagicDNS هو نظام DNS المضمّن في Tailscale، وهو الذي يمنح الجهاز اسماً مثل blog-vps.your-tailnet.ts.net بدلاً من اقتصار الوصول إليه على عنوان 100.x.
• تفعيل شهادات HTTPS لـtailnet من صفحة DNS في وحدة تحكم الإدارة. من دون ذلك، لا توجد شهادة تضعها أمام المنفذ.
• بالنسبة إلى funnel فقط، يجب إضافة سمة العقدة funnel إلى ملف سياسة tailnet. هنا تتوقف معظم المحاولات الأولى، ويُشرح ذلك أدناه.

يبدأ كل أمر هنا بـ sudo، لأن CLI يتصل بـtailscaled عبر socket لا يمكن إلا لـroot الكتابة إليه. امنح مستخدماً واحداً صلاحية تجاوز ذلك:

sudo tailscale set --operator=$USER

النشر على tailnet باستخدام tailscale serve

وجّه serve إلى منفذ محلي، وسيتولى الباقي.

sudo tailscale serve 3000

Available within your tailnet:
https://amelie-workstation.pango-lin.ts.net

 |-- / proxy http://127.0.0.1:3000

Press Ctrl+C to exit.

إنّ 3000 المجرّد هو اختصار لـ http://127.0.0.1:3000. يستمع Tailscale على المنفذ 443 لعنوان الجهاز في tailnet، وينهي TLS (أمان طبقة النقل) باستخدام شهادة ts.net، ثم يوجّه HTTP العادي إلى منفذك المحلي. لا يحتاج تطبيقك إلى معرفة وجود شهادة، وهذا هو السبب الرئيسي لاستخدام هذا الأسلوب أمام لوحة إدارة كنت ستتركها بخلاف ذلك على HTTP العادي. وتُعد واجهة الويب التي تستمع على 127.0.0.1 فقط المرشح الواضح لذلك. ومن الأمثلة الجيدة واجهة الويب dsh على المنفذ 3080: بدلاً من فتح نفق SSH في كل مرة تريد فيها الوصول إليها، وجّه serve إلى 3080 مرة واحدة، ثم صِل إليها من أي جهاز في tailnet.

اقرأ الآن السطر الأخير: Press Ctrl+C to exit. يعمل الأمر في الواجهة الأمامية، ويظل الربط داخل هذه العملية. أغلق الطرفية، وسيتوقف عنوان URL عن العمل، لأن شيئاً لم يُكتب على القرص. أضف --bg، وسينتقل الربط إلى إعدادات serve الخاصة بالعقدة، وسيظل قائماً بعد إغلاق الطرفية وإعادة التشغيل.

sudo tailscale serve --bg 3000

لا يقتصر Serve على رقم منفذ. يربط --set-path خدمة بمسار فرعي، ولذلك يمكن لعدة تطبيقات مشاركة اسم مضيف واحد:

sudo tailscale serve --bg --set-path=/grafana 3000
sudo tailscale serve --bg --set-path=/metrics 9090

يمكن أن يكون الهدف أيضاً دليلاً يحتوي على ملفات ثابتة، أو خلفية تتحدث TLS مسبقاً باستخدام شهادة لا تريد التحقق منها:

sudo tailscale serve --bg /srv/reports
sudo tailscale serve --bg https+insecure://localhost:8443

ولا يقتصر الأمر على HTTP. يوجّه --tcp=<port> دفق TCP (بروتوكول التحكم في النقل) خاماً، بينما ينهي --tls-terminated-tcp=<port> TLS على عقدتك ويمرر النص العادي، مما يضع شهادة موثوقة أمام خدمة لا تتحدث HTTP أصلاً:

sudo tailscale serve --bg --tls-terminated-tcp=443 tcp://127.0.0.1:9899

لماذا يعرض funnel أن سمة node غير معيّنة؟

يكون Funnel معطّلاً افتراضياً على مستوى tailnet بالكامل. يعرض التشغيل الأول هذه الرسالة ثم يتوقف:

Funnel not available; "funnel" node attribute not set. See https://tailscale.com/kb/1223/tailscale-funnel/.

الأمر صحيح. لم تمنح سياسة tailnet هذه العقدة الإذن بالنشر، لذلك يرفض العميل الطلب قبل أن يتصل بأي relay. عدّل ملف سياسة tailnet في وحدة تحكم الإدارة، ضمن Access Controls، وأضف السمة:

"nodeAttrs": [
  {
    "target": ["autogroup:member"],
    "attr":   ["funnel"],
  },
],

تمنح autogroup:member هذه الصلاحية لكل عضو في tailnet. إذا كان يجب السماح لجهاز واحد فقط بالنشر، فأضف tag إلى ذلك الجهاز واستهدف الـtag بدلاً من ذلك، مثل tag:public. احفظ السياسة، ثم شغّل أمر Funnel مرة أخرى.

إذا كان حسابك مسؤول tailnet، توفّر الإصدارات الحديثة من العملاء اختصاراً: يطبع CLI عنوان URL للموافقة على login.tailscale.com، ويؤدي فتحه إلى تفعيل شهادات HTTPS وإضافة السمة نيابةً عنك. إذا لم تكن مسؤولاً، فلن يفيدك عنوان URL هذا. يجب أن يجري شخص لديه صلاحية الوصول إلى السياسة هذا التعديل.

النشر على الإنترنت باستخدام tailscale funnel

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

sudo tailscale funnel --bg 3000

Available on the internet:
https://amelie-workstation.pango-lin.ts.net

 |-- / proxy http://127.0.0.1:3000

Press Ctrl+C to exit.

اقرأ ذلك السطر الأول في كل مرة. Available within your tailnet وAvailable on the internet هما الاختلافان الوحيدان الظاهران بين خدمة خاصة وخدمة عامة، وتختلف الأوامر التي تنشئهما بكلمة واحدة.

اعتباراً من August 2026، يستمع funnel على المنفذ 443 أو 8443 أو 10000، ولا يستمع على أي منفذ آخر. القيمة الافتراضية هي 443، و--https=8443 أو --https=10000 هما البديلان. يُرفض أي منفذ آخر، لأن مرحلات funnel تقبل الاتصالات على هذه المنافذ فقط. لذلك يكون عنوان URL الخاص بـfunnel دائماً اسم المضيف مجرداً، أو اسم المضيف متبوعاً بـ:8443.

كيف ترى ما هو منشور حالياً؟

يؤدي التخمين إلى بقاء لوحة معلومات مكشوفة للعامة لمدة شهر. استعلم من العقدة مباشرة.

tailscale serve status
tailscale funnel status
tailscale serve status --json

يقرأ أمرَا الحالة الإعداد نفسه، لذلك يعرض أيٌّ منهما الصورة كاملة. استخدم صيغة --json داخل script أو فحص مجدول، لأن المخرجات العادية مهيأة للقراءة البشرية. عندما لا يكون هناك أي إعداد، تحصل على سطر واحد:

No serve config

إذا رأيت ذلك بعد إعداد تعرف أنه نجح، فهذا يعني أن الربط أُنشئ في الواجهة الأمامية ثم انتهت العملية. أعد إنشاؤه باستخدام --bg.

لإزالة ربط واحد، كرر الأمر الذي أنشأه وأضف off في نهايته. لمسح كل عمليات serve وfunnel على العقدة، استخدم reset.

sudo tailscale funnel --https=443 3000 off
sudo tailscale serve reset

شغّل tailscale serve status مرة أخرى بعد أيٍّ من الأمرين، واقرأ ما تبقى بدلاً من افتراض أن الأمر نفّذ ما قصدته.

ما الذي تحصل عليه، وما الذي تتخلى عنه

المزايا حقيقية، وهي سبب اختيار بعض الأشخاص لهذا الحل بدلاً من Reverse Proxy.

• شهادة تثق بها المتصفحات، مع تجديدها تلقائياً. لا تحتاج إلى تثبيت عميل ACME (بيئة إدارة الشهادات تلقائياً)، ولا إلى تذكّر مهمة التجديد.
• لا تحتاج إلى فتح منفذ وارد في جدار VPS الناري. يتصل tailscaled بالخارج، لذلك يمكن أن يبقى جدار ufw الناري في VPS، الذي يرفض الاتصالات افتراضياً مضبوطاً بالصرامة نفسها.
• لا تحتاج إلى شراء سجل DNS أو توجيهه أو انتظار تفعيله.
• لا تحتاج إلى إعادة توجيه المنافذ. وهذا هو الحل الكامل لجهاز موجود خلف NAT (ترجمة عناوين الشبكة)، وليس VPS يملك عنوان IP عاماً.

التكاليف حقيقية بالقدر نفسه، ويتحمل funnel جميعها.

• الاسم ليس ملكك. يرى الزوار العامون host.your-tailnet.ts.net. لا يدعم Funnel النطاقات المخصصة، لذلك لا يمكنك وضع app.example.com أمامه.
• المسار ليس ملكك. تصل حركة الشبكة أولاً إلى مرحّل Tailscale، ثم يمرّر المرحّل التدفق إلى عقدتك عبر tailnet. توضح Tailscale أن حركة funnel تخضع لحدود نطاق ترددي غير منشورة ولا يمكن ضبطها، لذلك قِس معدل النقل لديك قبل الاعتماد على قيمة معينة.
• عناصر التحكم غير متوفرة. يمنحك Reverse Proxy الذي تديره بنفسك سجلات وصول، وحدوداً لمعدل الطلبات، وحدوداً لحجم الطلبات، ومكاناً لإضافة المصادقة. أما Funnel فيمنحك عنوان URL. ويجب أن تكون كل الوظائف الأخرى داخل تطبيقك.
• قائمة المنافذ ثابتة، كما سبق.

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

أيّهما ينبغي أن تستخدم؟

القاعدة بسيطة.

استخدم serve لكل ما هو داخلي: واجهات الإدارة، ولوحات المعلومات، وواجهة مقاييس لا تريد فهرستها، أو نسخة تجريبية من موقع. عضوية tailnet هي آلية التحكم في الوصول، وهي آلية جيدة. ولا يستطيع جهاز غير موجود في tailnet حتى حل الاسم.

استخدم funnel لرابط تجريبي، أو مستقبِل webhook يجب أن يرسل إليه طرف ثالث طلبات POST، أو callback لـOAuth أثناء التطوير. إنه أسرع طريق إلى عنوان HTTPS عام، وينهيه أمر off واحد. لكن العام يعني عاماً: اسم المضيف ليس سراً، ووجود funnel أمام تطبيق لا يتطلب تسجيل الدخول يجعل الخدمة مفتوحة. يجب أن يصادق كل ما يوجد خلفه على طلباته بنفس العناية التي يحتاج إليها نقطة نهاية Ollama مكشوفة.

استخدم reverse proxy حقيقياً لكل ما تعتبره خدمة إنتاجية. يكون نطاقك وشهادتك وسجلاتك وحدود معدّل الطلبات تحت إدارتك، ولا يوجد طرف آخر في مسار الطلب. يوضّح مقارنة nginx وCaddy وTraefik بوصفها reverse proxy كيفية اختيار أحدها.

أوضاع الفشل، مع النصوص التي ستظهر لك

يرفض Funnel البدء. Funnel not available; "funnel" node attribute not set. مشكلة في السياسة، وليست مشكلة في الأمر. أضف السمة funnel إلى ملف سياسة tailnet، واحفظه، ثم أعد المحاولة.

عمل الأمر، والآن يعرض tailscale serve status القيمة No serve config. أُنشئ الربط في الواجهة الأمامية، ثم انتهت تلك العملية. أعد تشغيل الأمر نفسه مع --bg.

يُحلّ الاسم، لكن لا يستجيب شيء. يوجّه Serve الطلبات إلى الهدف الذي حددته، لذلك إذا لم يكن هناك شيء يستمع على ذلك الهدف، فلن يجد Serve ما يوجّه إليه. تحقّق باستخدام ss -ltnp | grep 3000 على الجهاز نفسه الذي يشغّل tailscaled. السبب الشائع هو أن حاوية تنشر منفذها على عنوان Docker bridge بدلاً من 127.0.0.1، ما يعني أن المضيف لا يرى مستمعاً في الموضع الذي تتوقعه. يوضّح كيفية عمل شبكة Docker Compose مكان وصول المنفذ المنشور فعلياً.

أخطاء الشهادة عند استخدام اسم ts.net. على الأرجح لم تُفعّل شهادات HTTPS لـtailnet. فعّلها في وحدة تحكم الإدارة، ثم شغّل خطوة الشهادة منفردة حتى لا تختلط أخطاؤها بمخرجات Serve:

sudo tailscale cert your-host.your-tailnet.ts.net

يُحمّل Funnel عبر بيانات الهاتف المحمول، لكنه يتصرف بشكل مختلف من جهازك المحمول. جهازك المحمول متصل بـtailnet، لذلك يحل MagicDNS الاسم إلى عنوان 100.x، وتصل إلى الخدمة مباشرةً من دون المرور عبر relay. هذا سلوك صحيح، ويعني أن جهازك المحمول لا يستطيع اختبار إمكانية الوصول العامة إطلاقاً. استخدم curl من جهاز غير متصل بـtailnet.

FAQ

ما الفرق بين tailscale serve وtailscale funnel؟

من يمكنه الوصول إلى النتيجة؟ ينشر tailscale serve منفذاً محلياً على عنوان URL يستخدم HTTPS ولا يمكن للأجهزة الموجودة في tailnet الخاص بك الوصول إليه إلا. وينشر tailscale funnel المنفذ نفسه على عنوان URL يمكن لأي شخص على الإنترنت الوصول إليه، مع توجيه الاتصال عبر خوادم relay التي تديرها Tailscale. تكون الرايات والأهداف مشتركة بينهما. يخبرك السطر الأول من الناتج بأي منهما حصلت: Available within your tailnet أو Available on the internet.

لماذا يقول tailscale funnel إن سمة العقدة غير مضبوطة؟

لأن funnel يكون معطلاً في tailnet إلى أن يفعّله أحد. الرسالة هي Funnel not available; "funnel" node attribute not set.، وتصدر من العميل الخاص بك قبل الاتصال بأي relay. أضف إدخالاً من نوع nodeAttrs يمنح السمة funnel إلى autogroup:member، أو إلى tag إذا كان يجب على جهاز واحد فقط النشر، في ملف سياسة tailnet ضمن Access Controls. ويمكن لمسؤول tailnet بدلاً من ذلك اتباع عنوان الموافقة الذي يطبعه CLI.

ما المنافذ التي يمكن لـ Tailscale Funnel استخدامها؟

المنافذ المتاحة هي 443 و8443 و10000 فقط. المنفذ الافتراضي هو 443، ويمكنك اختيار منفذ آخر باستخدام --https=8443 أو --https=10000. هذا حد تفرضه relay الخاصة بـ funnel، وليس خادمك، لذلك لا يمكن لأي تغيير في الجدار الناري أو الإعدادات على VPS إزالته. لا يخضع tailscale serve لهذا القيد، لأنه لا يغادر tailnet الخاص بك.

هل يبقى عنوان URL الخاص بـ serve أو funnel بعد إعادة التشغيل؟

يبقى فقط إذا استخدمت --bg. من دون ذلك، يعمل الأمر في الواجهة الأمامية، ويطبع Press Ctrl+C to exit.، ويختفي الربط مع انتهاء العملية. ومع --bg، يُكتب الربط في إعدادات serve الخاصة بالعقدة ويعود مع tailscaled بعد إعادة التشغيل. تحقّق باستخدام tailscale serve status؛ إذ يطبع No serve config عندما لا يكون هناك أي إعداد.

هل من الآمن ترك funnel قيد التشغيل؟

هو آمن من ناحية النقل: الاتصال يستخدم HTTPS، ولا يكون أي منفذ مفتوحاً في الجدار الناري لديك. لكنه ليس آمناً بالمعنى المعتاد، لأن عنوان URL عام، وبالتالي يصبح التطبيق الموجود خلفه عاماً أيضاً. اترك funnel قيد التشغيل أمام شيء يصادق على طلباته بنفسه فقط، وأوقفه عند انتهاء العرض التوضيحي أو اختبار webhook، باستخدام الأمر الذي أنشأته مع إضافة off في نهايته.

مصادر سلوك الأوامر المذكور أعلاه هي وثائق Tailscale Serve وFunnel ومرجع CLI على tailscale.com/docs.