आपकी .ovpn फ़ाइल कोड चला सकती है, केवल ट्रैफ़िक रूट नहीं

ज़्यादातर लोग .ovpn फ़ाइल को वैसे पढ़ते हैं जैसे राउटर का सेटिंग्स पेज पढ़ते हैं: पते, रूट, सिफ़र की सूची। कोड चलाने वाला हिस्सा नीचे की ओर बैठता है, ऐसे निर्देशों के बगल में जो प्लंबिंग का काम लगते हैं, और वह उसी विशेषाधिकार के साथ चलता है जो क्लाइंट के पास पहले से है। यही वह खाई है जिसका फ़ायदा लापरवाह या दुर्भावनापूर्ण प्रोफ़ाइल उठाता है, और यही वह खाई है जो एक उपयोगी DNS सहायक को तीन हफ़्ते बाद सपोर्ट समस्या में बदल देती है। इवेंट निर्देश, सुरक्षा स्तर और फ़ाइल का स्वामित्व तय करते हैं कि क्या हो सकता है; स्क्रिप्ट की सामग्री तय करती है कि वास्तव में क्या होता है। जुड़ने से पहले चारों पढ़ें।

सहायक चलाने वाली प्रोफ़ाइल एक प्रोग्राम है, सेटिंग्स फ़ाइल नहीं

route और dhcp-option जैसे निर्देश उस स्थिति का वर्णन करते हैं जो क्लाइंट को स्थापित करनी चाहिए, और क्लाइंट उन्हें डेटा की तरह मानता है। up स्क्रिप्ट अलग है: क्लाइंट उसे प्रोसेस के रूप में शुरू करता है और कनेक्शन के ब्यौरों से भरा वातावरण देता है, इसलिए इसके लेखक ने जो कुछ लिखा, वह आपके खाते के अधिकारों के साथ चलता है। जिस लैपटॉप में उपयोगकर्ता एडमिन है, वहाँ यह अटैचमेंट या फ़ोरम थ्रेड से चिपकाई गई फ़ाइल के लिए चौड़ा दरवाज़ा है। अंतर शैली का नहीं, यह कॉन्फ़िगरेशन और कोड का अंतर है।

जिस मिथक को छोड़ देना चाहिए वह यह है कि प्रोफ़ाइल केवल ट्रैफ़िक को दिशा बदल सकती है। ip route add चलाने वाला सहायक और दूरस्थ होस्ट के विरुद्ध curl चलाने वाला सहायक एक ही तंत्र हैं, और प्रोफ़ाइल बाहर से एक जैसी दिखती है। फ़ाइल के रूप में कुछ भी नहीं बताता कि आपके पास कौन-सी है, इसलिए समीक्षा को स्क्रिप्ट तक पहुँचना ही होगा।

वास्तव में निष्पादन क्या तय करता है, और सक्षम करने वाली पंक्तियाँ कैसी दिखती हैं

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

script-security 2
up /etc/openvpn/update-resolv-conf.sh
down /etc/openvpn/update-resolv-conf.sh

स्तर 0 बाहरी प्रोग्राम अस्वीकार करता है और स्तर 1, जो डिफ़ॉल्ट है, केवल क्लाइंट के अंतर्निहित निष्पादन-योग्य फ़ाइलों की अनुमति देता है, इसलिए हुक को 2 या अधिक चाहिए; स्तर 3 मुख्य रूप से पुराने पासवर्ड पारित करने के लिए है और इससे बचना बेहतर है। हुक के साथ भेजी गई प्रोफ़ाइल को निर्देश और वह स्तर दोनों चाहिए, इसलिए फ़ाइल के निचले हिस्से की एक पंक्ति उतनी ही जाँच की हक़दार है जितनी प्रमाणपत्र ब्लॉक। OpenVPN मैनुअल अनुमति स्तरों की सूची देता है, और उसका शब्दांकन प्रोफ़ाइल की वास्तविक माँग के साथ पढ़ने लायक है।

स्वामित्व, पथ और सहायक को क्या खिलाया जाता है

जिस प्रोफ़ाइल पर आप भरोसा करते हैं पर जो ऐसी स्क्रिप्ट की ओर इशारा करती है जिसे दूसरा खाता फिर से लिख सकता है, वह भरोसेमंद व्यवस्था नहीं है, क्योंकि कल की समीक्षा अब यह नहीं बताती कि आज क्या चलता है। सहायक का स्वामी और मोड जाँचें, और जाँचें कि कॉन्फ़िगर किया गया पथ उसी फ़ाइल तक पहुँचता है जिसकी आपने जाँच की, न कि ऐसे नाम तक जिसे कोई और ढक सके। आर्ग्युमेंट और वातावरण भी उसी नज़र के हक़दार हैं: क्लाइंट हुक को कनेक्शन का ब्यौरा देता है, और अपना पूरा वातावरण लॉग करने वाला सहायक सपोर्ट टिकट में क्रेडेंशियल लिख सकता है। ऑपरेटर या प्लेटफ़ॉर्म के प्रलेखित एकीकरण को असंबद्ध पोस्ट से कॉपी की गई DNS स्क्रिप्ट पर प्राथमिकता दें, क्योंकि एक ही फ़ाइल पर झगड़ते दो रिज़ॉल्वर प्रबंधक ऐसी विफलता पैदा करते हैं जो टूटे VPN जैसी दिखती है।

जब किसी विफल हुक की रिपोर्ट करें, तो उसे कहीं भी चिपकाने से पहले वातावरण को संपादित करें। जो डंप आपको डीबग करने में मदद करता है, वह वह टोकन भी ले जा सकता है जो आपको प्रमाणित करता है।

सफ़ाई की विफलताएँ सुरंग जाने के बाद दिखती हैं

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

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

सहायक की समीक्षा और निकास रखना

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

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