کیا 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 کے جنریٹر کی دستاویزات بیان کرتی ہیں کہ یہ درجہ بندی ان پٹ کیسے حاصل کرتی ہے اور دوبارہ بیج ڈالنا کب ہوتا ہے، جو افسانے سے کہیں زیادہ تنگ دعوی ہے اور صرف اسی عمل درآمد کے لیے درست ہے۔ اینٹروپی ڈیمون عالمگیر رفتار کی مرمت نہیں، اور کاؤنٹر بڑھانے کے لیے اسے نصب کرنا تاخیر دکھائے بغیر حفاظتی مفروضہ بدل دیتا ہے۔ تھرو پٹ کے لیے ڈیٹا راستے کی پیروی کریں: ایک سیر شدہ تھریڈ، دوبارہ ارسال، بیرونی نقصان اور قطار کا گرنا—ہر ایک کو مختلف اصلاح درکار ہے، اور بفر کے حجم ساکٹ بفرنگ کو اپنے قطار کے ثبوت کے ساتھ سنبھالتے ہیں۔