लीक हुई VPN कुंजी बदलना: सर्वर को क्या करना चाहिए

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

स्थानीय प्रति अधिकार नहीं है

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

इसीलिए चोरी हुई कुंजी स्पष्ट सफ़ाई के बाद भी काम करती रहती है, और इसीलिए नया कॉन्फ़िगरेशन स्थापित होने पर भी घटना अनसुलझी लगती है।

सर्वर के नियम से शुरू करें, फिर क्लाइंट की ओर बाहर बढ़ें।

प्रमाणपत्र: निर्णय सर्वर के पास है

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

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

ये दो अलग परीक्षण हैं और दोनों आवश्यक हैं। RFC 5280 उस प्रमाणपत्र और निरसन अर्थ-विधि को परिभाषित करता है जिस पर गेटवे निर्भर है।

WireGuard: पीयर कुंजी ही पहचान है

WireGuard में प्रमाणपत्र की परत नहीं है: पीयर की सार्वजनिक कुंजी ही पहचान है, और सर्वर की allowed-ips प्रविष्टि ही प्राधिकरण है। इंटरफ़ेस कॉन्फ़िगरेशन से पुराने पीयर को हटाना ही निरसन है, और यह नए हैंडशेक पर तुरंत लागू होता है।

मौजूदा सत्र तब समाप्त होते हैं जब अगला हैंडशेक विफल होता है, जो आमतौर पर तुरंत नहीं बल्कि कुछ मिनटों के भीतर होता है।

नया कॉन्फ़िगरेशन ऐसे चैनल से बाँटें जिसे आप पासवर्ड सौंपने लायक मानें, क्योंकि निजी कुंजी ही क्रेडेंशियल है। प्रति डिवाइस एक कुंजी रखें, ताकि एक खोया डिवाइस हर डिवाइस को बदलने पर मजबूर न करे।

उस बंडल में और क्या था

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

यदि बंडल डिवाइसों में साझा था, तो उसे ले जाने वाला हर डिवाइस उस जोखिम को विरासत में पाता है।

जो बदला गया वह लिख लें, क्योंकि अगली ऑडिट पूछेगी।

अस्वीकृति सिद्ध करें, फिर प्रतिस्थापन दर्ज करें

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

निजी कुंजियाँ टिकट और चैट से बाहर रखें, और नीति के अनुसार भंडारण और बैकअप से अप्रचलित निर्यात हटाएँ।

अस्वीकृति परीक्षण के बिना प्रतिस्थापन एक अनुमान है, समाधान नहीं।