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 फेरि बनाउनुभन्दा सानो काम हो, र तीन सर्तहरूले सधैं यहीतर्फ संकेत गर्दै आएका थिए।