0x या 0s? ipsec.secrets में PSK फ़ॉर्मैट को समझना

एक क्लाइंट साझा कुंजी से प्रमाणीकरण करता है और दूसरा उसे अस्वीकार कर देता है, जबकि आपके द्वारा चिपकाए गए अक्षर दोनों ओर एक जैसे दिखते हैं। संभवतः वही अक्षर हैं; अंतर यह है कि फ़ाइल उन पर कौन-सा डिकोडिंग नियम लागू करती है। उद्धरण चिह्नों में दिया गया स्ट्रिंग शब्दशः लिया जाता है, 0x से शुरू होने वाला टोकन हेक्साडेसिमल के रूप में पढ़ा जाता है, और 0s से शुरू होने वाला टोकन Base64 के रूप में पढ़ा जाता है। इन तीन लेखन-तरीक़ों में से केवल एक ही वह अर्थ देता है जो आपका इरादा था, इसलिए सुधार आम तौर पर एक रूपांतरण होता है, बेहतर पासवर्ड नहीं।

लक्षण एन्कोडिंग की ओर इशारा करता है, सिफ़र की ओर नहीं

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

चरण ही सुराग है। चुने गए प्रस्ताव के बाद आने वाली विफलता का अर्थ है कि दोनों पक्ष कुंजी सामग्री के अतिरिक्त सब कुछ पर सहमत थे, जबकि «कोई प्रस्ताव नहीं चुना गया» नीति या सिफ़र-सेट से संबंधित है। पासवर्ड सही दिखते हुए विफल होने वाला अखंडता परीक्षण एन्कोडिंग असंगति का दृश्य चेहरा है।

एक रहस्य, फ़ाइल इसे पढ़ सकती है तीन तरह से

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

10.20.0.5 %any : PSK "key1"
10.20.0.5 %any : PSK 0x6b657931
10.20.0.5 %any : PSK 0sa2V5MQ==

उस ब्लॉक की दो बातें सबसे अधिक समय लेती हैं। हेक्साडेसिमल अंक दोनों केस स्वीकार करते हैं, इसलिए 0x6b657931 और 0x6B657931 एक ही मान हैं, लेकिन विषम संख्या में अक्षर अस्वीकार होने के बजाय चुपचाप ग़लत पढ़े जाते हैं, जिससे कट के बाद का हर बाइट खिसक जाता है। Base64 पैडिंग मान का हिस्सा है, इसलिए अंतिम = चिह्नों के बिना चिपकाया गया स्ट्रिंग ज़ोर से विफल होने के बजाय अलग बाइट में डिकोड होता है।

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

Base64 टेक्स्ट कहाँ से आता है

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

दोनों दिशाएँ एक-एक कमांड हैं, और उन्हें टिकट में उसी सटीक क्रिया के रूप में रखना उचित है जिसने संग्रहीत मान बनाया। उन्हें इस क्रम में चलाएँ:

printf '%s' 'a2V5MQ==' | base64 -d
printf '%s' 'key1' | base64

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

पुष्टि करें कि हर साथी वास्तव में कौन-से बाइट इस्तेमाल करता है

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

फ़ाइल सही होने पर फिर से शुरू करने के बजाय फिर से लोड करें। ipsec rereadsecrets IKE डेमन की प्रति ताज़ा करता है, और swanctl सेटअप अपने ही कमांड से क्रेडेंशियल लोड करता है। फिर से शुरू करने से हर स्थापित संबंध छूट जाता है और आप जो तुलना करना चाहते थे वह नष्ट हो जाती है।

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

परिणाम छिपाए बिना फ़ाइल बदलें

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

ऐसे क्लाइंट से परीक्षण करें जिसका कॉन्फ़िगरेशन आपके नियंत्रण में है, पुष्टि करें कि प्रमाणीकरण सफल होता है, और फिर पुष्टि करें कि टनल ट्रैफ़िक ढोती है। जो पुनः-लोड हैंडशेक ठीक करता है पर रूटिंग टूटी रहती है वह दूसरी समस्या है, और रहस्य के थमते ही वह दिखाई देने लगती है।