WireGuard कुंजी युग्म स्थानीय रूप से बनाएँ: कमांड और सावधानी

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

एक ही शेल में युग्म बनाना

प्रलेखित कार्यप्रवाह निजी मान के अस्तित्व में आने से पहले फ़ाइल बनाना सीमित करता है, फिर उससे सार्वजनिक मान निकालता है। तीनों पंक्तियाँ एक ही शेल सत्र में साथ रहती हैं:

umask 077  # applies to files created next, so keep the next line in this shell
wg genkey | tee privatekey | wg pubkey > publickey
wg pubkey < privatekey  # re-derive and compare with publickey

wg genkey 32 बाइट की Curve25519 निजी कुंजी base64 में लिखता है; wg pubkey उसे पढ़ता है और मेल खाती सार्वजनिक कुंजी निकालता है, और tee निजी मान को सहेजता है जबकि उसे पाइप से नीचे भेजता है। यही क्रम कारण है कि अनुमति वाली पंक्ति पहले आती है, और यह भी कि पाइपलाइन को दूसरे टर्मिनल में चिपकाने पर वह चुपचाप खो जाती है। फ़ाइल नाम उदाहरण हैं, और महत्वपूर्ण यह है कि दोनों फ़ाइलें ऐसी जगह गिरें जिसे मालिक डिवाइस नियंत्रित करता है। अगर कोई निजी फ़ाइल पहले से डिफ़ॉल्ट अनुमतियों के साथ मौजूद है, तो chmod 600 privatekey मौजूदा फ़ाइल को ठीक करता है और पहले बनी प्रतियों के बारे में कुछ नहीं करता।

निजी आधा हिस्सा एक ही डिवाइस पर रखें

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

सेवानिवृत्त फ़ाइल को जानबूझकर नष्ट करना उसी आदत का हिस्सा है। उसे डाउनलोड फ़ोल्डर में छोड़ देना जब तक किसी की नज़र न पड़े, नहीं है।

पीयर के ऑपरेटर को आपसे क्या चाहिए

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

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

युग्म को वास्तविक अदला-बदली से परखें

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

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

बिना अंतराल के कुंजी बदलना

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

बदली हुई निजी फ़ाइल को तब तक रखें जब तक नया पीयर पुष्ट न हो, फिर उसे जानबूझकर नष्ट करें। WireGuard का त्वरित प्रारंभ स्वयं कमांड के लिए संदर्भ है, और यह शुरू करने से पहले पूरा पढ़ने के लिए काफ़ी छोटा है।