WireGuard भन्छ निजी कुञ्जीको लम्बाइ गलत छ: अब के गर्ने?
base64 मा 32 बाइटको कुञ्जी 44 अक्षरको हुन्छ। केही पनि पुनः सिर्जना गर्नु अघि तपाईंको पाठ बिग्रिएको हो वा पहिचान गलत हो निर्णय गर्नुहोस्।
सन्देश भन्छ निजी कुञ्जीको लम्बाइ गलत छ, र त्यो शब्दावली पहिले इन्कोडिङतर्फ र त्यसपछि क्रिप्टोग्राफीतर्फ संकेत गर्छ। 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
आकार जाँचले सामग्री कुञ्जी-आकारको छ कि भन्ने जवाफ दिन्छ, र मार्ग प्रश्नले प्याकेट कहिल्यै इन्टरफेसमा पुग्छ कि भन्ने जवाफ दिन्छ। दुवै जाँच पास भएपछि पनि खाली रहने ह्यान्डसेक लाइनले निदानलाई सहकर्मीको अन्त्य बिन्दु र अनुमत ठेगानातर्फ सार्छ। इन्टरफेसको सार्वजनिक कुञ्जी प्रोभिजनिङ रेकर्डसँग अन्तिम पटक पढ्नुहोस्, किनकि पुरानो सुरक्षित प्रोफाइल सही देखिन सक्छ जबकि सक्रिय प्रोफाइल फरक हुन्छ]।
तपाईंले कुन मान बदल्नुभयो र अधिकृत प्रतिलिपि कहाँ छ लेख्नुहोस्। अर्को पटक यो सहकर्मीलाई छुने व्यक्तिले कुन छेउ बदलियो जान्नुपर्छ।