duplicate-cn दो डिवाइस को एक पहचान देता है, दो नहीं

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

मिथक: दूसरा सत्र दूसरी पहचान है

अंतर्ज्ञान कहता है कि दो कनेक्शन दो क्लाइंट होने चाहिए, और दो क्लाइंट अपने अधिकारों वाले दो डिवाइस होने चाहिए। सर्वर ऐसा मॉडल नहीं करता। वह एक साझा नाम देखता है, और duplicate-cn सक्रिय होने पर उस नाम को ले जाने वाले एक से अधिक जीवित सत्र स्वीकार करता है, और हर एक को डेमन में अपनी सत्र-स्थिति मिलती है।

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

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

जब दो सत्र एक नाम साझा करते हैं तो असल में क्या बदलता है

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

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

इसके आधार पर डिज़ाइन करने से पहले जाँचिए कि आपका बिल्ड असल में क्या करता है, क्योंकि विकल्प का असर विकल्प ख़ुद तय करता है, किवदंतियाँ नहीं:

grep -n 'duplicate-cn\|client-config-dir\|username-as-common-name' /etc/openvpn/server.conf

वह स्थिर पता जो आपने आवंटित किया समझा था

प्रति-क्लाइंट कॉन्फ़िगरेशन नाम से खोजा जाता है, और यहीं जाल है। साझा नाम पर नामित client-config-dir फ़ाइल उस नाम का उपयोग करने वाले हर डिवाइस पर लागू होती है, इसलिए उसके अंदर का ifconfig-push दोनों डिवाइस को एक ही टनल पता देता है। दूसरा सत्र या तो स्थापित नहीं होता, या ऐसे टकराता है कि राउटिंग ख़राबी जैसा लगे।

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

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

हटाने के समय साझा पहचान क्या नहीं कर सकती

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

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

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

साझा करना कब सही है, और उसे कैसे सीमित करें

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

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

चाहे कोई भी रास्ता चुनें, लॉगिन नहीं, प्रबंधन मॉडल को परखिए। दोनों डिवाइस जोड़िए, पुष्टि कीजिए कि उनके पते अलग हैं, फिर नुकसान का अनुकरण कीजिए और देखिए कि आप ठीक एक को हटा सकते हैं। openvpn(8) मैनुअल विकल्प का दायरा तय करता है; आपकी हटाने की प्रक्रिया तय करती है कि साझा करना वास्तव में स्वीकार्य है या नहीं।