दोन VPN, एक रिझॉल्व्हर: जो शेवटी लिहितो तोच जिंकतो
दोन्ही क्लायंट DNS धोरण स्थापित करू शकतात, आणि शेवटचा लेखक जिंकू शकतो. सफिक्स रिझॉल्व्हरशी जोडा आणि टनेलच्या बाहेर बूटस्ट्रॅप मार्ग ठेवा.
दोन VPN क्लायंट जोडलेले आहेत, एक कामासाठी आणि एक लॅब नेटवर्कसाठी, आणि अंतर्गत नावे फक्त शेवटी जोडलेल्या क्लायंटसाठीच सोडवली जातात। हा नमुना एका क्लायंटमधील बगसारखा दिसतो। साधारणपणे हा कोणते नाव कोणाचे याबद्दल करार न करता एकच रिझॉल्व्हर कॉन्फिगरेशन लिहिणाऱ्या दोन प्रोग्रॅमचा अंदाजित परिणाम असतो।
गैरसमज: सर्वात नवीन VPN कडे DNS आहे
सर्वात अलीकडील कनेक्शन जिंकते असा सामान्य नियम नाही। काय होते ते प्लॅटफॉर्मच्या यंत्रणेवर आणि प्रत्येक क्लायंट ते कसे लिहितो यावर अवलंबून असते। रिझॉल्व्हर फाइल बदलणारा क्लायंट एक परिणाम देतो; प्रत्येक लिंकसाठी डोमेन जोडणारा क्लायंट दुसरा देतो; काहीही न करणारा क्लायंट आधीची स्थिती अभंग ठेवतो।
म्हणून दिसणारे वर्तन दोन अंमलबजावणींचे वैशिष्ट्य आहे, नोंदवलेला प्राधान्यक्रम नाही। केवळ सुरुवातीच्या क्रमावरून विचार करणे कधी बरोबर असेल आणि कधी पुनरुत्पादन करणे कठीण अशा पद्धतीने चूक असेल। त्याऐवजी मॅपिंग लिहून ठेवा। दोन क्लायंटमध्ये राहणारी रचना ही रचना नसते।
नावांच्या जागा रिझॉल्व्हरशी जोडा
खाजगी सफिक्स आणि प्रत्येक नेटवर्कला आवश्यक असलेला रिझॉल्व्हर यांची यादी करा, नंतर सार्वजनिक नावे कुठे जावीत ते ठरवा। ती यादीच रचना आहे। तिच्याशिवाय, क्लायंट अपघाताने निर्णय घेतात।
प्रत्येक लिंकसाठी DNS किंवा राउटिंग डोमेनना समर्थन देणारा प्लॅटफॉर्म विभाजन जाणीवपूर्वक व्यक्त करू शकतो: एक डोमेन एका लिंककडे जाते, दुसरे डोमेन दुसऱ्याकडे, आणि बाकी सर्व स्पष्ट डीफॉल्टचे अनुसरण करते। एकच फाइल पुन्हा लिहिणाऱ्या दोन सपाट स्क्रिप्ट ती रचना टिकवू शकत नाहीत, कारण प्रत्येकाला वाटते की संपूर्ण कॉन्फिगरेशन त्याचेच आहे।
Windows मध्ये, नाव निराकरण धोरण सारणी सफिक्स विशिष्ट सर्व्हरकडे निर्देशित करू शकते, आणि VPN क्लायंट तिथे नियम स्थापित करू शकतो। अॅडॉप्टरच्या यादीऐवजी धोरण तपासा, कारण नाव अॅडॉप्टरची यादी सोडवत नाही।
बूटस्ट्रॅप मार्ग ठेवा
प्रत्येक क्लायंटने स्वतःचा शेवटचा बिंदू शोधला पाहिजे, तोपर्यंत तो त्या बिंदूने दिलेल्या सेवेचा वापर करू शकत नाही। जर शेवटच्या बिंदूचे होस्टनाव केवळ टनेलमधून सोडवता येत असेल, आणि टनेलला सोडवलेले होस्टनाव आवश्यक असेल, तर तुमच्याकडे कनेक्शन टाइमआउट म्हणून दिसणारे चक्रीय अवलंबित्व आहे। दोन्ही टनेलच्या बाहेर एक बूटस्ट्रॅप मार्ग ठेवा। ज्या दिवशी तो कनेक्शन वाचवतो त्या दिवसापर्यंत त्याचा काही खर्च नाही।
प्रत्येक रिझॉल्व्हरकडे जाणारा मार्ग पहा, केवळ त्यासाठी सेट केलेले नाव नाही। जो रिझॉल्व्हर केवळ दुसऱ्या टनेलमधून पोहोचता येतो तो गहाळ असल्यासारखा वागतो, आणि लक्षण राउटिंग त्रुटी नसून टाइमआउट आहे।
आच्छादित पत्ते DNS ची समस्या नाहीत
एकच पत्ता श्रेणी वापरणारे दोन खाजगी नेटवर्क DNS क्रमाने सुधारता येत नाहीत। जर दोन्ही टनेल 10.0.0.0/8 चा दावा करत असतील, तर योग्यरित्या सोडवलेले नावही अशा पत्त्याकडे निर्देश करते जिथे होस्ट योग्य टनेलकडे राउट करू शकत नाही। यासाठी पत्त्याच्या पातळीवर उपाय आवश्यक आहे, जसे वेगळ्या श्रेणी, नावाची जागा किंवा भाषांतर, अजून एक रिझॉल्व्हर सेटिंग नाही। हे लवकर ठरवल्यास कधीही काम न केलेल्या DNS कॉन्फिगरेशनमधून लांब वळण टळते।
नाव निराकरणाला दोष देण्यापूर्वी दोन्ही टनेलच्या पत्ता वाटपांची तुलना करा। जेव्हा दोन्ही बाजू एकच उपसर्ग ढकलतात, तेव्हा होस्ट त्यासाठी एकच मार्ग ठेवतो, आणि दुसऱ्या टनेलमधून सोडवलेले नाव तरीही पहिल्या टनेलच्या मालकीच्या पत्त्यावर उतरते। वेगळ्या श्रेणी, प्रत्येक नेटवर्कसाठी नावाची जागा किंवा भाषांतर हे उपाय आहेत; प्रत्येक क्लायंट जोडल्यानंतर राउट सारणी तुम्ही इच्छित मार्ग दाखवत असल्याची खात्री करा।
खऱ्या अनुप्रयोगांनी ते सिद्ध करा
फक्त स्वतःच्या नावाच्या जागेत अस्तित्वात असलेले दोन होस्ट आणि एक सार्वजनिक नाव निवडा, नंतर प्रत्येकाला तो हवा असलेल्या क्लायंटमधून सोडवा। अपेक्षित रिझॉल्व्हरकडून मिळालेले बरोबर उत्तर अनुप्रयोग होस्टपर्यंत पोहोचतो हे सिद्ध करत नाही, कारण त्या पत्त्याकडे जाणारा मार्ग अजूनही अयशस्वी होऊ शकतो। प्रत्येक शोधानंतर वापरकर्ता प्रत्यक्ष चालवणार असलेल्या प्रोग्रॅममधून कनेक्शन चाचणी करा।
ज्याच्याकडे स्वतःचा एन्क्रिप्टेड DNS पर्याय आहे असा क्लायंट तुम्ही नुकतेच तपासलेले धोरण बायपास करू शकतो, म्हणून पुनरावलोकनाचा भाग म्हणून ती सेटिंग तपासा। नंतर दोन्ही क्लायंट विक्रेत्याने समर्थित क्रमाने पुन्हा जोडा आणि शोधांची पुनरावृत्ती करा; क्रम बदलल्यावर उत्तरे बदलत असतील, तर स्पर्धक लेखक अजूनही कॉन्फिगरेशनचा काही भाग धारण करतो। काहीही संपादित करण्यापूर्वी कोणता घटक नियम स्थापित करतो ते शोधा - क्लायंट, ऑपरेटिंग सिस्टम प्रोफाइल किंवा व्यवस्थापन एजंट। क्रम आणि मालक नोंदवा जेणेकरून पुढच्या व्यक्तीला ते पुन्हा शोधावे लागणार नाहीत।