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 डंप हे खाजगी की असू शकणाऱ्या फाइलसाठी वाईट ठिकाण आहे, कारण एन्कोडिंगची समस्या सहज दुरुस्त होते, गळलेली की नाही।