WireGuard कहता है कि निजी कुंजी की लंबाई ग़लत है: अब क्या करें?

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

इस त्रुटि के पीछे दो अलग काम छिपे हैं: किसी मान्य कुंजी के टेक्स्ट को ठीक करना, और ऐसी पहचान बदलना जो अब आपके पास नहीं है। इनके परिणाम अलग हैं, और इनमें से एक दूसरे सिरे को अमान्य कर देता है।

पार्सर क्या अपेक्षा करता है

WireGuard कुंजी base64 में मानक पैडिंग के साथ 32 बाइट की कुंजी सामग्री है, जिससे 44 अक्षरों की निश्चित स्ट्रिंग बनती है। उपकरण उस हर चीज़ को अस्वीकार करते हैं जो ठीक 32 बाइट में डिकोड न हो, क्योंकि अंतर्निहित वक्र 32 बाइट का स्केलर लेता है और कुछ नहीं। सार्वजनिक और निजी मान एक ही एन्कोडिंग का उपयोग करते हैं, इसलिए पार्सर केवल प्रारूप से नहीं बता सकता कि आपने कौन-सा चिपकाया। यही अस्पष्टता इस त्रुटि के आसपास की आधी उलझन पैदा करती है।

wg genkey | tee private.key | wg pubkey > public.key
base64 -d private.key | wc -c
wc -c private.key
wg show wg0 public-key

अगर आपका मान 32 बाइट में डिकोड होता है, तो लंबाई ठीक है और शिकायत फ़ाइल में कहीं और से आती है। अगर यह किसी छोटी चीज़ में डिकोड होता है, तो आपके पास कटी हुई सामग्री है, प्रारूप की समस्या नहीं।

प्रारूप की क्षति या ग़लत सामग्री?

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

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

निजी फ़ील्ड में सार्वजनिक कुंजी

सबसे आम उलझन यह है कि सार्वजनिक मान निजी फ़ील्ड में चिपका दिया जाए, या इसका उलटा। दोनों 32 बाइट के मान्य base64 हैं, इसलिए लंबाई की जाँच पास हो जाती है और हैंडशेक बाद में उपयोगी संदेश के बिना विफल हो जाता है। निजी कुंजी वह स्केलर है जो सार्वजनिक कुंजी बनाती है, इसलिए आप सार्वजनिक मान निकालकर और सहकर्मी जिसे अधिकृत करता है उससे तुलना करके इसे तय कर सकते हैं। जब निकाला गया मान रिकॉर्ड से मेल नहीं खाता, तो आपके पास ग़लत पहचान है, टाइपिंग की ग़लती नहीं।

दूसरे सिरे पर अधिकृत सार्वजनिक कुंजी को अपडेट किए बिना क्लाइंट की निजी कुंजी बदलने से वही बेमेल फिर बन जाता है, इस अतिरिक्त उलझन के साथ कि क्लाइंट की अपनी फ़ाइल अब स्वयं-सुसंगत लगती है। एक ही क्रिया में दोनों सिरे बदलें, वरना अगला व्यक्ति ग़लत आधे हिस्से को डीबग करेगा।

प्रोफ़ाइल ठीक करें, फिर हैंडशेक साबित करें

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

wg genkey | tee new.key | wg pubkey > new.pub
base64 -d private.key | wc -c
ip route get 10.60.9.5
wg show wg0 latest-handshakes

आकार की जाँच बताती है कि सामग्री कुंजी-आकार की है या नहीं, और मार्ग का प्रश्न बताता है कि कोई पैकेट कभी इंटरफ़ेस तक पहुँचेगा या नहीं। दोनों जाँच पास होने के बाद भी ख़ाली रहने वाली हैंडशेक पंक्ति निदान को सहकर्मी के एंडपॉइंट और अनुमत पतों की ओर ले जाती है। इंटरफ़ेस की सार्वजनिक कुंजी को प्रोविज़निंग रिकॉर्ड के सामने आख़िरी बार पढ़ें, क्योंकि पुरानी सहेजी गई प्रोफ़ाइल सही लग सकती है जबकि सक्रिय प्रोफ़ाइल अलग हो]।

लिख लें कि आपने कौन-सा मान बदला और अधिकृत प्रतिलिपि कहाँ है। अगली बार इस सहकर्मी को छूने वाले को पता होना चाहिए कि कौन-सा सिरा बदला।