8192-बिट कीज हँडशेक थांबवतात; 1024-बिट DH नाकारला जातो

एका सर्व्हरवर ग्राहक काही काळ अडकतात आणि नंतर पुन्हा जोडले जातात, तर दुसरा कीच्या आकाराबद्दलच्या संदेशासह कनेक्शन लगेच नाकारतो. ती वेगवेगळ्या बगसारखी दिसतात आणि तीच बग विरुद्ध दिशांना दाखवते. हँडशेक क्रिप्टोग्राफीचा खर्च पॅरामीटरच्या आकारासोबत वाढतो, आणि आधुनिक लायब्ररी खाली जात नाहीत अशी एक तळमर्यादाही असते. सामग्रीचा आकार ठरवणे हीच तपासणी यादी आहे, आणि पहिला मुद्दा म्हणजे दोनपैकी कोणती त्रुटी तुमच्याकडे खरोखर आहे हे ठरवणे.

काहीही पुन्हा तयार करण्यापूर्वी अपयश वाचा

वेळ तुम्हाला त्यातले बहुतेक सांगतो. काही सेकंद घेऊन नंतर मरणारा हँडशेक सहसा असा अर्थ देतो की गणना समोरच्या बाजूच्या संयमापलीकडे गेली, जे हार्डवेअर किंवा मुदतीसाठी खूप मोठे पॅरामीटर दाखवते. की किंवा गटाचा आकार नमूद करणारा लगेचचा नकार दुसऱ्या दिशेला, लायब्ररी मुळीच स्वीकारणार नाही अशा सामग्रीकडे दाखवतो.

या दोन्हींना विरुद्ध दुरुस्त्या लागतात, आणि इथेच बहुतेक प्रयत्न चुकतात. ज्या ग्राहकाने आधीच लहान गट नाकारला आहे त्यावर 8192-बिट पॅरामीटर पुन्हा तयार करणे संथ प्रकरण अधिक बिघडवते, पण वेगवान प्रकरणासाठी काहीही करत नाही. फाइलला हात लावण्यापूर्वी तुम्ही कोणते लक्षण पाहिले ते लिहून ठेवा.

मग समोरच्या बाजूकडून काय मागितले जाते ते तपासा. मोठ्या मर्यादित-क्षेत्र गटासाठी सेट केलेला सर्व्हर प्रत्येक ग्राहकाला केवळ जोडणीच्या वेळीच नव्हे, तर प्रत्येक पुनर्वाटाघाटीत तोच CPU वेळ खर्च करण्यास भाग पाडतो. समस्या सुरुवातीला नाही तर नियमित अंतराने दिसल्यास ते अंतर कोणती सेटिंग महाग आहे याचा जोरदार संकेत आहे. पुनर्वाटाघाटी संपूर्ण गणना पुन्हा करते, म्हणून दर तासाला परत येणारा खोळंबा सहसा तोच खर्च पुन्हा भरणे असते.

संथ प्रकरण: हार्डवेअर परवडू शकत नाही अशी सामग्री

Diffie-Hellman आणि RSA चे काम कीच्या आकारासोबत वेगाने वाढते, आणि हे सर्व बोगद्यातून कोणताही रहदारी वाहण्यापूर्वीच घडते. लहान राउटर किंवा कमी शक्तीच्या ग्राहकावर पुरेसा मोठा गट देवघेव दुसऱ्या बाजूच्या मुदतीपलीकडे ढकलू शकतो, त्यामुळे कनेक्शन पुन्हा प्रयत्न करते किंवा कोणत्याही त्रुटीशिवाय फक्त अडकलेले दिसते.

दुरुस्ती म्हणजे प्रत्येक बाजू स्वीकारते आणि प्रत्येक उपकरण आरामात मोजू शकते अशा आकारापर्यंत खाली येणे. 2048-बिट RSA की आणि 2048-बिट गट व्यापकपणे सुसंगत पायाभूत रेषा राहतात; मोठे करणे फक्त तेव्हाच मदत करते जेव्हा सर्व बाजू सहमत असतात आणि प्रोसेसर प्रत्येक पुनर्वाटाघाटीत तो खर्च करू शकतो. त्या पायाभूत रेषेपुढील सर्व काही जाणीवपूर्वक केलेली देवघेव आहे, सुधारणा नाही.

आकार हा गुण नाही, आणि तुलना तक्त्यातील सर्वात मोठी संख्या आपोआप योग्य निवड नाही. तुमचे धोरण परवानगी देते आणि सर्व बाजू स्वीकारतात असे सर्वात लहान मूल्य निवडा, मग सुधारले असे गृहीत धरण्याऐवजी हँडशेक मोजा. तरीही मुदत संपणारा लहान गट तुम्हाला सांगतो की आकार कधीही संपूर्ण कथा नव्हता.

वेगवान प्रकरण: लायब्ररी नाकारते असा गट

आधुनिक OpenSSL बिल्ड सर्वात लहान मर्यादित-क्षेत्र गट सरळ नाकारतात, आणि वाढवलेली सुरक्षा पातळी तळमर्यादा अधिक वर ढकलते. दशकापूर्वीची पॅरामीटर फाइल सोबत आणणारे राउटर फर्मवेअर हा नेहमीचा स्रोत आहे, आणि लक्षण म्हणजे गट किंवा कीचा आकार नमूद करणाऱ्या संदेशासह लगेच अपयशी होणारे कनेक्शन. त्या अपयशात काहीही अधूनमधून नाही, आणि त्यामुळेच ते ओळखणे सोपे होते.

तपासणी टाळण्यासाठी कॉन्फिगरेशन संपादित करण्याऐवजी फाइल बदला. सध्याचा गट तयार करा, त्याची पडताळणी करा, मग डेमन प्रत्यक्षात जिथे वाचतो तिथे तो स्थापित करा. ग्राहक नव्यासह यशस्वीरित्या जोडला जाईपर्यंत जुनी फाइल ठेवा:

openssl dhparam -out /etc/openvpn/ffdhe2048.pem 2048
openssl dhparam -in /etc/openvpn/ffdhe2048.pem -check -noout
ls -l /etc/openvpn/ffdhe2048.pem

तपासणी आदेश फाइलची पडताळणी करतो आणि ती उत्तीर्ण झाल्यावर काहीही उपयुक्त छापत नाही; यादी पुष्टी करते की तुम्ही सेवा लोड करते ती फाइल बदलली आहे, शेजारची जुनी प्रत नाही. कॉन्फिगरेशन त्या मार्गाकडे निर्देशित करा, डेमन पुन्हा सुरू करा, आणि पूर्वी अपयशी ठरलेला ग्राहक आता हँडशेक पूर्ण करतो याची पुष्टी करा.

सर्व्हर सुरक्षा पातळी किंवा प्रमाणपत्र प्रोफाइलही सेट करत असेल, तर गट चुकीचा होता असा निष्कर्ष काढण्यापूर्वी ते वाचा. अधिक कडक वर्ग मागणारे प्रोफाइल डीफॉल्ट स्वीकारलेली सामग्री नाकारू शकते, आणि ती सेटिंग काढणे हे तपासणी जागतिकरित्या बंद करण्यापेक्षा अरुंद बदल आहे.

समोरच्या बाजू आणि हार्डवेअरसाठी आकार निवडा

विचित्र काहीही तयार करण्यापूर्वी दूरचे टोक काय सहन करू शकते ते शोधा. 2048-बिट गटासाठी खूप जुने उपकरण बदलण्याजोगे उपकरण आहे, कारण सर्व्हर कमकुवत गटाकडे वळवणे केवळ सुसंगतीची तक्रार बिघाडात बदलते. टिकाऊ दुरुस्त्या जुन्या पॅरामीटरकडे नाही, नवीन सॉफ्टवेअरकडे जातात. या क्षेत्रातील प्रत्येक तात्पुरता अपवाद कायमची कॉन्फिगरेशन होण्याचा मार्ग शोधतो.

सर्व्हरचा CPU मर्यादा असेल तिथे धोरणाखाली जाण्याऐवजी अल्गोरिदम बदला. X25519 सारखी लंबवर्तुळ वक्र की देवघेव मोठ्या मर्यादित-क्षेत्र गटापेक्षा प्रचंड स्वस्त आहे आणि मोठ्या प्रमाणात समर्थित आहे, त्यामुळे कार्यक्षमतेच्या तक्रारीला लहान RSA मॉड्यूलसपेक्षा ती चांगले उत्तर ठरते.

कायही निवडा, एका खऱ्या कनेक्शनने चाचणी करा आणि हँडशेकला किती वेळ लागतो ते पाहा, केवळ शेवटी जोडले जाते का ते नाही. बारा सेकंदात यशस्वी होणाऱ्या कनेक्शनचे मूळ कारण पंधरात अपयशी होणाऱ्यासारखेच आहे.

पुनर्बांधणी ती रद्द करू नये म्हणून निवड नोंदवा

पॅरामीटर फाइल कॉन्फिगरेशन व्यवस्थापनाखाली ठेवा आणि शेजारी आकार, कारण आणि तारीख लिहा. स्वतःचे डीफॉल्ट गुपचूप तयार करणारा पुन्हा बांधलेला सर्व्हर हाच तोच दोष सहा महिन्यांनी परत येण्याचा मार्ग, आणि मूळ निर्णय कोणीही समजावून सांगू शकत नाही.

तीच माहिती एंडपॉइंट आणि प्रोफाइलजवळ लिहा, जेणेकरून पुनरावलोकनाला ती फाइल आकारातून पुन्हा तयार करावी लागणार नाही. पुढचे कनेक्शन अडकल्यावर ती नोंद पाच मिनिटांची तपासणी आणि नवीन तपास यातील फरक ठरते. पुढच्या अभियंत्याला वेगवान प्रकरणासाठी केलेल्या दुरुस्तीने संथ प्रकरण सोडवण्यापासूनही ती रोखते.