OpenVPN میں RAND_bytes ناکام: لائبریری کی خرابی یا گمشدہ نوڈ

RAND_bytes() failed ایک مقامی بنیادی عنصر کے بارے میں بیان ہے، نہ کہ اکاؤنٹ، پیشگی مشترکہ کلید یا دور دراز پورٹ کے بارے میں۔ دو بہت مختلف خرابیاں وہی سطر پیدا کرتی ہیں اور مختلف ثبوت چھوڑتی ہیں۔ ایک رمزنگاری بیک اینڈ ہے جو بائٹس جاری کرنے سے انکار کرتا ہے؛ دوسرا ایسا عمل ہے جو اس اینٹروپی ماخذ تک نہیں پہنچتا جس کے لیے اس کا کوڈ بنایا گیا تھا۔ انہیں الگ کرنے کے لیے غلطیوں کی قطار کی ایک قرأت اور قید شدہ عمل کے فائل سسٹم کے منظر پر ایک نظر درکار ہے، اور یہ جانچ /dev کے تحت کچھ بھی بنانے سے پہلے ہونی چاہیے۔

واپسی قدر کس چیز کو الگ کرتی ہے

دستاویزی معاہدہ تین نتائج الگ کرتا ہے، دو نہیں: کامیابی کے لیے 1، جب لوڈ شدہ RAND طریقہ درخواست کی حمایت نہ کرے تو -1، اور دیگر خرابیوں کے لیے 0، جبکہ وضاحت غلطیوں کی قطار میں رہتی ہے۔ RAND_bytes کا حوالہ ایک نکتہ شامل کرتا ہے جسے نظرانداز کرنا آسان ہے: طے شدہ جنریٹر معاون پلیٹ فارمز پر آپریٹنگ سسٹم سے بیج لیتا ہے، اور جب یہ بیج بندی ناکام ہو تو وہ پیش قیاسی بائٹس واپس کرنے کے بجائے خرابی کی حالت میں رہتا ہے۔

ان میں سے صرف ایک عدد ماحول کو بیان کرتا ہے۔ 1- تعمیر، فراہم کنندہ یا خصوصیت کا سوال ہے، کیونکہ کوڈ نے ایسی چیز مانگی جو فعال عمل درآمد پیش نہیں کرتا۔ بیج بندی کی شکایت کے ساتھ 0 ماحول کا سوال ہے، کیونکہ جنریٹر اینٹروپی حاصل ہی نہیں کر سکا۔ عدد بذات خود کبھی نہیں بتاتا کہ کون سا، اور فنکشن کا نام بھی نہیں۔

جب چھپا ہوا آلہ نوڈ اصل وجہ ہو

محدود سروس اس شیل سے مختلف درخت دیکھتی ہے جس میں آپ ٹائپ کر رہے ہیں۔ chroot جیلیں، کنٹینر کی تصاویر اور سخت کیے گئے unit فائلیں معمولاً ایسا /dev پیش کرتی ہیں جس میں میزبان سے کم نوڈ ہوتے ہیں۔ اگر ناکام عمل درآمد /dev/urandom کو راستے کے نام سے کھولتا ہے تو یہ فرق آغاز کو توڑنے کے لیے کافی ہے جبکہ میزبان خود بالکل صحت مند دکھائی دیتا ہے۔ جیل سے باہر موجود آلہ اس بارے میں کچھ ثابت نہیں کرتا کہ قید شدہ عمل کو کیا کھولنے کی اجازت ہے۔

تاہم ہر بے ترتیب انٹرفیس کو راستے کی ضرورت نہیں۔ لینکس میں getrandom نظامی کال نہ فائل کا نام قبول کرتی ہے نہ فائل ڈسکرپٹر، اور اس کا دستی صفحہ نوٹ کرتا ہے کہ یہ خصوصیت بالکل وہاں مفید ہے جہاں chroot آلے کے راستے چھپاتا ہے۔

چنانچہ گمشدہ نوڈ کی وضاحت کوڈ کی ایک شاخ کے بارے میں مفروضہ ہے، بے ترتیب اعداد کے بارے میں عمومی اصول نہیں۔ جب ثبوت راستہ بتائیں تو یہ قائم رہتا ہے، اور جب ثبوت کچھ اور بتائیں تو یہ اندازہ ہے۔

پہلے غلطیوں کی قطار، پھر عمل کا منظر پڑھیں

سوال طے کرنے کا تیزترین طریقہ یہ ہے کہ لائبریری جو کچھ پہلے ریکارڈ کر چکی ہے پڑھیں، پھر جیل کے اندر کے منظر کو براہ راست دیکھیں۔ اس OpenSSL بلڈ سے شروع کریں جو سروس نے واقعی لوڈ کیا، کیونکہ فراہم کنندہ اسٹیک بڑے ورژنوں اور تقسیمات کے درمیان مختلف ہوتے ہیں۔ پھر systemd سے پوچھیں کون سا عمل چل رہا ہے اور اس پر کون سی پابندیاں لاگو ہیں۔ دونوں حقائق میز پر آنے کے بعد ہی ان نوڈ کی فہرست بنانا قابلِ قدر ہے جو وہ عمل دیکھ سکتا ہے۔

openssl version -a
systemctl show openvpn-server@lab -p MainPID -p PrivateDevices -p DevicePolicy
pid=$(systemctl show -p MainPID --value openvpn-server@lab)
sudo ls -l /proc/"$pid"/root/dev/urandom /proc/"$pid"/root/dev/random

یہ قرأتیں اسی عمل پر کریں، اس شیل پر نہیں جو اتفاقاً کھلا ہے۔ میزبان کے /dev کا غیر متعلقہ عمل کے منظر سے موازنہ کرنا وہی طریقہ ہے جس سے غلط انحصار دو بار ٹھیک ہوتا ہے۔

انحصار صرف اس وقت شامل کریں جب آپ اس کا نام لے سکیں

جب ثبوت واقعی راستہ بتائیں تو مرمت چھوٹی ہے: اسی ایک راستے کو جیل کے اندر دستیاب کریں اور باقی سب کچھ چھوڑ دیں۔ ایک نوڈ کا bind mount عموماً کافی ہوتا ہے، اور mknod نوڈ کے معیاری major اور minor نمبروں کے ساتھ ان تنصیبات پر وہی نتیجہ دیتا ہے جہاں mount کوئی آپشن نہیں۔ سینڈ باکس کو بڑھانا، ہر کریکٹر ڈیوائس تک رسائی دینا یا PrivateDevices بند کرنا نشانہ بنائی گئی درستی کو مستقل سیکیورٹی رجعت سے بدل دیتا ہے۔

اینٹروپی ڈیمون اس مرمت کا متبادل نہیں۔ haveged جیسی پیکیجز کرنل پول کی خوراک کا طریقہ بدلتی ہیں؛ وہ ایسا راستہ نہیں بنا سکتیں جسے قید شدہ عمل کھولنے کا مجاز ہو۔ ایک انسٹال کرنا صحت کے گراف کو بہتر دکھا سکتا ہے جبکہ کھولنے کی کال اب بھی ناکام ہوتی ہے۔ دونوں مسائل کو الگ رکھیں، ورنہ اگلی ناکامی دوبارہ غلط تہہ سے منسوب ہوگی۔

جنریٹر اور ٹنل کو الگ الگ جانچیں

دوبارہ آغاز واحد آزمائش ہے جو وہی ترتیب، وہی unit فائل اور وہی تحدید دوبارہ استعمال کرتی ہے جس نے ناکامی پیدا کی۔ اسے چلائیں، پھر کسی پہلے بوٹ کے نمونے کے بجائے جرنل کے تازہ ترین اندراجات پڑھیں۔

sudo systemctl restart openvpn-server@lab
sudo journalctl -u openvpn-server@lab --since -5min --no-pager | grep -iE 'rand|entropy|Initialization Sequence'

اس آؤٹ پٹ میں دو الگ چیزیں تلاش کریں: بے ترتیب ماخذ کے پیغام کا غائب ہونا، اور ٹنل کا اپنے معمول کے آغاز کے سنگ میل تک پہنچنا۔ دوبارہ کام کرنے والا جنریٹر ایک مقامی ناکامی دور کرتا ہے اور سرور کی شناخت، اسناد یا روٹنگ کے بارے میں کچھ نہیں کہتا۔ اسے اسی کلائنٹ ترتیب سے آزمائیں جو پہلے ناکام ہوئی تھی، تاکہ نتیجہ موازنے کے قابل ہو، صرف بہتر نہ ہو۔