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 चे जनरेटर दस्तऐवज हे श्रेणी इनपुट कसे मिळवते आणि पुनः-बीज कधी होते हे वर्णन करतात, हे आख्यायिकेपेक्षा खूप संकुचित विधान आहे आणि फक्त त्या अंमलबजावणीसाठी खरे आहे. एन्ट्रोपी डेमन सार्वत्रिक वेग सुधारणा नाही, आणि काउंटर वाढण्यासाठी तो स्थापित करणे विलंब न दाखवता सुरक्षा गृहीतक बदलते. थ्रूपुटसाठी डेटा मार्ग अनुसरा: एक संतृप्त थ्रेड, पुनःप्रेषण, बाह्य हानी आणि रांगेतील घसरण—प्रत्येकाला वेगळी दुरुस्ती लागते, आणि बफर आकार सॉकेट बफरिंगला स्वतःच्या रांग-पुराव्यासह हाताळतात.