दोन पीअरमधील OpenVPN दुव्यासाठी स्थिर किल्ली की TLS?

फक्त एकमेकांशी बोलणाऱ्या दोन मशीन ती टोपोलॉजी ठेवूनही बोलणी करून ठरलेल्या रहदारीच्या किल्ल्या मिळवू शकतात। नेटवर्कचा आकार आणि संरक्षण मोड हे स्वतंत्र पर्याय आहेत, आणि हे दोन्ही एकत्र मिसळल्यामुळेच लोक दोन्ही डीमन सुरू असताना फाइल बदलून स्थिर गुपित फिरवण्याचा प्रयत्न करतात। चालू असलेल्या जोडीखाली किल्लीची फाइल बदलल्याने काहीही फिरत नाही। OpenVPN 2.6 ज्याला अप्रचलित म्हणते तो स्थिर-किल्ली मोड बोगद्याच्या संपूर्ण आयुष्यभर एकच किल्ली ठेवतो, त्यामुळे डिस्कवरील फाइल आणि स्मरणपत्रातील किल्ली दोन्ही टोके पुन्हा सुरू झाल्यावरच पुन्हा जुळतात। स्वयंचलित नूतनीकरण ही गरज असेल, तर संरक्षण मोड बदलावा लागेल।

स्थिर-किल्ली मोड काय करू शकत नाही

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

OpenVPN 2.6 हस्तपुस्तिका नवीन किल्ली तयार होईपर्यंत किल्ली टिकते असे स्पष्ट सांगते। हे प्रयोगशाळेच्या दुव्यासाठी किंवा दस्तऐवजीकृत फिरवणी प्रक्रियेअसलेल्या स्थिर उपकरण जोडीसाठी स्वीकारार्ह आहे, आणि दीर्घकालीन गुपित हा खरा धोका असेल तेथे ते अस्वीकारार्ह आहे। फाइल बदलल्याने चालू जोडीला नवीन किल्ली तयार होत नाही; त्याने जुळत नसलेले दोन पीअर तयार होतात। म्हणून फाइल बदलणे फिरवणी न जोडता खंड जोडते।

फाइल धारण करण्यापलीकडे पीअर ओळखीची कल्पनाही नाही। ज्याच्याकडे किल्ली आहे तोच पीअर आहे, आणि बोगद्यात काहीही कोणती बाजू कोणती आहे हे नोंदवत नाही, म्हणून रद्दीकरण म्हणजे सर्व किंवा काहीच नाही।

दुवा पुन्हा रचनेशिवाय TLS कडे जाणे

TLS मोड नियंत्रण वाहिनी जोडतो, आणि तिच्यासोबत डेटा वाहिनीच्या किल्ल्यांवर बोलणी करण्याची क्षमता। पॉइंट-टू-पॉइंट तैनातीत एक बाजू सर्व्हरची भूमिका घेते आणि दुसरी क्लायंटची, पण टोपोलॉजी दोन पीअरमधील दुवाच राहते: प्रत्येक बाजूला दुसऱ्याचा शेवटचा बिंदू माहीत असतो, आणि कोणताही तलाव किंवा बहुवापरकर्ता सेवा दिसत नाही। भूमिका या हात मिळवणीचा तपशील आहेत, नवीन स्थापत्य नाही।

प्रत्येक मशीनला तिची स्वतःची ओळख द्या। प्रत्येक बाजूला प्रमाणपत्र आणि खाजगी किल्ली, दुसरी बाजू पडताळणारा विश्वास-अँकर, आणि कोणाची अपेक्षा आहे हे नाव देणारा पीअर-पडताळणी नियम लागतो। वेळ वाचवण्यासाठी एका पीअरची खाजगी किल्ली दुसऱ्यावर पुन्हा वापरू नका; त्याने दोन ओळखी एक होतात आणि कोणतीही बाजू स्वतंत्रपणे रद्द करण्याची क्षमता निघून जाते। नोंदणी हीच हे नीट करण्याची जागा आहे, कारण नंतर दुरुस्त करणे म्हणजे प्रमाणपत्रे पुन्हा देणे।

संरक्षण बदलत असताना नेटवर्क करार बदलू नका। तेच बोगदा पत्ते, मार्ग आणि परवानगी असलेल्या सेवा आधी व नंतर लागू झाल्या पाहिजेत, जेणेकरून स्थलांतरादरम्यानचा अपयश छद्म मार्गनिर्देशनाचे आश्चर्य न होता संरक्षणाची समस्या असेल। बदलापूर्वी पत्ते व मार्ग लिहून ठेवा; नंतर त्यांची तुलना करणे स्मरणातून पुन्हा रचण्यापेक्षा वेगवान आहे।

काही तैनाती नियंत्रण वाहिनीला डेटा वाहिनीसोबत न फिरणाऱ्या स्वतःच्या स्थिर किल्लीनेही संरक्षित करतात। ती किल्ली पेलोडऐवजी हात मिळवणीचे रक्षण करते, त्यामुळे ती फुटल्यास रहदारी नाही तर बोलणी उघड होते। ती डेटा वाहिनीच्या सामग्रीपासून वेगळी ठेवा, आणि नाव नमूद केलेल्या व्यक्तीकडे मालकीची बदली तारीख द्या। ती फिरवणे म्हणजे समन्वित खिडकीत दोन्ही पीअर पुन्हा सुरू करणे, म्हणून ती स्मरणापेक्षा दिनदर्शिकेतील नोंदीला पात्र आहे।

कोण काय नूतनीकरण करतो, आणि कधी

TLS मोडमध्ये नूतनीकरण संरचित मर्यादांद्वारे चालते: कालावधी, बाइट मोजणी किंवा पॅकेट मोजणी। दस्तऐवजीकृत वेळ नियंत्रण हेच बहुतेक तैनाती अवलंबतात, आणि दोन्ही पीअरमधील कमी प्रभावी मूल्य बदली सुरू करू शकते, म्हणून फक्त एका बाजूला ते वाढवल्याने घटना थांबणार नाही। आकारमान-आधारित मर्यादा यासाठी आहेत की व्यस्त दुवा घड्याळाच्या खूप आधी किल्ली संपवू शकतो। कोणतीही मर्यादा आरोग्य-तपासणी नाही, आणि कोणतीही तुम्हाला नूतनीकरण यशस्वी झाले असे सांगत नाही।

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

वस्तू मनात वेगळ्या ठेवा। प्रमाणपत्र दीर्घकालीन ओळख सिद्ध करते आणि तुम्ही नियंत्रित करता त्या वेळापत्रकानुसार बदलले जाते। डेटा वाहिनीची किल्ली स्वयंचलितपणे ताजी होते, आणि स्वतंत्र प्रमाणीकरण देवघेव, तैनातीला ती लागत असेल तर, खाते धोरणाचे पालन करते आणि पुढील देवघेवींसाठी स्वतःची व्यवस्था लागू शकते।

मध्यांतर शून्यावर ठेवून नूतनीकरण पूर्णपणे बंद करणे हा गोंगाट करणाऱ्या नोंदीसाठी उपाय नाही। त्याने निरोगी जीवनचक्र घटना कायमच्या किल्लीत बदलते, ज्यामुळे तुम्ही सोडू पाहत असलेल्या गुणाकडे परत जाता।

बदल स्वीकारणे

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

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

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