OpenVPN त्रुटि: tls-remote वा keysize विकल्प अपरिचित
नयाँ OpenVPN क्लाइन्टले tls-remote र keysize जस्ता पुराना प्रोफाइल लाइनहरू अस्वीकार गर्छ। विकल्पको नाम पढ्नुहोस्, जाँच बदल्नुहोस् र प्रमाणीकरण चालु राख्नुहोस्।
सामान्यतया यो वर्षौंदेखि जोडिएको प्रोफाइल नयाँ क्लाइन्टमा खोल्दा टनेल सुरु हुनुअघि नै असफल भएर सुरु हुन्छ। टर्मिनलले Options error: Unrecognized option ... in client.ovpn:130: tls-remote जस्तो केही छाप्छ, अन्त्यमा कोष्ठकमा संस्करण हुन्छ। यसलाई पार्सरको गुनासोका रूपमा पढ्नुहोस्: फाइलमा यो क्लाइन्टलाई अब थाहा नभएको निर्देशन छ।
यही एउटा सन्देशले किन कुञ्जीहरू पुनः सिर्जना गर्नु, पासवर्ड फेरि टाइप गर्नु वा सर्भर जाँच गर्नु केही गर्दैन भनेर बताउँछ। क्लाइन्ट आफ्नै कन्फिगरेसन पढ्दै गर्दा, सकेट खोल्नुअघि नै असफलता हुन्छ। उपयोगी काम भनेको अस्वीकृत निर्देशन पहिचान गरी त्यसलाई हालको समकक्षले बदल्नु हो।
केही पनि बदल्नुअघि असफल हुने लाइन पढ्नुहोस्
क्लाइन्टलाई ट्रे आइकनबाट सुरु गर्नुको सट्टा आफैं चलाउनुहोस्, ताकि सन्देश देखियोस् र प्रोफाइलको बाटो अस्पष्ट नहोस्। देखाइएको लाइनमा फाइल खोल्नुहोस् र क्लाइन्टले नाम दिएको टोकन हेर्नुहोस्। लाइन नम्बर प्रोफाइलको लाइन हो, संस्करण होइन, जसले मानिसहरूलाई अलमल्याउँछ किनभने त्यही नम्बर कोष्ठकमा संस्करण पहिचानकर्ताका रूपमा देखिन्छ।
पुराना प्रोफाइल जेनेरेटरहरूले एउटा खराब निर्देशन होइन, धेरै निर्देशन दिन्थे। पहिलो त्रुटि सुधार्नुहोस्, क्लाइन्ट फेरि चलाउनुहोस् र अर्को आउने अपेक्षा गर्नुहोस्। त्यो क्रम सामान्य हो र परिवर्तनले अवस्था बिगारेको संकेत होइन।
keysize र tls-remote लाई के भयो
keysize प्रोफाइलले सिफर स्पष्ट रूपमा छान्ने युगमा सिफर कुञ्जीको लम्बाइ माग्थ्यो। OpenVPN 2.4 ले यसलाई अप्रचलित घोषणा गर्यो, र पछिका क्लाइन्टहरूले यसलाई विकल्प तालिकाबाट हटाए, त्यसैले पार्सर अब लाइनलाई बेवास्ता गर्नुको सट्टा अस्वीकार गर्छ। आधुनिक वार्ताले छानिएको सिफरबाट कुञ्जीको लम्बाइ निकाल्छ, त्यसैले निर्देशनसँग नियन्त्रण गर्न केही बाँकी छैन।
tls-remote 2.4 मा हटाइयो। यसले सर्भर प्रमाणपत्रलाई अपेक्षित नामसँग तुलना गर्थ्यो, र यसको प्रतिस्थापन verify-x509-name हो, जो नाम कसरी मिलाइन्छ भन्नेमा बढी कडा छ। पुरानो निर्देशन गयो, त्यसैले यो बोकेको प्रोफाइल हालको क्लाइन्टमा कहिल्यै पार्स हुनेछैन।
प्रत्येक प्रयासमा एउटा निर्देशन सुधार्नुहोस्। यदि प्रोफाइलले क्लाइन्टले नदिने सिफर पनि निर्दिष्ट गर्छ भने, त्यसले पछि अर्को त्रुटि उत्पन्न गर्छ, र दुवै परिवर्तन एउटै सम्पादनमा मिसाउँदा कुनले ह्यान्डशेक तोड्यो भन्न असम्भव हुन्छ। प्रत्येक सम्पादनपछि फेरि जोड्नुहोस् र त्रुटिको पाठ राख्नुहोस्। यो बानीले सम्पादनले अवस्था बिगारेमा काम गर्ने विकल्प पनि छोड्छ।
सर्भर पहिचान जाँच फेरि लेख्नुहोस्
प्रतिस्थापनले अपेक्षित नाम र तुलना मोड लिन्छ। verify-x509-name vpn.example.edu name ले प्रमाणपत्रको विषय ठ्याक्कै त्यो मानसँग बराबर हुनुपर्ने माग गर्छ। अन्य मोडहरूले उपसर्ग वा पूर्ण विषय स्ट्रिङ मिलाउँछन्, र गलत मोड छान्दा काम गर्ने प्रोफाइल सफा प्रमाणीकरण असफलतामा बदलिन्छ।
यदि पुरानो tls-remote तर्क सर्भरको पूर्ण सामान्य नाम थियो भने, सही name तुलना सामान्यतया ठीक हुन्छ। यदि यो आंशिक मान थियो भने, अपेक्षित नाम छोट्याउनुको सट्टा उपसर्ग मोड प्रयोग गर्नुहोस्, किनभने छोटो सही मिलान प्रमाणित हुँदैन। जब मूल मान लेखिएको छैन, सर्भर चलाउनेलाई उनीहरूले प्रकाशित गर्ने विषय सोध्नुहोस्।
त्रुटि हराउन जाँचलाई शान्त नपार्नुहोस्। सर्भर पहिचान प्रमाणीकरण हटाउँदा सुधार्न सकिने प्रोफाइल समस्या अप्रमाणित टनेलमा बदलिन्छ, र यो ठ्याक्कै त्यो जोखिम हो जसलाई रोक्न निर्देशन अस्तित्वमा थियो।
सुधारिएको प्रोफाइल, स्थानीय सम्पादन वा पुरानो क्लाइन्ट
जब सर्भर अरू कसैको हो, सबैभन्दा सफा बाटो उनीबाट प्राप्त हालको प्रोफाइल हो। तपाईंको प्रतिलिपि पुरानो जेनेरेटरबाट आएको हो, र उनीहरूको निर्यात पहिले नै हालका निर्देशनहरू प्रयोग गर्छ। एउटा डाउनलोडले त्रुटिको सम्पूर्ण वर्ग हटाउँछ र भविष्यका सम्पादन एकै ठाउँमा राख्छ।
जब दुवै छेउ तपाईंका हुन्, प्रतिलिपि सम्पादन गर्नुहोस् र मूल राख्नुहोस्। एउटा निर्देशन बदल्नुहोस्, सुरक्षित गर्नुहोस्, जोड्नुहोस् र परीक्षण गरिएको क्लाइन्ट संस्करण लेख्नुहोस्। प्रत्येक सम्पादनको छेउमा छोटो टिप्पणी राख्नुहोस्, किनभने धेरै सत्रमा सम्पादित प्रोफाइल स्मृतिबाट लेखापरीक्षण गर्न गाह्रो हुन्छ। सम्पादित फाइलमा कमाण्ड लाइन चलाउँदा त्यो लुप छिटो हुन्छ किनभने त्रुटि सिधै टर्मिनलमा जान्छ।
2.4 अघिको क्लाइन्टमा पिन गर्नु वा फर्कनुले पनि सन्देश हराउँछ, र कहिल्यै अद्यावधिक नहुने उपकरणसँग त्यो एकमात्र व्यावहारिक अस्थायी उपाय हुन सक्छ। यसलाई अस्थायी मान्नुहोस्: हालको डेस्कटपमा पुरानो क्लाइन्टले सामान्यतया पुरानो पुस्तकालय र असमर्थित कन्फिगरेसन जनाउँछ, जो समाधान नभई स्थगित समस्या हो।
टनेल माथि आएपछि पूरै प्रोफाइल अर्को पटक पढ्नुहोस्। एउटा हटाइएको निर्देशन बोकेका प्रोफाइलहरू प्रायः अर्को पनि बोक्छन्, र दोस्रो पहिलो गएपछि मात्र देखिन्छ।