OpenVPN रूट निर्देश में वाइल्डकार्ड क्यों काम नहीं कर सकता

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

रूट क्या इंस्टॉल करता है, और क्या कभी नहीं पढ़ता

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

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

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

जब गंतव्य वास्तव में एक प्रीफ़िक्स हो

अगर लक्ष्य कोई ज्ञात निजी नेटवर्क है, तो प्रीफ़िक्स लिखें। दस्तावेज़ीकरण स्थान के उदाहरण के लिए, एक अकेला होस्ट और एक सबनेट ऐसे दिखते हैं:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

दोनों प्रविष्टियाँ पते और मास्क बताती हैं, और दोनों DNS परिवर्तनों को झेल जाती हैं क्योंकि उनमें कुछ भी किसी नाम पर निर्भर नहीं है। यही पूरा लाभ है: रूट टोपोलॉजी के बारे में एक कथन है, उस खोज के बारे में नहीं जो एक बार हुई थी।

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

जब काम की इकाई होस्टनाम हो

डोमेन से चुनने के लिए ऐसा कुछ चाहिए जो डोमेन पढ़े, यानी एप्लिकेशन-परत का घटक। सामान्य उत्तर एक HTTP प्रॉक्सी है जो टनल के दूसरी ओर रहती है, और क्लाइंट तय करता है कि कौन-सी अनुरोध उसे भेजने हैं।

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

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

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

ये नियम एक प्रॉक्सी चुनते हैं; वे उसे बनाते नहीं, और ऑपरेटिंग सिस्टम का कोई रूट नहीं बदलते। प्रॉक्सी पते को अब भी टनल से होकर अपना रास्ता चाहिए, और सीधे के रूप में चिह्नित अनुरोध अब भी वही राउटिंग नीति अपनाते हैं जो मशीन के पास पहले से है।

प्रॉक्सी विकल्प क्या कवर नहीं करता

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

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

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

दोनों रास्तों का परीक्षण, सिर्फ़ सुखद वाले का नहीं

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

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