OpenVPN सर्वर कॉन्फ़िगरेशन को शाखा में कॉपी करना क्यों विफल होता है

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

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

एक ही फ़ाइल जैसी दिखने वाली दो भूमिकाएँ

TLS मोड में दोनों पक्षों के काम पूरक होते हैं। एक पक्ष सुनता है, सर्वर प्रमाणपत्र और कुंजी रखता है, और तय करता है कि कौन से क्लाइंट जुड़ सकते हैं। दूसरा पक्ष शुरू करता है, श्रोता को सत्यापित करता है और अपनी पहचान प्रस्तुत करता है।

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

निजी कुंजी सबसे महत्वपूर्ण हिस्सा है। क्लाइंट को कभी सर्वर की निजी कुंजी नहीं रखनी चाहिए, और उसे CA की हस्ताक्षर कुंजी की भी ज़रूरत नहीं है। CA प्रमाणपत्र सार्वजनिक विश्वास सामग्री है; हस्ताक्षर कुंजी वहीं रहती है जहाँ प्रमाणपत्र जारी होते हैं।

शाखा प्रोफ़ाइल में क्या होना चाहिए

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

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

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

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

पीयर-से-नेटवर्क संबंध अलग है

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

हब के ऑपरेटिंग सिस्टम में रूट जोड़ना यह बताने के बराबर नहीं है कि OpenVPN को कौन सा क्लाइंट प्रीफ़िक्स का स्वामी है। हर क्लाइंट के संबंध के बिना पैकेट सुरंग इंटरफ़ेस तक पहुँचता है और गिरा दिया जाता है, क्योंकि कोई पीयर गंतव्य का दावा नहीं करता।

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

यह साबित करना कि शाखा वही पीयर है जो आप सोचते हैं

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

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

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

पूरी शाखा वह है जिसके पास प्रलेखित पहचान, केवल-क्लाइंट प्रोफ़ाइल, हब पर पीयर-से-नेटवर्क संबंध और परखा हुआ वापसी मार्ग है। सर्वर फ़ाइल में पाठ उलटने से आपको इनमें से कोई नहीं मिलता।