के VPN को एन्ट्रोपी सकिन्छ? entropy_avail ले वास्तवमा के देखाउँछ

बुटको समयमा रोकिनु र ढिलो स्थापित टनेल दुई फरक खराबी हुन्। यादृच्छिकतालाई दोष दिनु अघि चरण, काउन्टरको वास्तविक अर्थ र लाइन पढ्नुहोस्।

कर्नेलको यादृच्छिकता सकिनु ढिलो VPN का लागि आकर्षक व्याख्या हो, र मानिसहरूले रिपोर्ट गर्ने लक्षणका लागि लगभग सधैं गलत व्याख्या हो। यादृच्छिक आउटपुटको प्रतीक्षा गरिरहेको होस्ट निश्चित क्षणमा रोकिन्छ, सामान्यतया बुटको सुरुमा वा कुञ्जी ह्यान्डलिङका बेला। जुन टनेल छिटो जोडिन्छ र त्यसपछि ढिलो स्थानान्तरण गर्छ त्यसले बरु थ्रुपुट वर्णन गर्छ। तपाईंले पढी नसक्नुभएको संख्या सुधार्न डेमन स्थापना गर्नु अघि यी दुई अवलोकन छुट्याउनुहोस्।

यो मिथक किन टिक्छ

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

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

जेनेरेटरले प्रति प्याकेट के गर्छ

OpenSSL 3 मा पूर्वनिर्धारित जेनेरेटर पदानुक्रम कन्फिगरेसन र स्थितिअनुसार बीउ राख्ने र फेरि राख्ने DRBG उदाहरणहरूबाट बन्छ। OpenVPN 2.6 मा AEAD डेटा मार्गले आफ्नो nonce प्याकेटको क्रम संख्याबाट प्रति-सत्र गुप्त मानसँग मिलाएर लिन्छ, जबकि पुरानो CBC मार्गले प्रति प्याकेट स्युडो-यादृच्छिक IV लिन्छ। कुनै पनि ढाँचाले एक गिगाबाइट सार्दा एक गिगाबाइट ताजा कर्नेल हल्ला खपत हुन्छ भन्ने नियमलाई समर्थन गर्दैन। दुवैले कुञ्जी उत्पादन र ह्यान्डशेक नै बीउ राख्नु महत्त्वपूर्ण हुने ठाउँ हो भन्ने विचारलाई समर्थन गर्छन्।

CBC घटनाको नाम लिन लायक छ किनकि यो मिथकजस्तो देखिन्छ र होइन: यसको प्रति-प्याकेट IV लाइब्रेरीकै आफ्नै पुनः-बीउ तालिकाअनुसार लाइब्रेरी जेनेरेटरबाट आउँछ, कहिल्यै प्रति प्याकेट कर्नेल कलबाट आउँदैन। कसैले प्रति-बाइट एन्ट्रोपी लागत उल्लेख गरे, उनीहरूले कुन लाइब्रेरी संस्करण र कुन कोड मार्ग नापे भनी सोध्नुहोस्।

प्रतीक्षा वास्तवमा कहाँ देखिन्छ

टाइमस्ट्याम्प सत्रको वरिपरि होइन, चरणहरूको वरिपरि राख्नुहोस्: सुरुवात, प्रमाणीकरण, कुञ्जी परिवर्तन र स्थानान्तरण। टनेल प्रयोगयोग्य हुनु अघिको प्रतीक्षा कम स्थिर दरभन्दा फरक उजुरी हो, र तीमध्ये एउटाले मात्र यादृच्छिकतातर्फ संकेत गर्छ। Linux मा सामान्य getrandom() अनुरोध कर्नेलको यादृच्छिक स्रोत सुरु नभएसम्म अवरुद्ध हुन सक्छ, त्यसैले यो समस्याको बुट-समय संस्करण सुरुमा पोखरीलाई खुवाउन थोरै भएका भर्चुअल मेसिन र इम्बेडेड बोर्डमा वास्तविक छ।

चरणके चलाउनेप्रतीक्षा अर्थ लाग्ने पाठथ्रुपुट अर्थ लाग्ने पाठ
बुट, कुनै पनि टनेल अघिsystemd-analyze critical-chainटनेल सुरु हुनु अघि सेकेन्ड बस्ने युनिटलागू हुँदैन, अझै केही स्थानान्तरण भइरहेको छैन
ह्यान्डशेकjournalctl -u openvpn-server@server -bइनिसियलाइजेसन क्रम पूरा हुनु अघिको लामो अन्तराललागू हुँदैन, टनेल माथि छैन
स्थापित स्थानान्तरणss -tin को छेउमा sar -n DEV 1खाली सकेट लाइनसहित अवरुद्ध प्रक्रियाभरिएका लाइन, पुनःप्रेषण र एउटा व्यस्त थ्रेड

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

cat /proc/sys/kernel/random/entropy_avail
uname -r

सुधारलाई पढाइसँग मिलाउनुहोस्

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

ss -tin dst 203.0.113.7
sar -n DEV 1 5

OpenSSL को जेनेरेटर कागजात यस पदानुक्रमले कसरी इनपुट पाउँछ र पुनः-बीउ कहिले हुन्छ वर्णन गर्छ, जो मिथकभन्दा धेरै साँघुरो दाबी हो र त्यो कार्यान्वयनका लागि मात्र सत्य हो। एन्ट्रोपी डेमन सार्वभौमिक गति सुधार होइन, र काउन्टर बढाउन त्यसलाई स्थापना गर्नु ढिलाइ नदेखाई सुरक्षा धारणा बदल्छ। थ्रुपुटका लागि डेटा मार्ग पछ्याउनुहोस्: एउटा संतृप्त थ्रेड, पुनःप्रेषण, बाह्य हानि र लाइन खस्कने—प्रत्येकलाई फरक सुधार चाहिन्छ, र बफर आकारले सकेट बफरिङलाई आफ्नै लाइन-प्रमाणसहित सम्बोधन गर्छ।

सम्बन्धित लेखहरू