DH फाइल की tls-auth किल्ली? दोन OpenVPN फाइल वेगळ्या ओळखणे

दोन फाइल, दोन सूचना, आणि दोन्हींना त्या जे कॉन्फिगर करतात त्याच नावाने हाक मारण्याची सवय. अशाच प्रकारे dh.pem tls-auth ओळीत जाते आणि क्लायंट अनपेक्षित किल्ली स्वरूपाबद्दलच्या संदेशासह अपयशी ठरतो. तुमच्यासमोरचा निर्णय कोणती फाइल अधिक मजबूत आहे हा नाही. तर तैनातीला खरोखर कोणती भूमिका हवी आहे हा आहे, आणि तीन अटी तो ठरवतात: तुमचा TLS स्टॅक कोणते किल्ली देवाणघेवाण करार करेल, नियंत्रण-चॅनेल प्रमाणीकरण तुम्हाला हवे आहे का, आणि सामग्री गुप्त राहिली पाहिजे का.

त्यांना क्रमाने उत्तर द्या आणि फाइलचा प्रश्न स्वतःच उत्तर देईल. त्या वगळल्या तर सूचनांची नावे परस्पर बदलण्यायोग्य वाटू लागतात, आणि चूक नेमकी त्या स्थितीतूनच येते.

फाइलच्या नावापूर्वी लेबल वाचा

फाइलची पहिली ओळ तिच्या नावापेक्षा अधिक माहिती देते, कारण नाव मानवी परंपरा आहे आणि लेबल साधन तयार करते. Diffie-Hellman पॅरामीटर्स BEGIN DH PARAMETERS हे PEM लेबल धारण करतात. OpenVPN ची स्थिर किल्ली पूर्णपणे वेगळी रचना आहे, तिचे स्वतःचे शीर्षक आणि हेक्स पेलोड आहे.

नाव बदलल्याने काहीही रूपांतरित होत नाही. ta.key नावाची पॅरामीटर फाइल अजूनही पॅरामीटर्स आहे, आणि dh.pem नावाची स्थिर किल्ली अजूनही स्थिर किल्ली आहे; पार्सर सामग्री वाचतो आणि विसंगती नाकारतो. प्रोफाइल संपादित करण्यापूर्वी तपासा:

head -n 1 dh.pem
head -n 1 ta.key

कोणती फाइल हवी हे ठरवणाऱ्या तीन अटी

पहिली अट म्हणजे देवाणघेवाण. मर्यादित क्षेत्राच्या Diffie-Hellman हस्तांदोलनाला गट लागतो, आणि dh सूचना हे असे स्थान आहे जिथे सर्व्हर त्यासाठी पॅरामीटर्सना नाव देतो. लंबवर्तुळाकार वक्राच्या हस्तांदोलनाला ती फाइल अजिबात लागत नाही, कारण वक्र स्वतःच पॅरामीटर संच आहे. तुमचा सर्व्हर फक्त ECDHE संचांवर चर्चा करत असेल तर DH फाइल अतिरिक्त शक्ती नसून मृत भार आहे.

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

तिसरी अट म्हणजे गुप्तता आणि वितरण. DH पॅरामीटर्स सत्र कमकुवत न करता प्रकाशित करता येतात, कारण गुप्त मूल्ये प्रत्येक हस्तांदोलनासाठी तयार होतात आणि पक्ष कधीही सोडत नाहीत. स्थिर किल्ली प्रकाशित करू नये: ती दोन्ही टोकांना एकाच बाइट्स आहे, स्वतः फिरत नाही, आणि ज्याच्याकडे ती आहे तो वैध नियंत्रण-चॅनेल स्वाक्षऱ्या तयार करू शकतो. या दोन उत्तरांच्या मार्गांनी पूर्णपणे वेगळे हाताळणीचे नियम दिसतात, म्हणूनच एक फाइल भांडारात राहू शकते आणि दुसरी नाही.

प्रत्येक भूमिकेसाठी योग्य सामग्री तयार करा

सूचना जे स्वरूप अपेक्षित करते ते तयार करणारे साधन वापरा, त्यांच्यात रूपांतर करण्याऐवजी. OpenVPN 2.6 वरील सामायिक किल्लीसाठी जनरेटरचे टाइप केलेले स्वरूप हेतू स्पष्टपणे सांगते.

openvpn --genkey tls-auth ta.key

ती आज्ञा नवीन गुप्त सामग्री तयार करते; ती विद्यमान किल्ली दुरुस्त करत नाही किंवा तपासत नाही, आणि पुन्हा चालवल्यास इतर पक्षांकडे नसलेली वेगळी किल्ली मिळते. तयार झालेली फाइल ज्यांना ती हवी त्या पक्षांकडे कोणत्याही सामायिक गुप्त गोष्टीसाठी वापरता त्या मार्गाने प्रत करा, आणि दिशेची परंपरा सुसंगत ठेवा: tls-auth सह एक बाजू key-direction 0 आणि दुसरी key-direction 1 वापरते.

DH पॅरामीटर्स हवे असताना पॅरामीटर निर्मितीतून येतात, किल्ली जनरेटरमधून नाही, आणि निकाल सार्वजनिक असला तरी त्यांचा उगम महत्त्वाचा आहे. अज्ञात स्रोतातून घेतलेला गट सार्वजनिक असल्यामुळे विश्वासार्ह होत नाही; तो अजूनही तुमचे पक्ष ज्यावर सहमत आहेत असा गट असला पाहिजे आणि त्याच्या आकाराने किंवा रचनेने कमकुवत न झालेला असला पाहिजे.

dh none चा अर्थ काय आणि काय नाही

dh none मर्यादित अर्थाची खरी सूचना आहे: कोणतेही मर्यादित-क्षेत्र पॅरामीटर फाइल लोड होणार नाही, कारण हस्तांदोलन लंबवर्तुळाकार वक्राचे Diffie-Hellman वापरते. हे काहीतरी कमकुवत करण्याच्या अर्थाने “DH पायरी वगळा” याचे संक्षिप्त रूप नाही, आणि OpenVPN ला दुसरी फाइल पर्याय म्हणून स्वीकारण्यास ते निश्चितपणे सांगत नाही.

चुकीच्या वाचनातून दोन चुका होतात. पहिली म्हणजे dh none tls-auth ची गरज काढून टाकते असे गृहीत धरणे, तर त्या दोन वेगवेगळ्या गोष्टी नियंत्रित करतात. दुसरी म्हणजे केवळ-वक्र संरचनेच्या शेजारी जुनी dh ओळ ठेवून नंतर सर्व्हर प्रत्यक्षात कोणती फाइल वापरतो याचा विचार करणे; सूचना असेल तर फाइल वाचली जाते, आणि तिथला तुटलेला मार्ग वाटाघाटी होणाऱ्या देवाणघेवाणीशी संबंध नसलेल्या कारणाने सुरुवात अपयशी करतो.

चुकीची फाइल आधीच तैनात झाली असेल तर

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

मग लोक एकत्र करतात त्या दोन घटना वेगळ्या करा. DH पॅरामीटर फाइल प्रकाशित करणे जवळपास निरुपद्रवी आहे, कारण पॅरामीटर्स रचनेपासूनच सार्वजनिक होते. tls-auth किल्ली उघड करणे ही वेगळी घटना आहे: किल्ली ती असलेल्या प्रत्येक पक्षासाठी नियंत्रण-चॅनेल पॅकेट प्रमाणित करते, त्यामुळे बदली एका होस्टवर नाही तर संपूर्ण तैनातीत समन्वयित करावी लागते.

पाच मिनिटांची तपासणी तुम्ही कोणत्या प्रकरणात आहात हे ठरवते: प्रत्येक फाइलची पहिली ओळ वाचा, तिचा उल्लेख करणारी सूचना पुष्टी करा, आणि फाइलचे वितरण सामग्रीच्या गरजेशी जुळते का ते पुष्टी करा. कार्यरत PKI पुन्हा तयार करण्यापेक्षा हे लहान काम आहे, आणि तीन अटी सतत याकडेच निर्देश करत होत्या.