هل ضعف إنتاجية VPN مشكلة إنتروبيا؟ في العادة لا

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

عَرَضان يبدوان متشابهين

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

ضع طوابع زمنية حول الإقلاع والمصادقة وإعادة تفاوض المفاتيح والنقل نفسه. التأخير الطويل قبل أن يصبح النفق صالحًا للاستخدام ليس معدلًا منخفضًا ثابتًا، ومتوسط الاثنين في رقم واحد يدمّر الدليل.

systemd-analyze blame | head -10
journalctl -u [email protected] -o short-precise | head -40
cat /proc/sys/kernel/random/entropy_avail

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

كيف يبدو انتظار الأرقام العشوائية فعليًا

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

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

strace -f -e trace=getrandom -p $(pidof openvpn) 2>&1 | head -20
dmesg | grep -i 'random\|crng'

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

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

كيف يبدو البطء المستمر فعليًا

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

قِس في الاتجاهين بخط أساس قابل للمقارنة، وراقب عدّادات الواجهة بدلًا من تقرير التطبيق نفسه.

ss -tin dst 203.0.113.10
nstat -az | grep -i 'drop\|retrans'
ethtool -S eth0 | grep -i 'drop\|error'

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

اختر التصحيح للعنق الذي قِسته

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

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

لا تقبل التغيير إلا عندما يتحسّن القياس نفسه في الظروف نفسها. العدّاد الأكبر ليس نتيجة؛ الانتظار الأقصر المقيس أو النقل الأسرع بسبب محدَّد هو النتيجة.