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 डम्प निजी कुञ्जी हुन सक्ने फाइलका लागि खराब ठाउँ हुन्, किनकि एन्कोडिङको समस्या सजिलै सुधारिन्छ, चुहिएको कुञ्जी सुधारिँदैन।