نشر تطبيقك بلا فتح منافذ: Cloudflare Tunnel على سيرفرات مرام هوست

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

الطريقة المعتادة هي فتح المنفذين 80 و443 ثم حماية ما خلفهما. أما Cloudflare Tunnel فيقلب الاتجاه: لا يدخل أحد إلى السيرفر، بل يخرج السيرفر بنفسه ويفتح اتصالاً إلى شبكة Cloudflare، ومن هذا الاتصال تصل طلبات الزوّار إلى تطبيقك. في هذا المقال نشرح متى تفيدك هذه الطريقة، وكيف تطبّقها على سيرفر Linux، وأين تقف حدودها.

الفكرة: اتصال يخرج بدل منفذ ينتظر

تثبّت على السيرفر برنامجاً صغيراً اسمه cloudflared. يبدأ البرنامج اتصالات صادرة مشفّرة نحو Cloudflare ويبقيها مفتوحة. حين يطلب زائر app.example.com يصل طلبه إلى Cloudflare أولاً، فتمرّره عبر تلك الاتصالات إلى cloudflared، وهو بدوره يسلّمه إلى تطبيقك على عنوان محلي مثل localhost:3000.

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

التطبيق خطوة بخطوة

المثال التالي افتراضي: تطبيق يعمل على app-01 بالمنفذ 3000، ونطاق example.com تُدار أسماؤه في Cloudflare. بعد تثبيت cloudflared من مستودع Cloudflare الرسمي:

# سجّل الدخول وأنشئ النفق
cloudflared tunnel login
cloudflared tunnel create app-01

# اربط اسم النطاق بالنفق
cloudflared tunnel route dns app-01 app.example.com

ثم أنشئ ملف الإعداد /etc/cloudflared/config.yml:

tunnel: <TUNNEL-ID>
credentials-file: /etc/cloudflared/<TUNNEL-ID>.json

ingress:
  - hostname: app.example.com
    service: http://localhost:3000
  - service: http_status:404

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

cloudflared tunnel ingress validate
sudo cloudflared service install
sudo systemctl enable --now cloudflared

أغلق المنافذ فعلاً، وإلا فلا فائدة

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

1. اجعل التطبيق يستمع على localhost فقط.
2. ارفض الوارد افتراضياً في جدار السيرفر، واترك الصادر مفتوحاً كي يعمل النفق.
3. لا تفقد طريقك إلى السيرفر: اجعل SSH عبر شبكة خاصة مثل WireGuard قبل إغلاق منفذه العام.

# مثال ufw: نترك SSH عبر واجهة النفق الخاص فقط
ufw default deny incoming
ufw default allow outgoing
ufw allow in on wg0 to any port 22 proto tcp
ufw enable

النفق لا يغني عن شبكة إدارة

يحدث خلط شائع بين النفقين. Cloudflare Tunnel ممتاز لنشر تطبيق ويب للعموم، وWireGuard ممتاز لربط موظفيك وأجهزتك بشبكة خاصة. كل منهما يحل مشكلة مختلفة، وغالباً تستعملهما معاً: الزوار يمرّون عبر الأول، وفريقك يصل إلى SSH وقاعدة البيانات عبر الثاني. وقد شرحنا بناء الثاني في دليل خادم WireGuard على Proxmox.

حدود يجب أن تعرفها قبل القرار

• التشفير ينتهي عند Cloudflare: الاتصال مشفّر في مرحلتيه، لكن Cloudflare تفك تشفيره لتمريره. قيّم ذلك إن كانت بياناتك حساسة أو تخضع لعقود خاصة.
• نقطة اعتماد جديدة: إن تعطّل الطريق إلى Cloudflare توقف الوصول إلى تطبيقك، حتى لو كان سيرفرك سليماً.
• حدود الخطة: حجم الرفع وأنواع الحركة تتبع شروط خطتك. راجعها إن كان تطبيقك يرفع ملفات كبيرة.
• عنوان الزائر: يصل تطبيقك الطلب من العنوان المحلي، والعنوان الحقيقي في الترويسة CF-Connecting-IP. عدّل السجلات وحدود الطلبات لتقرأها.
• الأمان لا ينتقل كله: ثغرة في تطبيقك تبقى قابلة للاستغلال عبر النفق. التحديث والمصادقة ما زالا مسؤوليتك.

النفق لا يسرّع تطبيقاً بطيئاً

كثيرون يبحثون عن سبب البطء في الطريق، بينما هو في السيرفر. زمن الشبكة في العراق بين 70 و150ms، أما توليد الصفحة فيتراوح بين 150ms وأكثر من ثانيتين حسب العتاد. أي أن المسافة تكلّف عشرات الملّي ثانية والعتاد الضعيف يكلّف آلافاً. لذلك اسأل عن المعالج والتخزين، لا عن المدينة وحدها. وضمن عتاد مرام هوست معالجات AMD EPYC 9655 (Zen 5) وAMD EPYC 9684X بذاكرة 3D V-Cache سعة 1152MB L3؛ راجع صفحة الخدمة لمعرفة العتاد في كل باقة.

لمن تناسب هذه الخدمة؟

• فريق يطلق تطبيق ويب أو API ويريد تقليل ما يظهر للإنترنت.
• لوحات داخلية تحتاج نشراً محدوداً مع طبقة دخول إضافية من Cloudflare Access.
• مطوّر يدير عدة تطبيقات على سيرفر واحد ويريد ربطها بأسماء نطاقات بسهولة.

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

أخطاء شائعة

• ترك التطبيق مفتوحاً على العنوان العام بعد تشغيل النفق، فيبقى الباب القديم كما هو.
• نسيان قاعدة 404 الأخيرة في ملف الإعداد، أو تعريف الأسماء بترتيب خاطئ.
• إغلاق SSH قبل تجهيز طريق بديل، ثم فقدان الوصول إلى السيرفر.
• إبقاء سجلات DNS قديمة تكشف عنوان السيرفر الحقيقي.
• حفظ ملف اعتماد النفق في مستودع الكود. من يحصل عليه يستطيع تشغيل النفق نفسه.

أسئلة شائعة

هل أحتاج عنواناً عاماً ثابتاً على السيرفر؟

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

هل يمكنني نشر عدة تطبيقات عبر نفق واحد؟

نعم. أضف قاعدة hostname لكل تطبيق في ملف الإعداد، واجعل قاعدة 404 في الأخير دائماً.

ماذا لو توقف برنامج cloudflared؟

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

ابدأ بسيرفر مناسب لتطبيقك

النفق لا يحتاج موارد كبيرة، فالموارد يحتاجها تطبيقك. إن كان مشروعك في بدايته فابدأ من باقات VPS في العراق، وإن كنت تشغّل منتج SaaS فراجع سيرفرات SaaS. ولاختيار الباقة المناسبة تواصل مع فريق المبيعات.