स्थिर 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 एकत्रीकरण सामान्य वाटपकर्ता समस्यांसह छोटे वाटपकर्ता आहे. त्याला विनंती करणाऱ्या ओळखीची पडताळणी करावी लागते, पत्ता अणु-रूपात आरक्षित करावा लागतो, केवळ समर्थित प्रति-कनेक्शन आउटपुट द्यावे लागते, आणि डिस्कनेक्ट किंवा अयशस्वी झाल्यास आरक्षण सोडावे लागते. एकाचवेळी येणाऱ्या विनंत्यांना लॉक किंवा डेटाबेस मर्यादा हवी, वाचा-मग-लिहा क्रम नाही. स्वच्छता न केल्यास पूल रीस्टार्टपर्यंत पत्ते गळतो.

वाटपकर्त्याची स्थिती पुढील ऑपरेटर वाचू शकेल अशा ठिकाणी ठेवा, आणि केवळ पत्ता नाही तर ओळख-ते-पत्ता निर्णय लॉग करा.

पत्ता धोरण आहे की सोय ते ठरवा

फायरवॉल नियम किंवा मार्ग एका टनेल पत्त्यावरून रहदारीला परवानगी देत असेल, तर पत्ता प्रवेश धोरणात सहभागी होतो आणि पुनर्वाटप ती परवानगी वारशाने घेते. ओळख, पत्ता आणि फायरवॉलचे जीवनचक्र समन्वयित करा, किंवा नियम पुनर्वाटप करता येणार नाही अशा गोष्टीशी जोडा. स्थिर पत्ता-निर्धारण कॉन्फिगरेशन वाचनीय करते; ते प्रमाणीकरणाची जागा घेत नाही.

योजना प्रत्येक नोंदीसाठी मालकासह यादी म्हणून लिहा, नंतर उपकरण सेवानिवृत्त झाल्यावर तिचा आढावा घ्या. न वापरलेले आरक्षण हेच चुकून पुन्हा वापरले जाते.