दो पीयर के बीच OpenVPN लिंक के लिए स्थिर कुंजी या TLS?

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

स्थिर-कुंजी मोड क्या नहीं कर सकता

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

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

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

लिंक को फिर से डिज़ाइन किए बिना TLS पर जाना

TLS मोड एक नियंत्रण चैनल जोड़ता है, और उसके साथ डेटा चैनल की कुंजियों पर बातचीत करने की क्षमता। पॉइंट-टू-पॉइंट परिनियोजन में, एक पक्ष सर्वर की भूमिका लेता है और दूसरा क्लाइंट की, लेकिन टोपोलॉजी दो पीयर के बीच का लिंक ही रहती है: हर पक्ष दूसरे का एंडपॉइंट जानता है, और कोई पूल या बहु-उपयोगकर्ता सेवा नहीं दिखती। भूमिकाएँ हैंडशेक का ब्यौरा हैं, नई संरचना नहीं।

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

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

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

कौन क्या नवीनीकृत करता है, और कब

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

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

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

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

बदलाव को स्वीकार करना

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

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

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