स्थिर OpenVPN पते स्रोत IP नहीं, पहचान का पालन करें

जो पता योजनाएँ कहती हैं ‘यह लैपटॉप 10.90.0.10 पाता है’, वे वास्तव में पहचान के बारे में कथन हैं: कौन-सा प्रमाणित उपकरण उस पते को रख सकता है। उस उपकरण के वर्तमान सार्वजनिक IP से इसका लगभग कोई संबंध नहीं है, क्योंकि NAT और रोमिंग उपयोगकर्ता कौन है, यह बदले बिना इसे बदल देते हैं। स्रोत पते पर योजना बनाने से ऐसे नियम बनते हैं जो पहले होटल नेटवर्क पर टूट जाते हैं। प्रमाणित पहचान पर इसे बनाने से ऐसी योजना बनती है जो यात्रा में टिकती है।

सर्वर जो सत्यापित कर सकता है उससे शुरू करें, फिर तय करें कि पता किसलिए है।

पते से पहले पहचान की कुंजी चुनें

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

duplicate-cn के साथ, कई एक साथ चल रहे सत्र एक ही सामान्य नाम प्रस्तुत कर सकते हैं, इसलिए एक पिन किया गया पता उन्हें अलग-अलग पहचान नहीं सकता। यह पहचान मॉडल की विशेषता है, ऐसी चीज़ नहीं जिसे बेहतर पता योजना ठीक कर सके।

गतिशील श्रेणी के बाहर पते आरक्षित करें

10.90.0.0/24 जैसे सबनेट-टोपोलॉजी नेटवर्क में, नामित सदस्यों के लिए निचले पते रखें और गतिशील पूल को अलग श्रेणी में रखें। पिन किए गए सदस्य के लिए आवंटन ऐसा दिखता है ifconfig-push 10.90.0.10 255.255.255.0 उस फ़ाइल में जिसे सर्वर उस पहचान के लिए चुनता है। दूसरा आर्ग्युमेंट net30 के अंतर्गत कुछ और अर्थ देता है, इसलिए उदाहरण टोपोलॉजी-तटस्थ नहीं है। इसे कॉपी करने से पहले टोपोलॉजी पढ़ें।

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

आवंटन की प्राथमिकता तय करती है कौन जीतेगा

मैनुअल एक क्रम दर्ज करता है: client-connect के दौरान उत्पन्न स्पष्ट आवंटन client-config-dir प्रविष्टि से पहले प्रभावी हो सकता है, जो बदले में सामान्य पूल आवंटन से पहले आती है। यही क्रम ‘पिन किया गया पता लागू नहीं हुआ’ वाली अधिकांश रिपोर्ट समझाता है। इसका यह भी अर्थ है कि प्रति-सत्र कॉन्फ़िगरेशन लिखने वाला गतिशील आवंटक उस स्थिर फ़ाइल को चुपचाप ओवरराइड कर सकता है जिसे आप प्रामाणिक मानते थे।

आवंटनों का स्वामी एक परत चुनें और बाकी को केवल-पठन बनाएँ। दो परतें जो दोनों निर्णय का दावा करती हैं, समय-निर्भर आवंटन बनाती हैं।

गतिशील आवंटक को भी वही मॉडल चाहिए

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

आवंटक की स्थिति वहाँ रखें जहाँ अगला ऑपरेटर उसे पढ़ सके, और केवल पता नहीं, पहचान-से-पता निर्णय लॉग करें।

तय करें कि पता नीति है या सुविधा

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

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