OpenVPN पहली पंक्ति को अस्वीकार कर रहा है? फ़ाइल शायद UTF-16 है

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

मिथक: एडिटर आपको फ़ाइल दिखाता है

टेक्स्ट एडिटर बाइट को अक्षरों में ऐसी एन्कोडिंग से डिकोड करता है जिसे वह या तो पहचानता है या अनुमान लगाता है। जब वह UTF-16 का अनुमान लगाता है, फ़ाइल स्क्रीन पर निर्दोष दिखती है जबकि उसके नीचे के बाइट जोड़े में हैं, हर लैटिन अक्षर के बाद एक शून्य बाइट आती है। OpenVPN उन बाइट को अक्षरों के रूप में पढ़ता है, और असंगति उस पहले निर्देश पर दिखती है जिसे वह पार्स करने की कोशिश करता है।

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

विफलता के ठोस स्वरूप को पहचानना ज़रूरी है, क्योंकि यह एक ख़ास तरीके से निदानकारी है। फ़ाइल के ठीक शुरू में एक टोकन, ऐसी प्रोफ़ाइल में जो बाकी मामलों में दूसरी मशीनों पर काम कर चुकी है, शब्दावली का नहीं बल्कि बाइट-क्रम का सवाल है।

पहली बाइट वास्तव में क्या कहती हैं

अक्षरों के बजाय बाइट पढ़ें। दो छोटे कमांड इसे सेकंडों में तय कर देते हैं, और किसी को भी फ़ाइल को ऐसे ऐप में खोलने की ज़रूरत नहीं जो उसे बदल सके:

file client.ovpn
head -c 24 client.ovpn | od -An -tx1

आप जिस पैटर्न की तलाश कर रहे हैं वह शुरुआती बाइट का एक जोड़ा है जिसके बाद ऐसा पाठ आता है जिसमें हर दूसरी बाइट शून्य है। FF FE UTF-16 लिटल-एंडियन दर्शाता है, FE FF बिग-एंडियन दर्शाता है, और EF BB BF बाइट-क्रम चिह्न के साथ UTF-8 दर्शाता है। बिना चिह्न वाली सादी UTF-8 फ़ाइल सीधे पहले अक्षर की बाइट से शुरू होती है।

अक्षरों के बीच शून्य बाइट ही मुख्य सुराग हैं। UTF-16 लिटल-एंडियन में client शब्द छह के बजाय बारह बाइट लेता है, क्योंकि हर ASCII अक्षर के बाद एक शून्य आता है। वह संरचना एडिटर का प्रदर्शन आपको नहीं दिखा सकता, और दो बाइट मिटाने से वह हटती भी नहीं है।

यहाँ एक महत्वपूर्ण बारीकी है: OpenVPN का कॉन्फ़िगरेशन पढ़ने वाला फ़ाइल के शुरू में UTF-8 बाइट-क्रम चिह्न को वाकई छोड़ देता है, जैसा 2.6 कॉन्फ़िगरेशन रीडर दिखाता है। वह सहनशीलता ठीक उसी चिह्न के लिए है, और ऐसी UTF-16 फ़ाइल के लिए कुछ नहीं करती जिसके अक्षर शून्य से भरे हैं। दोनों चिह्नों को एक ही समस्या मानना मिथक का दूसरा आधा हिस्सा है।

सुधरी हुई एन्कोडिंग क्या सुधारती नहीं

कुछ भी करने से पहले ऑपरेटर की मूल प्रति अछूती रखें और अलग फ़ाइल पर काम करें। प्रोफ़ाइल में निजी कुंजी या खाते की सामग्री हो सकती है, इसलिए वह प्रति आपका रोलबैक और आपका संदर्भ दोनों है।

फिर वास्तविक एन्कोडिंग रूपांतरण करें, या तो एडिटर के स्पष्ट एन्कोडिंग मेनू से या ऐसे कनवर्टर से जो अपनी इनपुट और आउटपुट एन्कोडिंग बताता है:

iconv -f UTF-16 -t UTF-8 client.ovpn > client-utf8.ovpn
file client-utf8.ovpn

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

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

सुधरी हुई एन्कोडिंग क्या नहीं सुधारती

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

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

जब तक इस पर काम कर रहे हैं, जाँच को स्थानीय रखें। सार्वजनिक ऑनलाइन कनवर्टर और चिपकाए गए hex डंप ऐसी फ़ाइल के लिए बुरी जगह हैं जिसमें निजी कुंजी हो सकती है, क्योंकि एन्कोडिंग की समस्या आसानी से सुधर जाती है और लीक हुई कुंजी नहीं।