OpenSSL मा AES-NI वा कर्नेल अफलोड: तपाईंलाई कुन चाहिन्छ?
CPU निर्देश समर्थनलाई प्याकेट कहाँ प्रशोधन हुन्छ भन्नेबाट अलग गर्नुहोस्: ट्युन गर्नु अघि क्रिप्टो ब्याकएन्ड, सहमत साइफर र सक्रिय मार्ग जाँच्नुहोस्।
दुई लेबललाई एउटै कुरा जस्तै प्रयोग गरिन्छ: हार्डवेयर-त्वरित र कर्नेलमा सारिएको। एउटाले पुस्तकालयको AES रुटिनले कुन निर्देशन चलाउँछ भन्ने बताउँछ, अर्कोले प्याकेट प्रशोधन कहाँ हुन्छ भन्ने बताउँछ। VPN सँग पहिलो दोस्रो बिना, दोस्रो पहिलो बिना, वा दुवै सँगै हुन सक्छ। कार्यसम्पादनबारे कुनै पनि निर्णय तपाईंले यी दुईमध्ये कुनलाई साँच्चै बदल्दै हुनुहुन्छ भन्ने नाम दिनबाट सुरु हुनुपर्छ।
दुई अक्ष, एउटा अंक होइन
पहिलो अक्ष कार्यान्वयन हो: AES-256-GCM गर्ने कोड प्रोसेसरका समर्पित निर्देशनहरू प्रयोग गर्ने संस्करणतर्फ जान्छ कि तिनलाई साधारण अंकगणितका रूपमा चलाउने पोर्टेबल रुटिनतर्फ। यो छनोट क्रिप्टोग्राफिक पुस्तकालयभित्र रहन्छ र त्यसको सुरुवातमा गरिन्छ।
दोस्रो अक्ष स्थान हो: प्याकेट कर्नेलको रूपान्तरण मार्गबाट जान्छ कि प्रयोगकर्ता स्थानको डेमन टनेल उपकरणबाट पढ्छ, इन्क्रिप्ट गर्छ र फेरि लेख्छ।
कुनै पनि अक्षले अर्कोलाई सीमित गर्दैन। AES निर्देशन भएको CPU मा प्रयोगकर्ता स्थानको VPN ले तिनलाई सधैं प्रयोग गर्न सक्छ, र ती नभएको CPU मा कर्नेल मार्ग सफ्टवेयर कार्यान्वयनतर्फ फर्कन्छ। विक्रेताका सामग्रीमा लेबलले यो भिन्नता विरलै देखाउँछन्, त्यसैले दुई अवस्थाबीच प्रतिलिपि गरिएको ट्युनिङ सल्लाहले प्रायः केही गर्दैन।
अक्ष एक: कुन कोडले इन्क्रिप्शन गर्छ
OpenSSL ले सुरुवातमा प्रोसेसरका विशेषताहरू पहिचान गर्छ र नतिजालाई अनुकूलित कोड मार्ग छान्न प्रयोग गर्छ, जसरी x86 क्षमताको कागजात वर्णन गर्छ। AES-NI त्यो प्रेषणपछाडिका अभिलेखित क्षमताहरूमध्ये एक हो। यीमध्ये केहीले पनि पुस्तकालय कर्नेल घटक बन्नुपर्ने माग गर्दैन।
द्रुत मार्ग प्रयोग भइरहेको छ भनी मान्नु अघि विशेषता प्रक्रियालाई देखिन्छ भनी पुष्टि गर्नुहोस्। Linux मा स्रोत /proc/cpuinfo को flags क्षेत्र हो, र अतिथिभित्र यसले हाइपरभाइजरले खोल्ने कुरा प्रतिबिम्बित गर्छ, भौतिक होस्टको मोडेल नाम होइन।
grep -m1 '^flags' /proc/cpuinfo | grep -o '\baes\b'
openssl list -providers -verboseदोस्रो आदेशले त्यो बिल्डमा लोड भएका प्रदायकहरूको नाम बताउँछ। यसले तपाईंलाई VPN सेवाले कुन पुस्तकालय जोड्यो भन्ने बताउँदैन, र एउटा होस्टले दुई OpenSSL स्थापना बोक्न सक्छ जबकि चलिरहेको प्रक्रियाले तीमध्ये एउटा मात्र प्रयोग गर्छ।
अक्ष दुई: प्याकेट मार्ग कहाँ चल्छ
कर्नेलमा राख्नु भन्नाले रूपान्तरण कर्नेलकै IPsec यन्त्रणामा वा कर्नेलभित्रको टनेल ड्राइभरमा हुन्छ, त्यसैले प्याकेटहरूलाई प्रत्येक ब्याचका लागि प्रयोगकर्ता स्थानको प्रक्रियाबाट आउने-जाने यात्रा आवश्यक पर्दैन। यसले प्रतिलिपि र सन्दर्भ परिवर्तन घटाउन सक्छ, र एउटै थ्रेडको डेमनले गर्न नसक्ने तरिकाले काम कोरहरूमा फैलाउन सक्छ। यसले ती काउन्टर र ट्रेसहरू पनि सार्छ जुन तपाईंले थ्रुपुट घट्दा पढ्नुहुनेछ, किनकि काम अब तपाईंले नियन्त्रण नगर्ने सीमाको अर्को पट्टि हुन्छ। यसलाई केवल कार्यसम्पादनको निर्णय नभई डिबगिङको लागत मान्नुहोस्।
यसले निर्देश समर्थन बनाउँदैन, साइफर कन्फिगर गर्दैन र भएको मार्गलाई काम गर्ने बनाउँदैन।
भर्चुअलाइजेसनले यो अक्षमा पनि एउटा मोड्ने थप्छ। अतिथिलाई होस्टसँग भएका विशेषता लुकाउने मास्क गरिएको CPU मोडेल दिन सकिन्छ, र भित्री अतिथिले अझ कम देख्न सक्छ। क्षमताको दृश्य VPN साँच्चै चल्ने वातावरणभित्रबाट पढ्नुहोस्, हाइपरभाइजर कन्सोलबाट होइन।
प्रत्येक छनोटले के किन्छ, र के गर्न सक्दैन
व्यावहारिक प्रश्न समय कहाँ जान्छ भन्ने हो। यदि एउटा व्यस्त थ्रेड, बारम्बार बफर प्रतिलिपि वा प्रत्येक प्याकेटको सिस्टम कलले थ्रुपुट सीमित गर्छ भने, ती लागत हटाउने मार्गमा रूपान्तरण सार्नु मद्दत गर्न सक्छ, यदि कर्नेलले आवश्यक रूपान्तरण लागू गरेको छ भने।
यदि सीमा भीडभाड भएको माथिल्लो लिङ्क, हानि भएको मार्ग, लामो आउने-जाने समय, भरिएको गन्तव्य सेवा वा एउटा कोरमा पिन गरिएको एउटा थ्रेड हो भने, स्थानले केही महत्त्वपूर्ण बदल्दैन। निर्देश छनोटमा पनि त्यही लागू हुन्छ: समर्पित हार्डवेयरमा AES ले हराएको मार्ग मर्मत गर्न सक्दैन र नाम विश्लेषण असफल भएर टनेल खाली भए मद्दत गर्दैन।
जहाँ दुवै लागू हुन्छन्, ती मिल्छन्। कर्नेल मार्गले कर्नेलको क्रिप्टो API भित्रको त्यही निर्देश-स्तरको प्रेषण प्रयोग गर्न सक्छ, र राम्रोसँग छानिएको पुस्तकालय भएको प्रयोगकर्ता स्थानको मार्गले यसलाई पहिले नै प्रयोग गरिरहेको छ। निर्णय कुन अमूर्त रूपमा छिटो हो भन्ने होइन; कुन लागतका लागि तपाईंसँग प्रमाण छ भन्ने हो।
केही बदल्नु अघि चार तथ्य लेख्नुहोस्
सेवाको बाइनरी र यसले जोडेको क्रिप्टो पुस्तकालय लेख्नुहोस्, किनकि तिनैले अक्ष एक निर्धारण गर्छन्। त्यसपछि सहमत भएको डाटा सुरक्षा लेख्नुहोस्, किनकि समर्पित निर्देश मार्ग नभएको साइफरले त्यो भएकोभन्दा फरक व्यवहार गर्छ, र सेट दुवै पक्षले छान्छन्।
त्यसपछि, चलिरहेको वातावरणभित्रबाट क्षमताको दृश्य, र अन्तमा सक्रिय प्याकेट मार्गसँग प्रमाण कि तपाईं सक्षम ठान्नुभएको मोड साँच्चै त्यही हो। लोड गरिएको मोड्युल प्रोफाइलले यसलाई प्रयोग गर्छ भन्ने प्रमाण होइन, र कन्फिगरेसन लाइन कर्नेलले यसलाई स्वीकार गर्यो भन्ने प्रमाण होइन।
एउटा कुरा बदल्नुहोस्, त्यसपछि उही अन्त्य बिन्दु र उही स्थानान्तरण दिशा भएको एकरूप कार्यभारसँग तुलना गर्नुहोस्। तपाईंले ननापेको गति दाबी ब्याकएन्ड कहिल्यै शंकामा परेन भन्ने टिप्पणीभन्दा कम मूल्यको हुन्छ।