लगमा P_CONTROL_HARD_RESET_CLIENT_V2: के यो त्रुटि हो?

यो लाइन हरेक केही सेकेन्डमा दोहोरिन्छ र सबैथोकको कारणजस्तो देखिन्छ: control hard reset नामको प्याकेट, कतै नपुग्ने क्लाइन्टबाट आउँछ। यो त्रुटि होइन। यो नयाँ सत्रको पहिलो सन्देश हो, र दोहोरिनु अगाडि अरू केही असफल भइरहेको लक्षण हो। लेबलले के भन्छ र जडानले त्यसपछि के गर्‍यो भन्ने छुट्याउनु नै पूरै निदान हो।

अपकोडले प्रोटोकलमा स्थान जनाउँछ

OpenVPN एउटै सकेटमा धेरै प्रकारका प्याकेट मल्टिप्लेक्स गर्छ, र अपकोडले प्राप्तकर्तालाई कुन प्रकार हातमा छ भन्छ। hard-reset प्याकेटले सत्र खोल्छन्, नियन्त्रण प्याकेटले ह्यान्डसेक सामग्री बोक्छन्, स्वीकृतिले प्राप्ति पुष्टि गर्छन् र डेटा प्याकेटले टनेलको भार बोक्छन्। पहिलो बाइट पढ्दा त्यो आदानप्रदानमा प्याकेट कहाँ पर्छ थाहा हुन्छ, र स्रोत कोडका प्याकेट परिभाषाहरू ले हरेक परिवारको नाम स्पष्ट रूपमा दिन्छन्।

यो त्यति मात्र भन्छ। प्रारम्भिक क्लाइन्ट रिसेट भनी चिन्ह लगाइएको प्याकेटले प्याकेट तपाईंको अवलोकन बिन्दुमा पुग्यो र साथीले सत्र सुरु गर्न चाहन्छ भन्ने प्रमाणित गर्छ। क्लाइन्टले तपाईंको प्रमाणपत्रमा भरोसा गर्‍यो, त्यसका प्रमाणहरू स्वीकारिए वा डेटा च्यानल कहिल्यै उपयोगी भयो भन्ने प्रमाणित गर्दैन।

V2 प्रत्यय त्यो प्याकेट परिवारका लागि प्रोटोकल पुस्ताको चिन्ह हो, उत्पादन संस्करण होइन र तपाईंले स्थापना गर्ने सेटिङ पनि होइन। नाममा टनेल रिसेट गर्ने, सेवा पुनः सुरु गर्ने वा क्यास खाली गर्नेसँग सम्बन्धित केही छैन।

त्यो क्षणमा क्लाइन्टले साँच्चै के गर्दैछ

क्लाइन्टले सत्र पहिचानकर्ता खोल्छ, जसमा दुवै पक्षले अर्को नियन्त्रण ट्राफिक जोड्नेछन्। नियन्त्रण-च्यानल सुरक्षा मिलाइएको भए त्यो पहिलो प्याकेटले पहिले नै HMAC बोक्छ, जसले बाँकी आदानप्रदानमा श्रम गर्नुपर्छ कि भन्ने निर्णय गर्न प्राप्तकर्तालाई सक्षम बनाउँछ। जसले त्यो प्रमाणित गर्न सक्दैन त्यसले प्याकेट चुपचाप फालिदिन्छ, त्यसैले गलत साझा कुञ्जी शून्यमा बोलिरहेको क्लाइन्टजस्तो देखिन्छ।

प्रयोगकर्तालाई देखिने केही अझै भएको छैन। कुनै प्रमाणपत्र प्रमाणित भएको छैन, कुनै प्रयोगकर्तानाम प्रस्तुत भएको छैन र कुनै टनेल ठेगाना तोकिएको छैन। रिसेट ह्यान्डसेकको प्रस्तावना हो, त्यसैले यो क्षणमा जडानबारे कुनै पनि निर्णय अकाल हो।

निष्क्रिय पुनःजडान लूपमा रोचक विवरण अन्तराल हो। प्रगति बिना स्थिर चक्रमा फेरि प्रयास गर्ने क्लाइन्ट सामान्यतया अगाडि बढ्नुअघि नै अस्वीकार गरिन्छ, र कारण प्याकेटको नाममा होइन, साथीको लगमा हुन्छ।

रिसेटपछि वास्तविक असफलता कहाँ लुकेको छ

दुवै लग सँगै पढ्नुहोस् र रिसेट नभएको पहिलो घटना खोज्नुहोस्। क्लाइन्टमा प्रमाणपत्र प्रमाणीकरण असफलता ठोस कारणसहित रिपोर्ट गरिन्छ: म्याद सकिएको प्रमाणपत्र, नाम नमिल्ने वा अज्ञात जारीकर्ता। सर्भरमा प्रमाण अस्वीकार स्वीकृतिको आफ्नै कारणसहित प्रमाणीकरण असफलताका रूपमा रिपोर्ट गरिन्छ। दुवै सर्भरको नयाँ प्रयासतर्फको दोहोरिने दृष्टिकोणभन्दा धेरै ठोस छन्।

हरेक लग अलग पढ्नुको साटो एउटा प्रयासलाई समयछापसँग मिलाउनुहोस्, किनकि त्यही असफलता दुवै ठाउँमा फरक शब्द र फरक तीव्रतासँग देखिन्छ। हार मान्ने साथीले सामान्यतया कारण भन्छ।

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

grep -nE 'VERIFY|AUTH_FAILED|TLS Error|SIGUSR1' /var/log/openvpn*.log

त्यो खोज आफैंमा निदान होइन, तर एकै पाइलामा तपाईंलाई प्रोटोकलको शब्दावलीबाट वास्तविक असफलता वर्गमा सार्छ।

प्रमाणीकरण बन्द गर्नु किन गलत प्रतिक्रिया हो

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

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

सहयोग कुराकानीमा अपकोड एउटा कुराका लागि उपयोगी छ: साथी प्रयास गर्नेसम्म अगाडि बढ्यो भनी बताउँछ। त्यसपछि के भयो त्यही तपाईंले जान्नुपर्ने हो, र पहिलो ठोस अस्वीकार अभिलेख गर्ने लगमा त्यो लेखिएको छ। त्यहीँबाट सुरु गर्नुहोस्, अनि रिसेट लाइन कारणजस्तो देखिन छाडेर समयछापजस्तो देखिन थाल्छ।