OpenVPN प्रोफ़ाइल में प्रमाणपत्र के तीन ब्लॉक होते हैं: कौन सा गुप्त है?

आप एक पंक्ति बदलने के लिए .ovpn फ़ाइल खोलते हैं और base64 के तीन ब्लॉक पाते हैं जो सभी क्रेडेंशियल जैसे दिखते हैं। एक प्रकाशित करने के लिए सुरक्षित है, दूसरा पासवर्ड जितना संवेदनशील है, और तीसरा एक सार्वजनिक कुंजी है जिसका कोई अर्थ नहीं जब तक कोई और उसकी जोड़ी से हस्ताक्षर न करे। लोग पूरी फ़ाइल को सहायता थ्रेड में चिपका देते हैं क्योंकि ब्लॉक बदले जा सकने वाले लगते हैं, और इसी तरह क्लाइंट कुंजी सार्वजनिक संग्रह में पहुँच जाती है। कौन सा ब्लॉक क्या करता है, यह अलग करना इन प्रोफ़ाइलों के आसपास की अधिकांश उलझन समझाता है, और यह भी बताता है कि कौन सी विफलताएँ आपको ठीक करनी हैं।

एक फ़ाइल, तीन ब्लॉक, अलग काम

एक सामान्य प्रोफ़ाइल BEGIN और END मार्करों के बीच ca ब्लॉक, cert ब्लॉक और key ब्लॉक रखती है, या उन्हीं तीनों को अलग फ़ाइलों के रूप में इंगित करती है। कुछ प्रोफ़ाइलें tls-auth या tls-crypt कुंजी के लिए चौथा ब्लॉक जोड़ती हैं, जो प्रमाणपत्र नहीं बल्कि साझा रहस्य है। क्लाइंट हर ब्लॉक को उस निर्देश के अनुसार पढ़ता है जो उसका नाम देता है, इसलिए लेबल उनके दिखने के क्रम से अधिक मायने रखते हैं।

जब तक आप वास्तव में भीतर न देख लें, संयोजित प्रोफ़ाइल को संवेदनशील मानें। एक सार्वजनिक प्रमाणपत्र और एक निजी कुंजी एक ही फ़ाइल में कुछ पंक्तियों के फ़ासले पर हो सकते हैं, और हेडर सहित स्क्रीनशॉट दोनों को शामिल कर सकता है। दिखने वाले base64 को हाथ से ढकना भी भरोसेमंद नहीं है, क्योंकि आधा-अधूरा ब्लॉक भी उन प्रमाणपत्र मेटाडेटा को लीक करता है जो आपके परिनियोजन का नाम बताते हैं। तीनों निर्देशों को उनके मानों के बिना कॉपी करना आम तौर पर उपयोगी प्रश्न पूछने के लिए पर्याप्त है।

ब्लॉकों के आसपास के निर्देश तय करते हैं कि उनका उपयोग कैसे होगा। ca बदलें और क्लाइंट किसी दूसरे प्राधिकरण पर भरोसा करता है; key बदले बिना cert बदलें और हैंडशेक ऐसी बेमेल से विफल होता है जिसका भरोसे से कोई संबंध नहीं।

CA ब्लॉक सार्वजनिक है, CA कुंजी कभी नहीं

एक प्रमाणपत्र प्राधिकरण ऐसे प्रमाणपत्रों पर हस्ताक्षर करता है जो सार्वजनिक कुंजी को पहचान से बाँधते हैं, और उसका अपना प्रमाणपत्र वह लंगर है जिससे क्लाइंट तय करता है कि श्रृंखला भरोसेमंद है या नहीं। वह प्रमाणपत्र रचना से ही सार्वजनिक है: उसे हर प्रोफ़ाइल के भीतर भेजना सामान्य है, और इसी कारण स्व-हस्ताक्षरित परिनियोजन वाणिज्यिक प्राधिकरण के बिना काम कर सकता है।

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

किसी प्राधिकरण पर भरोसा करना भी सुनने में जितना लगता है उससे संकरा है। CA द्वारा हस्ताक्षरित कोई भी प्रमाणपत्र स्वीकार करने वाला क्लाइंट उसी CA पर किसी दूसरी सेवा के लिए जारी प्रमाणपत्र भी स्वीकार करेगा। अपेक्षित सर्वर भूमिका या नाम को पिन करने वाले विकल्प वह अंतराल बंद करते हैं, और TLS विकल्प संदर्भ ऐसा करने वाले सत्यापन निर्देशों की सूची देता है।

सर्वर और क्लाइंट प्रमाणपत्र विपरीत दिशाओं में इशारा करते हैं

सर्वर का प्रमाणपत्र वह है जिसे क्लाइंट जाँचता है ताकि पुष्टि हो कि वह सही अंतिम बिंदु पर पहुँचा। आपका क्लाइंट प्रमाणपत्र उलटी दिशा में चलता है: सर्वर उससे तय करता है कि यह उपकरण या उपयोगकर्ता उसका नामांकित है। एक ही प्रारूप, भरोसे की विपरीत दिशा।

पता पहचान नहीं है। सही IP तक पहुँचना इस बात का कुछ साबित नहीं करता कि जवाब किसने दिया, इसलिए होस्टनाम या प्रमाणपत्र नाम की जाँच अब भी प्रोफ़ाइल में ही रहती है। खाता पासवर्ड भी आवश्यक क्लाइंट प्रमाणपत्र की चुपचाप जगह नहीं लेता, क्योंकि दोनों अलग-अलग चरणों में जाँचे जाते हैं और परिनियोजन दोनों माँग सकता है।

क्लाइंट की निजी कुंजी वह हिस्सा है जो निजी रहना चाहिए। अगर वह उजागर हुई हो सकती है, तो अपने लैपटॉप से फ़ाइल हटाने से सर्वर पर कुछ नहीं बदलता, जो संबंधित प्रमाणपत्र तब तक स्वीकार करता रहेगा जब तक ऑपरेटर उसे निरस्त न करे। ऑपरेटर से उस पहचान को बदलने या निरस्त करने के लिए कहना ही एकमात्र ऐसा उपाय है जो आपके साथ चलता है।

दो प्रॉम्प्ट जो एक जैसे दिखते हैं और हैं नहीं

एन्क्रिप्टेड रूप में संग्रहीत कुंजी क्लाइंट के उपयोग से पहले एक पासफ़्रेज़ माँगती है। VPN सेवा अलग से खाता पासवर्ड माँग सकती है, और दोनों प्रॉम्प्ट लगभग एक जैसे शब्दों में कुछ सेकंड के अंतर से आ सकते हैं। पासफ़्रेज़ आपकी डिस्क पर की फ़ाइल की रक्षा करता है; पासवर्ड सर्वर को खाता साबित करता है। दोनों को गड्ड-मड्ड करना लोगों को ऐसे पासवर्ड रीसेट तक भेजता है जो कभी मदद नहीं कर सकते।

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

जब प्रमाणपत्र वास्तव में समाप्त हो जाए, तो प्रतिस्थापन उसी से आना चाहिए जिसने उसे जारी किया। किसी और की कुंजी नवीनीकरण का रास्ता नहीं है, और सहकर्मी से चलती हुई प्रोफ़ाइल उधार लेना भी नहीं।

एक स्वच्छ हैंडशेक क्या साबित करता है और क्या नहीं

पूर्ण TLS हैंडशेक तक पहुँचने का अर्थ है कि कॉन्फ़िगर किया गया पहचान संबंध टिका: सर्वर का प्रमाणपत्र आपके CA से श्रृंखलित हुआ और आपका प्रमाणपत्र स्वीकार किया गया। यह ऑपरेटर की लॉगिंग नीति के बारे में कुछ नहीं कहता, और न ही इस बारे में कि सुरंग उठने के बाद आपके एप्लिकेशन काम करेंगे या नहीं।

रूट और DNS कनेक्शन के बाद के चरण हैं, इसलिए सफल लॉगिन के बाद अगम्य इंट्रानेट होस्ट प्रमाणपत्र की नहीं बल्कि कनेक्टिविटी की समस्या है। क्रेडेंशियल बदलने के बजाय उस परत पर काम करें, और प्रोफ़ाइल किसी को देते समय उसका स्रोत, उसकी निजी सामग्री और उसकी पहचान जाँचें साथ रखें।