VPN प्रमाणपत्र प्राधिकरण बदलल्यावर काय होते

VPN प्रमाणपत्र प्राधिकरण बदलणे म्हणजे फाइल बदलणे नाही। नवीन CA ने आपल्या पहिल्या प्रमाणपत्रावर स्वाक्षरी केल्याच्या क्षणी, अजूनही फक्त जुन्यावर विश्वास ठेवणाऱ्या प्रत्येक सत्यापकाला निर्णय घ्यावा लागतो, आणि नवीन अँकर कधीच न मिळणाऱ्या यजमानांकडून चांगल्या समकक्षांना नाकारणे सुरूच राहते। मी हे दोन्ही दिशांनी बिघडताना पाहिले आहे: गेटवेने नवीन CA शिकला पण क्लायंटनी नाही, त्यामुळे नवीन जोडण्या अयशस्वी झाल्या, तर आधीच उभ्या असलेल्या बोगद्या तशाच राहिल्या आणि बिघाड मार्गनिर्देशनाची समस्या वाटू लागला। काय बदलते ते, बिघाड ज्या क्रमाने दिसतात त्याच क्रमाने पुढे दिले आहे।

एक बदल, दोन वेगवेगळे बदल

प्रमाणपत्र प्राधिकरण म्हणजे एक नाव, एक सार्वजनिक की आणि स्वाक्षरी करणारी खाजगी की। सत्यापक अमूर्त अर्थाने ‘CA’ वर कधीही विश्वास ठेवत नाहीत। ते विश्वास साठवणीत आधीच असलेल्या एका विशिष्ट प्रमाणपत्रावर विश्वास ठेवतात, आणि स्वाक्षऱ्यांची साखळी त्या साठवलेल्या प्रतीपर्यंत पोहोचली तरच जारीकर्ता स्वीकारतात। म्हणून CA बदलल्याने स्वतंत्रपणे अयशस्वी होणाऱ्या दोन गोष्टी बदलतात: कोणते अँकर स्वीकारले जातात आणि त्यांच्या अंतर्गत कोणत्या समकक्ष ओळखी जारी झाल्या।

बहुतेक VPN उपयोजन दोन्ही दिशांनी सत्यापन करतात। क्लायंट गेटवेचे प्रमाणपत्र प्रमाणित करतो, आणि गेटवे क्लायंटचे। केवळ क्लायंट बंडल नूतनीकरण करणारा बदल सर्व्हरला जुन्या CA ची ओळख अजूनही सादर करणाऱ्या प्रत्येक क्लायंटला नाकारू देतो, आणि उलटेही तितकेच सामान्य आहे। आधी अंमलबजावणीची ठिकाणे यादी करा: क्लायंट विश्वास साठवणी, गेटवेची ca फाइल, त्याच्यासमोर TLS संपवणारा कोणताही प्रॉक्सी, आणि बाहेरून अंतिम बिंदू तपासणारा शोधक।

सत्यापक काय तपासतो, क्रमाने

मार्ग सत्यापन समकक्षाच्या प्रमाणपत्रापासून मध्यस्थांमधून विश्वसनीय अँकरपर्यंत चढते। प्रत्येक टप्प्यावर ते स्वाक्षरी तपासते, प्रत्येक प्रमाणपत्र त्याच्या वैधता कालावधीत आहे का पाहते, आणि मूलभूत मर्यादा व की वापर जारीकर्त्याला स्वाक्षरी करण्याची परवानगी देतात याची खात्री करते। त्यानंतरच अनुप्रयोग पान प्रमाणपत्राकडे पाहतो: विषयाच्या पर्यायी नावांनी डायल केलेले नाव व्यापले पाहिजे, आणि विस्तारित की वापराने सर्व्हर किंवा क्लायंट प्रमाणीकरणास परवानगी दिली पाहिजे।

तो प्रवास ऑफलाइन पुन्हा करण्यासाठी, -CAfile आपण उपयोजित करणार असलेल्या नेमक्या बंडलकडे निर्देश करा, प्रणाली साठवणीकडे नाही। अन्यथा आपण बदल नाही, यजमान तपासत आहात:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

ती आज्ञा गेटवेच्या HTTPS प्रशासन पानासारख्या साध्या TLS श्रोत्याविरुद्धच काम करते; OpenVPN चे नियंत्रण वाहिनी TLS च्या आधी येते, त्यामुळे s_client बोगद्याची हस्तांदोलन तपासू शकत नाही।

त्या त्रुटींमागील मार्ग-निर्मिती नियम RFC 5280 विभाग 6 मध्ये आहेत। ते अन्यथा मनमानी वाटणाऱ्या अयशस्वीता स्पष्ट करतात: कोणालाही आठवण नसलेले कालबाह्य मध्यस्थ प्रमाणपत्र, ज्याचा की वापर स्वाक्षरीवर बंदी घालतो असे प्रमाणपत्र, किंवा आपण तपासत असलेला यजमान वगळणारी नाव मर्यादा।

जुना बोगदा का चालू राहतो

TLS आणि OpenVPN दोन्ही हस्तांदोलन संपल्यानंतर प्रस्थापित सत्र जिवंत ठेवतात। प्रत्येक पॅकेटला समकक्षाचे प्रमाणपत्र पुन्हा सत्यापित करणारे काहीही नाही, त्यामुळे बदलापूर्वी जोडलेला क्लायंट पुन्हा वाटाघाटी, पुन्हा जोडणी किंवा बोगदा पडण्यापर्यंत रहदारी पुढे पाठवत राहतो। हेच अंतर CA बदल एक तास ठीक दिसून नंतर सर्वात वाईट क्षणी अयशस्वी होण्याचे कारण: लॅपटॉप झोपेतून जागा होतो, NAT मॅपिंगची मुदत संपते, गेटवे पुन्हा सुरू होते।

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

स्थिर-की स्तर यापासून वेगळा ठेवा। tls-auth नियंत्रण वाहिनीत HMAC जोडते, tls-crypt ती कूटबद्ध करून प्रमाणित करते, आणि दोन्हीपैकी कोणतेही प्रमाणपत्र सामग्री वाहत नाही, त्यामुळे कोणत्याही एकाची फिरकी ही स्वतःच्या अयशस्वीता-पद्धतीसह वेगळा बदल आहे। दोन्ही मिसळणारी उपयोजने अशा क्लायंटवर संपतात ज्याची स्थिर की ठीक आहे, प्रमाणपत्र जुने आहे, आणि त्रुटी संदेश दोन्हीपैकी कोणाचाही उल्लेख करत नाही।

विषय नाव पुनर्वापराचा सापळा

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

मग मार्ग-निर्मिती चुकीचे निवडू शकते, योग्य अँकर असतानाही ‘स्थानिक जारीकर्त्याचे प्रमाणपत्र मिळाले नाही’ असे कळवू शकते, किंवा उमेदवारांचा क्रम वेगळा असल्याने त्याच बंडल असलेल्या दुसऱ्या यजमानावर यशस्वी होऊन इथे अयशस्वी होऊ शकते। नाव पुनर्वापर करावेच लागल्यास, संक्रमणकाळात दोन्ही अँकर वेगळ्या फाइलांमध्ये ठेवा आणि स्पष्टपणे लोड करा, आणि प्रत्येक समकक्षाने नवीन जारीकर्ता सादर केल्यावरच ते एकत्र करा। अन्यथा बदलीला वेगळे सामान्य नाव द्या — पिढी किंवा तारखेचा प्रत्यय पुरतो — म्हणजे नोंदी आणि त्रुटी मजकूर अयशस्वी समकक्ष कोणत्या प्राधिकरणाखाली जारी झाला हे सांगतील।

नेटवर्क न पाडणारी फिरकी

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

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

विरुद्ध दिशेने निवृत्त करा। टिकून राहिले पाहिजे अशी प्रत्येक ओळख पुन्हा जारी करा, प्रत्येकजण नवीन साखळी सादर करते याची खात्री करा, मग बंडलांमधून जुना अँकर काढा। जुन्या CA ची खाजगी की सेवेतून काढा, कारण अजूनही स्वाक्षरी करू शकणारा जारीकर्ता म्हणजे फिरकी पूर्ण झाली नाही। लेखापरीक्षणासाठी प्रमाणपत्रे आणि जारी नोंदी ठेवा। हरवलेला जारीकर्ता त्याच विश्वासावर पुनर्संचयित होतो; उघड झाल्यास नवीन ओळखी लागतात आणि जुन्या अँकरकडे परतणे नाही।

फाइल यादी नाही, निकाल सत्यापित करा

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

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

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