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'

त्यो आउटपुटमा दुई अलग कुरा खोज्नुहोस्: अनियमित स्रोतको सन्देश हराउनु, र सुरुङ आफ्नो सामान्य सुरुवाती चरणमा पुग्नु। फेरि काम गर्ने जेनेरेटरले एउटा स्थानीय खराबी हटाउँछ र सर्भरको पहिचान, प्रमाणहरू वा राउटिङबारे केही भन्दैन। यसलाई त्यही क्लाइन्ट कन्फिगरेसनसँग परीक्षण गर्नुहोस् जुन पहिले असफल भएको थियो, ताकि नतिजा तुलनीय होस्, केवल राम्रो होइन।