هل ينفد الـ VPN من العشوائية؟ ما الذي يُظهره entropy_avail فعلًا

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

لماذا تصمد الأسطورة

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

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

ما يفعله المولّد لكل حزمة

في OpenSSL 3 تُبنى هرمية المولّد الافتراضية من نسخ DRBG تزرع وتعيد الزرع وفق الإعداد والحالة. وفي OpenVPN 2.6 يستمد مسار بيانات AEAD قيمة nonce من رقم تسلسل الحزمة مقترنًا بقيمة ضمنية لكل جلسة، بينما يسحب مسار CBC الأقدم قيمة IV شبه عشوائية لكل حزمة. لا يدعم أي من النمطين قاعدة تقول إن نقل غيغابايت يستهلك غيغابايت من ضجيج النواة الجديد. ويدعم كلاهما فكرة أن توليد المفاتيح والمصافحات هي الموضع الذي يهم فيه الزرع.

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

أين يظهر الانتظار فعليًا

ضع الطوابع الزمنية حول المراحل لا حول الجلسة: الإقلاع والمصادقة وتغيير المفتاح والنقل. الانتظار قبل أن يصبح النفق صالحًا للاستخدام شكوى مختلفة عن معدل مستقر منخفض، وواحد منهما فقط يشير إلى العشوائية. على Linux قد يمنع طلب getrandom() عادي حتى يُهيّأ المصدر العشوائي للنواة، ولهذا تكون نسخة هذا المشكلة المتعلقة بالإقلاع حقيقية على الآلات الافتراضية والألواح المدمجة التي لديها القليل لتغذية المجمّع مبكرًا.

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

cat /proc/sys/kernel/random/entropy_avail
uname -r

طابق التصحيح مع القراءة

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

ss -tin dst 203.0.113.7
sar -n DEV 1 5

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