Cloudflare أطلقت Mesh لتحل محل VPN: تتيح للوكلاء الذكيين الوصول الآمن إلى شبكتك الداخلية، وتوفر 50 عقدة مجانًا

كريپت كلاود في Agents Week 2026 يطلق رسميًا Cloudflare Mesh، ليحل محل الشبكة التقليدية VPN و SSH Tunnel بهيكل شبكة متعدد الاتجاهات ومتعدد النقاط، مما يسمح لوكيل الذكاء الاصطناعي بالوصول المباشر إلى البنية التحتية الخاصة ضمن إطار سياسة الثقة الصفرية، ويوفر خطة بداية مجانية من 50 عقدة.
(مقدمة سابقة: بعد دمج Cloudflare مع Kimi K2.5، تتعامل يوميًا مع 7 مليارات رمز، مع توفير 77% من تكاليف التدقيق الأمني)
(معلومات إضافية: هل اختارت Cloudflare Coinbase أم Stripe؟ هذا القرار سيحدد معيار دفع وكلاء الذكاء الاصطناعي)

فهرس المقال

Toggle

• الثغرة القاتلة في VPN: يفترض أنك دائمًا متواجد
• الأساس التقني لـ Mesh: ثنائي الاتجاه، عالمي، يتجاوز NAT تلقائيًا
• تطبيق سياسة الثقة الصفرية تلقائيًا على حركة الوكيل
• خارطة الطريق والوعود غير المحققة
• ما يمكن للمطورين القيام به الآن

في الثالثة صباحًا، يحاول وكيل الذكاء الاصطناعي الخاص بك إصدار أول 10,000 طلب API، بينما لا يزال VPN يفتح نوافذه، في انتظار تسجيل الدخول اليدوي.

هذه هي الحالة الواقعية لفريق الهندسة في عام 2026، عندما يبدأ وكيل الذكاء الاصطناعي في استعلام قواعد البيانات والتواصل مع الخدمات الخاصة، نكتشف أن أدوات الشبكة الحالية (VPN، SSH، Bastion Host) كلها مصممة للبشر. فهي تتطلب نقرات، وتفاعلات، وتدخل بشري.

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

لهذا السبب، أطلقت Cloudflare في اليوم (14) من فبراير خلال فعاليتها السنوية “Agents Week 2026” رسميًا Cloudflare Mesh، معلنة أنها ستسد هذا الثغرة، باستخدام بنية شبكة خاصة مصممة أصلاً لوكلاء الذكاء الاصطناعي، لتحل محل الأدوات القديمة التي وُجدت للتفاعل اليدوي.

الثغرة القاتلة في VPN: يفترض أنك دائمًا متواجد

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

الوكيل لا ينتظر تفاعل MFA التفاعلي. لا يمكنه إعداد نفق SSH يدويًا. والأهم من ذلك، بمجرد إنشاء اتصال VPN، لا توجد آلية لمعرفة ما يفعله الوكيل على الطرف الآخر: يمكنه خلال أجزاء من الثانية مسح البيانات التي لم تتوقع أن يلمسها.

خيار آخر هو كشف الخدمة على الإنترنت، لكن ذلك يعادل وضع المفتاح في الباب. في الإعلان، أشارت Cloudflare مباشرة إلى أن هذه الطرق الثلاثة لها نقطة ضعف مشتركة: “لا يمكن لهذه الحلول أن تراقب بشكل فعلي ما يفعله الوكيل بعد الاتصال.”

تصميم Cloudflare Mesh يبدأ بحل مشكلة الرؤية قبل الحديث عن الاتصال.

الأساس التقني لـ Mesh: ثنائي الاتجاه، عالمي، يتجاوز NAT تلقائيًا

مقارنة مع منتج Cloudflare الحالي Cloudflare Tunnel، الاختلاف الرئيسي في الهيكل هو الاتجاهية.

Tunnel هو اتجاه واحد: يتدفق المرور من الخارج إلى بنيتك التحتية. أما Mesh فهو متعدد الاتجاهات ومتعدد النقاط (bidirectional, many-to-many): يمكن لأي عقدة أن تبدأ اتصالًا نشطًا مع أي عقدة أخرى، ويتم توجيه المرور عبر شبكة Cloudflare التي تغطي 330 مدينة حول العالم.

هذا التصميم يعالج مباشرة المشكلة الأكثر إزعاجًا للمهندسين في بيئة الشركات: تجاوز NAT. شبكات المنازل، جدران حماية المكاتب، VPC السحابية: غالبًا ما تتطلب إعدادات يدوية لقواعد التوجيه، لكن Mesh يدعي أنه يعالجها تلقائيًا بالكامل.

بالنسبة للمطورين، فإن التكامل مع منصة Cloudflare Developer Platform هو الحافز الأكثر مباشرة. فقط عند ربط Mesh في ملف wrangler.jsonc، يمكن لـ Workers و Durable Objects استدعاء خدمات خاصة عبر env.MESH.fetch()، تمامًا كما تستدعي أي API خارجي — لكن المرور لا يترك Cloudflare ضمن إطار سياسة الثقة الصفرية.

كما تم توحيد العلامة التجارية على مستوى الأسماء: تم تغيير اسم WARP Connector إلى “Node Cloudflare Mesh”، وWARP Client إلى “Cloudflare One Client”، لتوحيدها ضمن خط منتجات Mesh.

تطبيق سياسة الثقة الصفرية تلقائيًا على حركة الوكيل

تؤكد Cloudflare أن Mesh ليس منتجًا جديدًا مستقلًا، بل هو امتداد أصلي لمجموعة Cloudflare One SASE.

هذا يعني أن سياسات Gateway الحالية، وفحوصات صحة الأجهزة، ووقاية تسرب البيانات (DLP)، يمكن تطبيقها تلقائيًا على حركة الوكيل دون إعادة إعداد.

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

من ناحية التسعير، تقدم Cloudflare حدًا مجانيًا مرنًا: يمكن لأي حساب Cloudflare استخدام 50 عقدة و50 مستخدم مجانًا، مما يجعل سيناريو “الوصول الوكيل إلى المختبر المنزلي” مناسبًا جدًا للشركات الصغيرة والمطورين الأفراد.

خارطة الطريق والوعود غير المحققة

من الجدير بالذكر أن العديد من الوظائف الأساسية التي تم وصفها بشكل موسع في إعلان Cloudflare لا تزال في قائمة الخطط وليست متاحة بعد.

• توجيه اسم المضيف (Hostname Routing) — تمكين الوكيل من استخدام أسماء نطاقات داخلية مثل wiki.local وapi.staging.internal للوصول مباشرة، من المتوقع أن يُطلق في صيف 2026
• DNS Mesh — تخصيص أسماء مضيفين لكل عقدة بصيغة postgres-staging.mesh، وسيأتي لاحقًا
• توجيه معتمد على الهوية (Identity-Aware Routing) — القدرة على تمييز ما إذا كانت الحركة من الوكيل الرئيسي (Principal)، أو الراعي (Sponsor)، أو الوكيل الفرعي (Agent)، وهذه الوظيفة لا تزال في مرحلة “الخطة”، ولا يوجد جدول زمني محدد لها

دعم الحاويات (Docker، Kubernetes، بيئات CI/CD لنشر عقد Mesh) أيضًا يتوقع أن يكون متاحًا بحلول نهاية 2026.

بمعنى آخر، ما يمكن استخدامه اليوم من Mesh هو بشكل رئيسي ربط VPC مع Workers/Durable Objects، والقدرة الأساسية على الاتصال بين العقد. أما إدارة هوية الوكيل بشكل أكثر تفصيلًا، فستتطلب وقتًا أطول.

ما يمكن للمطورين القيام به الآن

بالنسبة للفِرق الموجودة ضمن منظومة Cloudflare One، لا حاجة لتقديم طلب خاص، يمكن تفعيل Mesh مباشرة في الحساب الحالي. يتطلب دمج VPC مع Workers تعديل ملف wrangler.jsonc، ثم يمكن استدعاء الخدمات الخاصة عبر env.MESH.fetch().

أما الفرق التي لا تزال تقيّم، فإن السيناريو الأفضل حاليًا للاختبار هو: السماح لوكيل الترميز بالوصول إلى قاعدة بيانات staging، أو تمكين الوكيل المستضاف في السحابة من استدعاء API داخل الشبكة الداخلية للمكتب، ويمكن اختبار هذين السيناريوهين من الآن.

قبل إطلاق توجيه اسم المضيف، لا تزال طرق الاتصال المباشر عبر ip:port هي الخيار الرئيسي، رغم أنها ليست مثالية، لكنها قابلة للاستخدام. أما تجربة حل اسم النطاق التي تجعل الوكيل “يشعر وكأنه في الشبكة الداخلية”، فستكون متاحة بعد الصيف.