المقدمة
إذا كنت قد اطّلعت من قبل على V2Ray أو أدوات الوكيل (proxy) المقاومة للرقابة، فمن المرجح أنك صادفت مصطلح VMess. إنه البروتوكول الأصلي الذي يشكّل جوهر V2Ray، وفهم آلية عمله يمنحك صورة أوضح عن سبب فعالية الاتصالات القائمة على V2Ray في بيئات الشبكات المعادية.
VMess ليس بروتوكول VPN بالمعنى التقليدي. إنه بروتوكول وكيل صُمم من الأساس لمقاومة تحليل حركة البيانات والفحص العميق للحزم (DPI). في هذا الدليل، سنشرح كيف يعمل VMess، وكيف يشفّر البيانات، وكيف يختلف عن شقيقه الأحدث VLESS، ولماذا يهم تصميمه في تجاوز الرقابة على أرض الواقع.
VMess ومشروع Project V
VMess (اختصار لـ V2Ray Mess، رغم أن التسمية غير رسمية) هو البروتوكول الأصلي الذي طُوّر كجزء من Project V، والذي انطلق عام 2015. أُنشئ Project V بشكل أساسي على يد مطورين في مجتمع حرية الإنترنت الصيني، الذين احتاجوا إلى أداة قادرة على الصمود أمام أساليب الرصد المتطورة باستمرار لدى جدار الحماية العظيم.
أدرك المشروع أن بروتوكولات VPN التقليدية مثل OpenVPN وPPTP تحمل بصمات حركة بيانات يمكن التعرف عليها، بحيث تستطيع أنظمة الرقابة رصدها وحظرها. صُمم VMess خصيصًا لتجنب خلق مثل هذه البصمات مع الاستمرار في توفير اتصال مُصادَق عليه ومشفّر.
كيف تعمل مصادقة VMess
يستخدم VMess نظام مصادقة قائمًا على UUID بدلاً من المصادقة التقليدية باسم المستخدم/كلمة المرور أو الشهادات.
UUID كهوية
يُحدَّد كل اتصال VMess بواسطة UUID (معرّف فريد عالمي)، وهو قيمة من 128 بت تبدو كالتالي: b831381d-6324-4d53-ad4f-8cda48b30811. يجب أن يتشارك كل من العميل والخادم نفس الـ UUID لقبول الاتصال.
لا يُرسل هذا الـ UUID أبدًا بنص صريح. بل يُستخدم كجزء من عملية توليد المفتاح لتشفير طلب الاتصال.
مصافحة قائمة على الطابع الزمني
يستخدم VMess آلية مصادقة تعتمد على الوقت. يُنشئ العميل رمز مصادقة عن طريق تجزئة الطابع الزمني الحالي (بتوقيت UTC) مع الـ UUID باستخدام HMAC-MD5. يجب أن تكون ساعة العميل ضمن هامش 30 ثانية من وقت الخادم لنجاح المصادقة. من جانب الخادم، يتحقق VMess من الطوابع الزمنية الواردة ضمن نافذة زمنية مدتها 120 ثانية (60 ثانية قبل وبعد الوقت الحالي) لمراعاة تأخيرات الشبكة وانحراف الساعة الطفيف.
يخدم هذا التصميم غرضين:
- الحماية من إعادة التشغيل (Replay Protection) — كل رمز مصادقة صالح فقط لنافذة زمنية قصيرة، مما يمنع إعادة تشغيل الحزم الملتقطة لاحقًا
- لا مصافحة ثابتة — تتغير بيانات المصادقة مع كل محاولة اتصال، مما يجعل من المستحيل على أنظمة DPI إنشاء بصمة ثابتة لمصافحات VMess
يعني الاعتماد على تزامن الوقت أن ساعتي العميل والخادم يجب أن تكونا متوافقتين بشكل معقول. ورغم أن نافذة التحقق لدى الخادم توفّر بعض التسامح مع تأخيرات الشبكة، فإن انحراف ساعة العميل بأكثر من 30 ثانية يتسبب عادةً في فشل الاتصال - وهي مشكلة استكشاف أخطاء شائعة لدى مستخدمي VMess.
تشفير VMess
يطبّق VMess طبقة تشفير خاصة به مستقلة عن أي تشفير على مستوى النقل. هذا يعني أن البيانات تُشفَّر حتى لو لم توفّر طبقة النقل الأساسية تشفيرًا (رغم أن TLS يُستخدم في الممارسة العملية دائمًا تقريبًا أيضًا).
اختيار تلقائي للتشفير
يختار VMess تلقائيًا خوارزمية التشفير بناءً على عتاد العميل:
- AES-128-GCM على أنظمة x86/x64 (أجهزة سطح المكتب، والحواسيب المحمولة، ومعظم الخوادم) — يستفيد من تسريع AES بالعتاد (AES-NI) المتوفر في معالجات إنتل وأي إم دي الحديثة
- ChaCha20-Poly1305 على أجهزة ARM والأجهزة المحمولة — مُحسَّن للمعالجات التي لا تملك تعليمات AES مخصصة بالعتاد، وهو شائع في الهواتف الذكية والأجهزة القائمة على ARM
كلا الخوارزميتين من نوع التشفير الموثّق مع بيانات مرتبطة (AEAD)، بمعنى أنهما توفران حماية السرية والسلامة في عملية واحدة. يضمن هذا الاختيار التلقائي أداءً مثاليًا عبر أنواع الأجهزة المختلفة دون الحاجة إلى إعداد يدوي.
اشتقاق المفاتيح
تُشتق مفاتيح التشفير لكل جلسة من الـ UUID ومكوّن عشوائي. يستخدم كل اتصال مفاتيح جلسة فريدة مشتقة من الـ UUID ومكونات عشوائية، لذا فإن اعتراض المفاتيح المشتقة لجلسة واحدة لا يكشف مباشرة بيانات جلسات أخرى. لكن هذا لا يعادل السرية التامة الأمامية (forward secrecy) الحقيقية - إذا تم اختراق الـ UUID، فقد يصبح من الممكن نظريًا فك تشفير الجلسات الملتقطة سابقًا.
بنية حزمة VMess
فهم كيفية تنظيم VMess لبياناته يساعد في تفسير سبب مقاومته لتحليل حركة البيانات.
رأس الطلب (Request Header)
يتكون طلب العميل الأولي من:
- بايتات المصادقة — تجزئة HMAC-MD5 للطابع الزمني (16 بايت)
- رأس طلب مشفّر — يحتوي على الأمر (TCP/UDP)، وعنوان الوجهة، والمنفذ، ومفاتيح تشفير عشوائية مولّدة للجلسة
- حشو الرأس (Header Padding) — حشو بطول عشوائي لمنع أخذ بصمة بحجم ثابت
يُشفَّر رأس الطلب باستخدام AES-128-CFB، مع مفتاح مشتق من الـ UUID. لا يمكن فك تشفير هذا الرأس إلا لخادم يملك الـ UUID الصحيح.
شرائح البيانات (Data Chunks)
بعد المصافحة، تُنقل البيانات على شكل شرائح (chunks). تتضمن كل شريحة:
- حقل الطول (بايتان، مشفّر) — حجم مقطع البيانات
- علامة المصادقة — التحقق من سلامة الشريحة
- الحمولة المشفّرة — البيانات الفعلية، مشفّرة بمفاتيح الجلسة
يساعد النقل القائم على الشرائح ذات الأطوال المتغيرة على منع تحليل حركة البيانات بناءً على أحجام الحزم. وعلى عكس البروتوكولات ذات البنى الثابتة للحزم، لا تحمل تدفقات بيانات VMess أنماط أحجام يسهل التعرف عليها.
رأس الاستجابة (Response Header)
تستخدم استجابة الخادم مفتاحًا مختلفًا مشتقًا من الطلب، مما يضمن عدم إمكانية ربط حركة بيانات الطلب والاستجابة من خلال مطابقة أنماط تشفير بسيطة.
استقلالية طبقة النقل
من أهم سمات تصميم VMess فصله عن طبقة النقل. يحدد VMess كيفية مصادقة البيانات وتشفيرها، لكنه لا يفرض كيفية وصول تلك البيانات إلى الخادم. هذه المعيارية تتيح لـ VMess العمل عبر خيارات نقل متعددة:
- WebSocket — الخيار الأكثر شيوعًا لتجاوز الرقابة. تُنقل بيانات VMess داخل اتصال WebSocket، والذي يعمل بدوره فوق HTTP/HTTPS. بالنسبة للمراقبين على الشبكة، يبدو هذا كاتصال تطبيق ويب دائم.
- gRPC — يظهر كحركة بيانات API قياسية، شائعة في تطبيقات الويب الحديثة. مفيد في البيئات التي تُفحص فيها حركة بيانات WebSocket عن كثب.
- HTTP/2 — تدفقات متعددة الإرسال عبر اتصال TLS واحد، تحاكي أنماط تصفح الويب الحديثة.
- QUIC — نقل قائم على UDP يشبه حركة بيانات بروتوكول QUIC الخاص بجوجل.
- TCP خام — اتصال TCP مباشر مع TLS اختياري. أقل تمويهًا لكن بحمل زائد أقل، مناسب للشبكات غير المقيّدة.
استقلالية النقل هذه تعني أنه إذا طوّرت أنظمة الرقابة أساليب رصد لطبقة نقل معينة، يمكن للمستخدمين التحوّل إلى أخرى دون تغيير إعدادات بروتوكول VMess الأساسية.
VMess مقابل VLESS
قُدِّم VLESS كبديل أحدث لـ VMess ضمن منظومة V2Ray. فهم الاختلافات بينهما يساعد في تفسير تطوّر البروتوكول.
VMess: تشفير مدمج
يتضمن VMess طبقة تشفير خاصة به. حتى بدون TLS على مستوى النقل، تظل بيانات VMess مشفّرة. كان هذا خيار تصميم متعمدًا - في الأيام الأولى لمشروع Project V، لم تكن جميع خيارات النقل تدعم التشفير، لذا كان وجود التشفير على مستوى البروتوكول أمرًا ضروريًا.
VLESS: تشفير مُفوَّض
يزيل VLESS التشفير على مستوى البروتوكول ويُفوّضه بالكامل إلى طبقة النقل (عادةً TLS 1.3). المنطق هو أن عمليات النشر الحديثة تستخدم TLS دائمًا تقريبًا، مما يجعل طبقة التشفير الإضافية في VMess زائدة عن الحاجة. بإزالتها، يقلل VLESS الحمل الزائد ووقت المعالجة.
الاختلافات الرئيسية
| الميزة | VMess | VLESS | |---------|-------|-------| | تشفير مدمج | نعم (AES-128-GCM / ChaCha20) | لا (يعتمد على TLS في طبقة النقل) | | المصادقة | UUID + HMAC للطابع الزمني | UUID فقط | | الحمل الزائد | أعلى (تشفير مضاعف مع TLS) | أقل (طبقة TLS واحدة) | | بدون TLS | يظل مشفّرًا | غير مشفّر (غير موصى به) | | النضج | أقدم، وأكثر اختبارًا | أحدث، وأبسط |
أيهما أفضل؟
ليس أي منهما متفوقًا بشكل مطلق في كل الحالات. يوفّر VMess دفاعًا متعدد الطبقات - حتى لو تم اختراق طبقة TLS بطريقة ما، يظل تشفير VMess يحمي البيانات. أما VLESS فهو أخف وزنًا وأسرع قليلًا، لكنه يعتمد كليًا على طبقة النقل من أجل الأمان.
لاحظ بعض الباحثين الأمنيين نقاط ضعف نظرية في آلية مصادقة VMess، وأوصوا باستخدام VLESS+TLS كإعداد مفضّل. عمليًا، يظل كلاهما مستخدمًا على نطاق واسع وفعّالًا.
قيود VMess
من المهم أن نكون شفافين بشأن القيود:
- الحمل الزائد — التشفير المضاعف (VMess + TLS) يضيف حملًا زائدًا في المعالجة مقارنة بـ VLESS أو الوكيل المباشر عبر TLS. على العتاد الحديث، هذا ضئيل، لكنه قابل للقياس على الأجهزة محدودة الموارد.
- الحساسية لدقة الساعة — تتطلب المصادقة القائمة على الطابع الزمني تزامن الساعات. انحراف الساعة مصدر شائع لمشاكل الاتصال.
- حالة التدقيق — لم يخضع VMess لنفس مستوى التدقيق الأمني الرسمي والمستقل الذي خضعت له بروتوكولات مثل OpenVPN أو WireGuard. أمانه مبني على عناصر تشفير أساسية معروفة جيدًا، لكن تطبيق البروتوكول نفسه لم يخضع لنفس القدر من التمحيص.
- اتجاه نحو التقادم — تحوّل بعض أعضاء مجتمع V2Ray نحو VLESS+TLS كإعداد موصى به، معتبرين أن التشفير المدمج في VMess حمل زائد غير ضروري في عمليات النشر الحديثة.
كيف يستخدم EdgeVPN بروتوكول VMess
يطبّق EdgeVPN بروتوكول VMess مع WebSocket+TLS كأحد خيارات بروتوكوله القائم على V2Ray. يوفّر هذا الإعداد:
- مصادقة وتشفير VMess لطبقة الوكيل
- WebSocket للنقل، مما يجعل حركة البيانات تبدو كتواصل ويب قياسي
- TLS مع شهادات صالحة لتشفير طبقة النقل وتمويه إضافي
هذا النهج متعدد الطبقات يعظّم التوافقية والمرونة في بيئات الشبكات المقيّدة. يتولى تطبيق EdgeVPN جميع تفاصيل الإعداد، لذا لا يحتاج المستخدمون إلى إدارة ملفات إعداد JSON أو ضبط الشهادات يدويًا.
الخاتمة
يمثّل VMess نهجًا مدروسًا لتصميم بروتوكولات الوكيل. من خلال الجمع بين المصادقة القائمة على الوقت، والاختيار التلقائي للتشفير، ونقل البيانات على شكل شرائح، واستقلالية طبقة النقل، يُنشئ اتصالات أصعب بشكل أساسي في رصدها وحظرها مقارنة ببروتوكولات VPN التقليدية.
ورغم أن بروتوكولات أحدث مثل VLESS تقدّم بدائل أخف وزنًا، يظل VMess خيارًا قادرًا ومنتشرًا على نطاق واسع. فهم آلية عمله من الداخل يساعدك على تقدير سبب إثبات الأدوات القائمة على V2Ray مرونة أكبر في البيئات الخاضعة للرقابة مقارنة بحلول VPN التقليدية.