Pritunl का निजी DNS विफल? एक संकीर्ण रिज़ॉल्वर रूट जोड़ें

निजी नाम कॉर्पोरेट नेटवर्क पर सभी के लिए रिज़ॉल्व होते हैं और VPN पर सभी के लिए समय-समाप्त हो जाते हैं। रिज़ॉल्वर गेटवे को उत्तर देता है, उस तक रूट मौजूद है, और क्वेरी को फिर भी कभी उत्तर नहीं मिलता। जो गायब है वह दूसरा सार्वजनिक रिज़ॉल्वर या व्यापक रूट नहीं है: वह स्रोत पता है जिस पर निजी DNS सर्वर उत्तर देने को तैयार है।

पुष्टि करें कि रिज़ॉल्वर आपके क्लाइंट पूल को अस्वीकार कर रहा है

साबित करके शुरू करें कि विफलता स्रोत की है, पहुँच की नहीं। जुड़े हुए क्लाइंट से निजी रिज़ॉल्वर से सीधे क्वेरी करें और देखें कि अनुरोध समय-समाप्त होता है या अस्वीकृति के रूप में लौटता है। dig @10.40.0.53 intranet.example.net +time=2 +tries=1 का समय-समाप्त होना जबकि गेटवे से वही क्वेरी सफल होती है, रिज़ॉल्वर पर एक्सेस नीति की ओर इशारा करता है। SERVFAIL उत्तर पूरी तरह कहीं और, आमतौर पर ज़ोन या अपस्ट्रीम फ़ॉरवर्डर की ओर इशारा करता है।

परीक्षण से पहले क्लाइंट का पता नोट करें। क्लाइंट पर ip -4 addr show tun0, या कंसोल में दिखाया गया लीज़, बताता है कि रिज़ॉल्वर कौन सा पूल देखता है।

फिर पुष्टि करें कि मार्ग बिल्कुल मौजूद है। जो रूट रिज़ॉल्वर के पते को टनल में भेजता है वह पूर्वशर्त है, समाधान नहीं; यदि पैकेट कभी नहीं पहुँचते, तो स्रोत नीति पर कभी विचार ही नहीं होता। क्लाइंट पर ip route get 10.40.0.53 से इसे जाँचें।

सब कुछ अनुवाद करने के बजाय एक होस्ट रूट जोड़ें

Pritunl का निजी-DNS मार्गदर्शन संकीर्ण उपाय बताता है: रिज़ॉल्वर पते के लिए NAT-सक्षम /32 रूट, उस पते को क्लाइंट के DNS सर्वर के रूप में चुनकर। रूट केवल DNS ट्रैफ़िक के लिए वह स्रोत बदलता है जो रिज़ॉल्वर देखता है। एप्लिकेशन ट्रैफ़िक आपके द्वारा उसके लिए चुना गया स्रोत-संरक्षी डिज़ाइन बनाए रखता है।

मौजूदा रूट की ओवरलैप के लिए समीक्षा के बाद, सर्वर के समर्थित रूट मालिक के माध्यम से इसे कॉन्फ़िगर करें। ऊपर के उदाहरण में गंतव्य NAT-सक्षम 10.40.0.53/32 है, और क्लाइंट पूल 10.90.0.0/24 रहता है। एक सेवा ठीक करने के लिए पूरी निजी श्रेणी का अनुवाद न करें, क्योंकि क्लाइंट के वास्तविक पते पर निर्भर हर डाउनस्ट्रीम नीति उसके बजाय गेटवे देखने लगेगी। परीक्षण लुकअप के दौरान उसका क्वेरी लॉग देखकर पुष्टि करें कि रिज़ॉल्वर वास्तव में कौन सा पता प्राप्त करता है। अकेला होस्ट रूट अनुवाद या अनुमति के बारे में कुछ साबित नहीं करता।

रिज़ॉल्वर को अभी भी UDP और TCP पर अनूदित स्रोत की अनुमति देनी होगी, और उसके उत्तर लौट सकने चाहिए। स्रोत बदलकर गायब ज़ोन या रिकॉर्ड नहीं बनाया जा सकता।

तय करें कि सर्वर क्वेरी भेजता है या क्लाइंट

Pritunl, VPN Client DNS Mapping से जुड़ी DNS-प्रॉक्सी व्यवस्था का भी दस्तावेज़ीकरण करता है, जहाँ सर्वर क्लाइंट की ओर से अपस्ट्रीम क्वेरी फ़ॉरवर्ड करता है। उस मॉडल में अपस्ट्रीम स्रोत सर्वर के अपने नेटवर्क संदर्भ का है, और क्लाइंट-पक्ष अपवाद गलत समाधान है।

कुछ भी जोड़ने से पहले पहचानें कि कौन सा मॉडल सक्रिय है। तीन ओवरलैपिंग मरम्मत, एक प्रॉक्सी, क्लाइंट रिज़ॉल्वर ओवरराइड और एक मैन्युअल NAT स्क्रिप्ट आमतौर पर बताते हैं कि किसी ने स्थापित नहीं किया: किस घटक को क्वेरी भेजनी चाहिए। bootstrap भी जाँचें: टनल बनने से पहले एंडपॉइंट खोजने का एकमात्र तरीका केवल-निजी रिज़ॉल्वर नहीं हो सकता, और स्थायी रिज़ॉल्वर संपादन कनेक्शन से अधिक नहीं टिकना चाहिए।

निजी लुकअप जाँचें, सार्वजनिक वेब पेज नहीं

परिवर्तन लागू करने और फिर से जुड़ने के बाद, क्लाइंट का प्रभावी रिज़ॉल्वर कॉन्फ़िगरेशन जाँचें, फिर ऐसा नाम रिज़ॉल्व करें जिसके बारे में आप जानते हैं कि वह केवल निजी ज़ोन में है। स्पष्ट सर्वर के बिना dig intranet.example.net दिखाता है कि क्लाइंट वास्तव में क्या उपयोग करता है। इसके बाद उस पते पर अनुरोध भेजें जो उस लुकअप ने लौटाया, क्योंकि रिज़ॉल्यूशन और सेवा पहुँच अलग कदम हैं। DNS-over-HTTPS से सार्वजनिक साइटें लोड करने वाला ब्राउज़र ऑपरेटिंग सिस्टम के निजी रिज़ॉल्वर पथ के बारे में कुछ साबित नहीं करता। सार्वजनिक द्वितीयक रिज़ॉल्वर भी आंतरिक ज़ोन के लिए प्राधिकारी नहीं है।

रिज़ॉल्वर पता, /32 रूट और क्लाइंट DNS सेटिंग को साथ में सर्वर नोट्स में दर्ज करें। उस कॉन्फ़िगरेशन का आधा अकेले बहाल करने पर मूल विफलता दोबारा होती है।

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