पुरानी VPN प्रोफ़ाइल में अप्रचलित साइफ़र पंक्तियाँ: कॉपी करने से पहले पढ़ें

यह प्रोफ़ाइल 2016 में लिखी गई थी, और यह अब भी आयात होती है और अब भी जुड़ती है। ठीक इसी कारण कोई इसकी ओर नहीं देखता। जो क्लाइंट एक समय इन निर्देशों को पढ़ता था, वह बहुत पहले जा चुका है, और मौजूदा बिल्ड इनमें से कई को अलग तरह से पढ़ सकता है।

फ़ाइल का बचा रहना यह नहीं दर्शाता कि कॉन्फ़िगरेशन अद्यतित है। इन दो विचारों को अलग करना ही काम का बड़ा हिस्सा है।

पता लगाएँ कि प्रोफ़ाइल किस क्लाइंट ने लिखी

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

OpenVPN सबसे स्पष्ट उदाहरण है। संस्करण 2.5 ने data-ciphers पेश किया और बदला कि पुराना cipher निर्देश बातचीत में कैसे भाग लेता है। केवल cipher AES-128-CBC रखने वाली प्रोफ़ाइल अब अपने लेखक के इरादे से कहीं अधिक संकीर्ण प्रस्ताव देती है।

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

देखें कि वास्तव में क्या तय हुआ

सफल आयात पार्सिंग सिद्ध करता है, नीति नहीं। कनेक्शन उठने के बाद तय किया गया परिणाम क्लाइंट लॉग में दिखता है। यह कॉन्फ़िगरेशन फ़ाइल के दोनों सिरों से भिन्न हो सकता है।

# OpenVPN: what did this session agree on?
sudo journalctl -u openvpn-client@office --since '5 min ago' | grep -i 'cipher\|Data Channel'

# which directives does the profile actually carry?
grep -n -E 'cipher|auth|tls-|dh ' office.ovpn

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

लाइन नहीं, व्यवस्था को उन्नत करें

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

सर्वर को भी समन्वित उन्नयन की आवश्यकता हो सकती है। मौजूदा क्लाइंट ऐसे प्रस्ताव के लिए समर्थन नहीं बना सकता जो सामने वाला पक्ष कभी नहीं देता। क्लाइंट पक्ष का कोई विकल्प अद्यतित न किए गए गेटवे की जगह नहीं ले सकता।

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

परिणाम की पुष्टि करें और अपवाद दर्ज करें

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

पिछला ज्ञात-अच्छा कॉन्फ़िगरेशन किसी सुरक्षित स्थान पर रखें। तुलना केवल तब तक संभव है जब तक पुरानी फ़ाइल मौजूद है।

किसी भी अनुकूलता-अपवाद को स्वामी और समीक्षा तिथि के साथ प्रलेखित करें। जिस अस्थायी व्यवस्था का कोई स्वामी नहीं, वह स्थायी नीति बन जाती है। फ़ाइल पढ़ने वाला अगला व्यक्ति मानेगा कि इसे जानबूझकर चुना गया था।