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 फाइल नाही तर रूट टेबल घेतात, म्हणून त्या प्रकरणांना समर्थित प्रत्येक अनुप्रयोगासाठी यंत्रणा किंवा वेगळी रचना लागते। ब्राउझर नियम कार्यप्रवाह व्यापतो असे वचन देण्यापूर्वी महत्त्वाच्या क्लायंटची यादी करा।

थेट परत जाणेही सुटकेचा मार्ग नाही। जर मशीनचे राउटिंग धोरण आधीच सर्व काही टनेलमध्ये पाठवत असेल, तर थेट असे चिन्हांकित विनंती त्याच्या आतच राहते, कारण प्रॉक्सी निवड आणि रूट टेबल वेगवेगळ्या स्तरांवर घेतलेले वेगवेगळे निर्णय आहेत।

नावे सोडवणे हा तिसरा वेगळा प्रश्न आहे। कोणत्या विनंत्या प्रॉक्सीकडे जातात हे निवडणे त्यांना कोणता रिझोल्व्हर उत्तर देतो याबद्दल काहीही सांगत नाही, आणि दोन्हींना एक सेटिंग म्हणून हाताळल्यास बाहेरून कोणी तपासणार नाही तोपर्यंत अदृश्य असलेली गळती तयार होते। प्रत्येक क्वेरीला कुठे उत्तर दिले जाते ते ठरवा आणि तो निर्णय प्रॉक्सी नियमाच्या शेजारी लिहा। टनेल वर आल्यामुळे बदलणारा रिझोल्व्हर उत्तर शांतपणे हलवेल।

दोन्ही मार्गांची चाचणी, फक्त आनंददायी मार्गाची नाही

जुळायला हवे असे होस्टनाव, जुळायला नको असे होस्टनाव, आणि डोमेनचे शिखर यांची चाचणी करा, कारण केवळ-प्रत्यय नियम सर्वाधिक चुकवतो ते शिखरच। नंतर पृष्ठ लोड झाले की नाही यावरून अंदाज न लावता प्रत्येक विनंतीने प्रत्यक्षात कोणता मार्ग घेतला हे सुनिश्चित करा।

शेवटी, अयशस्वी शाखेची चाचणी करा। पोहोचता न येणाऱ्या प्रॉक्सीने तुम्ही आधीच ठरवलेल्या पद्धतीने अयशस्वी व्हावे, शांतपणे थेट कनेक्शनकडे परत न जाता। नेटवर्क पर्यायांचा संदर्भ रूट पॅरामीटर्स अचूकपणे नोंदवतो; या रचनेचा डोमेन अर्धा भाग पूर्णपणे त्याच्या बाहेर आहे।