لماذا قد تكون حزمة VPN المشفَّرة أقل كلفة مما تظن

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

العَرَض: الملف المشفَّر ليس هو البطيء

افترض أن اختبارًا قديمًا يقارن شيفرة AEAD بوضع ”بلا تشفير“ لا يزال يحسب رمز تحقق منفصلًا لكل حزمة. الملف الثاني يخفي محتوى الحمولة لكنه يحتفظ بتجزئة لكل حزمة، وعلى معالج بلا تسريع لتلك التجزئة قد يكلّف أكثر من البناء المتكامل الذي كان يُفترض أن يتفوق عليه.

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

هذا هو التفسير كله، ولا يتطلب أي زعم بأن إحدى البدائيات أسرع عالميًا. كلتاهما قد تكون سريعة، وكلتاهما قد تكون بطيئة، والترتيب يعتمد على الآلة والشيفرة.

عُدّ العمليات، لا التسميات

بناء AEAD، كما وصفه RFC 5116، يمنح التطبيق واجهة واحدة تعيد النص المشفَّر والوسم معًا. AES-GCM مثال على ذلك: تشفير بوضع العدّاد مدموجًا بمُصادِق Galois. الواجهة لا تجعل السلامة مجانية، بل تجعل الدمج محددًا جيدًا، وهذا ما يسمح للتطبيق بتحسين الزوج كوحدة واحدة.

Separate authentication path:
  payload -> independent HMAC -> framed packet

AEAD path:
  payload -> authenticated encryption with tag -> framed packet

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

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

ما يتيحه الوضع المتفاوض عليه فعليًا

مع Community OpenVPN، تعني شيفرة بيانات AEAD أن خيار auth لم يعد يسهم بـ HMAC منفصل لقناة البيانات. يصف مرجع خيار التشفير ذلك النطاق، وهو سبب اختلاف إعدادين متشابهين في ملف نصي في العمل لكل حزمة.

اقرأ الوضع المتفاوض عليه بدل قائمة الأمنيات. قائمة الشيفرات المسموح بها واسم حزمة TLS لا يخبرانك أي العمليات تُنفَّذ على الحمولة، وقد لا يصف سطر cipher القديم ما اختاره الاتصال الحالي.

openvpn --show-ciphers | head -20
sudo grep -E 'cipher|auth' /etc/openvpn/server.conf

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

قِس العمل الذي تنفّذه فعلًا

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

openssl speed -evp aes-256-gcm
openssl speed -evp sha1

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

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

أبقِ الهدف في الاعتبار أيضًا. مسار بيانات لديه طاقة تشفيرية فائضة قد يظل مقيّدًا بالزمن لأن التطبيق ينتظر رحلات الذهاب والإياب، ومكاسب الطاقة الكبيرة لا تصلح بروتوكولًا كثير الكلام. قِس الإعداد المدعوم والمُعتمد سياسيًا ككل، وعامل ”عدد أقل من الصناديق يجب أن يكون أسرع“ كفرضية هو كذلك. السؤال المفيد ليس هل يكلّف التشفير شيئًا، بل هل تظهر الكلفة في القياس الذي يهمك فعلًا.