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'

সেই আউটপুটে দুটি আলাদা জিনিস খুঁজুন: র‍্যান্ডম উৎসের বার্তা অদৃশ্য হওয়া, এবং টানেল তার স্বাভাবিক সূচনা মাইলফলকে পৌঁছানো। আবার কাজ করা জেনারেটর একটি স্থানীয় ব্যর্থতা সরায় এবং সার্ভারের পরিচয়, ক্রেডেনশিয়াল বা রাউটিং সম্পর্কে কিছু বলে না। একই ক্লায়েন্ট কনফিগারেশন দিয়ে এটি পরীক্ষা করুন যা আগে ব্যর্থ হয়েছিল, যাতে ফলাফল তুলনীয় হয় এবং কেবল উন্নত নয়।