Tailscale Serve مقابل Funnel: من يستطيع فعليًا فتح الرابط؟

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

Serve يجيب على سؤال داخل شبكة tailnet

يعمل Serve كوسيط لمنفذ محلي أو يقدّم محتوى محليًا للأجهزة الموجودة في شبكتك، ولا تزال قواعد الوصول الخاصة بالشبكة تنطبق على كل طلب. تصبح لوحة تحكم على المنفذ 3000 متاحة عبر اسم HTTPS لا تستطيع حلّه والاتصال به إلا أجهزتك. هذا هو الإعداد الافتراضي الصحيح للأدوات الداخلية، لأن الجمهور موثَّق بالفعل عبر الشبكة وأنت لا تضيف واجهة عامة. يبدو الرابط كموقع ويب عادي، ولهذا بالضبط يظنّه الناس موقعًا كذلك.

يستطيع Serve أيضًا إرفاق ترويسات هوية تصف مستخدم الشبكة بالطلبات التي يمرّرها. إذا كان تطبيقك يثق بتلك الترويسات كمصادقة، فاربط الخادم الخلفي بـ localhost حتى لا يصل إليه أي شيء آخر مباشرة، فالخادم الخلفي الذي يستمع على عنوان قابل للتوجيه يمكنه استقبال طلبات لم تمر قط عبر الوسيط.

Funnel يغيّر الجمهور إلى الإنترنت المفتوح

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

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

اقرأ الوضع من العميل، لا من المنفذ

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

tailscale serve status
tailscale funnel status
tailscale status --json | head -40

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

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

اختبر مع الجمهور الذي قصدته فعلًا

اختبر من خارج الشبكة، لا من الجهاز الذي نشر الخدمة. الطلب من جهاز داخل الشبكة يثبت أن الوسيط يعمل، لكنه لا يثبت استبعاد أي غريب. استخدم شبكة لا تحتوي على عميل Tailscale ولا مسار إلى الشبكة.

curl -sI https://host.tailnet-name.ts.net
curl -sI https://host.tailnet-name.ts.net --resolve host.tailnet-name.ts.net:443:203.0.113.10

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

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