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

इनमें से अधिकांश टूटन के लिए दो तंत्र ज़िम्मेदार हैं। उन्हें अलग करना ही असली काम है।

आपके नीचे नेगोशिएशन में क्या बदला

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

क्लाइंट पर असर असममित है। कंट्रोल चैनल ऊपर आता है, प्रमाणीकरण सफल होता है, और फिर टनल मर जाती है, जो अस्वीकृत प्रोफ़ाइल नहीं बल्कि नेगोशिएशन में असंगति का संकेत है।

सर्वर के बारे में सिद्धांत बनाने से पहले इंस्टॉल किया गया संस्करण पढ़ें। वह स्ट्रिंग एक स्थानीय तथ्य है जिसे आप किसी से पहुँच मांगे बिना जाँच सकते हैं।

प्रोफ़ाइल पार्स हो सकती है और कुछ और मतलब रख सकती है

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

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

openvpn --version | head -n 2
openvpn --show-ciphers | head -n 10
grep -nE '^(cipher|data-ciphers|ncp-|tls-)' office.ovpn

प्लेटफ़ॉर्म भी उसी समय हिला

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

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

जिस घटना ने रिपोर्ट शुरू की उसे फिर से जाँचें

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

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

संबंधित लेख