क्या आप VPN की सार्वजनिक कुंजी साझा कर सकते हैं? ये तीन बातें जाँचें

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

पहली जाँच: जोड़ी का कौन-सा आधा हिस्सा आपके क्लिपबोर्ड में है

असममित कुंजियाँ जोड़ों में आती हैं, और व्युत्पत्ति की दिशा ही पूरी बात है। WireGuard में निजी कुंजी 32 यादृच्छिक बाइट होती है और सार्वजनिक कुंजी उससे परिकलित होती है; उलटी दिशा में जाया नहीं जा सकता। wg genkey निजी मान लिखता है, wg pubkey सार्वजनिक मान निकालता है, और पीयर को भेजे गए संदेश में केवल दूसरा ही जाता है।

wg genkey | tee private.key | wg pubkey > public.key
chmod 600 private.key
openssl x509 -noout -pubkey -in server.crt

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

अगर आपको निश्चित नहीं कि कौन-सा मान आपके पास है, तो फ़ाइल नाम के बजाय चिह्न देखें। -----BEGIN PRIVATE KEY----- से शुरू होने वाला PEM ब्लॉक, या पुराना BEGIN RSA PRIVATE KEY रूप, गुप्त आधा हिस्सा है। वह मान जिसे आप उस चिह्न के बिना चिपका सकते हैं, साझा करने का उम्मीदवार है, अगली दो जाँचों के अधीन।

दूसरी जाँच: परिनियोजन उस सार्वजनिक मान को किससे बाँधता है

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

प्रमाणपत्र डिज़ाइन से ही पहचान का रिसाव करते हैं। Subject और subject alternative name फ़ील्ड पढ़े जा सकते हैं, और सार्वजनिक रूप से विश्वसनीय TLS प्रमाणपत्रों के लिए प्रमाणपत्र स्वयं Certificate Transparency लॉग में प्रकाशित होता है, जिन्हें खोजा जा सकता है। इनमें से कुछ भी निजी कुंजी को उजागर नहीं करता, और यह सब एक संबंध उजागर करता है।

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

तीसरी जाँच: आप क्या निरस्त कर सकते हैं, और कितनी तेज़ी से

तीसरी जाँच दोनों हिस्सों को पूरी तरह अलग करती है। प्रकाशित सार्वजनिक कुंजी को आपके कार्यक्रम के अनुसार बदला जा सकता है। प्रकाशित निजी कुंजी को वापस नहीं बुलाया जा सकता: अपनी प्रति मिटाने से पहले ली गई प्रतियों पर कोई असर नहीं होता, और जिस भी पीयर ने उस पर भरोसा किया वह अब किसी बाहरी व्यक्ति के पास की चीज़ पर भरोसा कर रहा है।

निरस्तीकरण एक कॉन्फ़िगरेशन क्रिया है, क्रिप्टोग्राफ़िक क्रिया नहीं। WireGuard कोई निरस्तीकरण सूची नहीं देता, इसलिए आप पीयर हटाते हैं:

wg set wg0 peer <peer-public-key> remove
# then delete the [Peer] block from the config so it does not return on restart

OpenVPN प्रमाणपत्र आधारित परिनियोजन प्रमाणपत्र निरस्त करते हैं और एक CRL प्रकाशित करते हैं जिसे सर्वर वास्तव में crl-verify के ज़रिए जाँचता है। उस निर्देश के बिना निरस्तीकरण सूची केवल सजावट है। किसी भी तरह क्रम वही है: प्रतिस्थापन जारी करें, समर्थित चैनल से वितरित करें, और फिर पुरानी पहचान को सेवानिवृत्त करें।

तीनों जाँचों को मिलाने से होने वाली गलतियाँ

अधिकांश वास्तविक रिसाव कोई व्यक्ति का निजी कुंजी प्रकाशित करने का निर्णय नहीं है। वे फ़ोरम में चिपकाई गई पूरी प्रोफ़ाइल हैं: WireGuard .conf जिसमें PrivateKey लाइन है, या .ovpn बंडल जिसमें इनलाइन कुंजी ब्लॉक है, या क्लाइंट विंडो का स्क्रीनशॉट जिसमें संयोगवश कुंजी फ़ील्ड आ गया है। सार्वजनिक मान शायद ठीक था; वह उस हिस्से के साथ गया जो ठीक नहीं था।

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

लॉग और स्क्रीनशॉट उसी श्रेणी में आते हैं। निदान आउटपुट में कुंजी सामग्री, सत्र पहचानकर्ता और आंतरिक पते हो सकते हैं, और एक प्रश्न का उत्तर पाने के लिए वह सब पोस्ट करना थोड़ी सुविधा के बदले बड़ा जोखिम लेता है।

निजी मान के रिसाव के बाद पहचान को सेवानिवृत्त करें

अगर निजी मान फिर भी बाहर आ गया, तो उस पहचान को सेवानिवृत्त मानें। नया जोड़ा बनाएँ, सार्वजनिक आधा वहाँ स्थापित करें जहाँ पीयर उसकी अपेक्षा करते हैं, पुराना पीयर हटाएँ या पुराना प्रमाणपत्र निरस्त करें, और उन जगहों को जाँचें जहाँ आपने इसे प्रकाशित किया था। आप उन प्रतियों को मिटा नहीं सकते जिन्हें आप नियंत्रित नहीं करते, इसलिए हटाना भविष्य के बारे में है, अतीत के बारे में नहीं।

फिर वितरण लिखें: कौन-सी कुंजी किस डिवाइस की है, किसके पास प्रति है, प्रतिस्थापन कैसे पहुँचाया जाता है, और सेवानिवृत्त पीयर कौन हटाता है। यही वे हिस्से हैं जो लोग भूल जाते हैं, और यही तय करते हैं कि कोई रिसाव कितने समय तक उपयोगी रहता है।