Pritunl को निजी DNS असफल हुन्छ? एउटा साँघुरो resolver मार्ग थप्नुहोस्

निजी नामहरू कर्पोरेट नेटवर्कमा सबैका लागि समाधान हुन्छन् र VPN मा सबैका लागि समय सकिन्छ। Resolver गेटवेलाई जवाफ दिन्छ, त्यहाँसम्मको मार्ग अवस्थित छ, र क्वेरीले अझै कहिल्यै जवाफ पाउँदैन। कमी भएको कुरा अर्को सार्वजनिक resolver वा फराकिलो मार्ग होइन: निजी DNS सर्भर जवाफ दिन तयार भएको स्रोत ठेगाना हो।

Resolver ले तपाईंको क्लाइन्ट पूल अस्वीकार गरिरहेको पुष्टि गर्नुहोस्

असफलता पहुँचको होइन, स्रोतको हो भनी प्रमाणित गरेर सुरु गर्नुहोस्। जोडिएको क्लाइन्टबाट निजी resolver लाई सिधै क्वेरी गर्नुहोस् र अनुरोधको समय सकिन्छ कि अस्वीकृतिको रूपमा फर्किन्छ हेर्नुहोस्। dig @10.40.0.53 intranet.example.net +time=2 +tries=1 को समय सकिँदा गेटवेबाट त्यही क्वेरी सफल हुनुले resolver मा पहुँच नीति देखाउँछ। SERVFAIL जवाफ पूर्ण रूपमा अर्कै ठाउँ, सामान्यतया जोन वा माथिल्लो फर्वार्डरतर्फ संकेत गर्छ।

परीक्षण गर्नुअघि क्लाइन्टको ठेगाना नोट गर्नुहोस्। क्लाइन्टमा ip -4 addr show tun0, वा कन्सोलमा देखाइएको लीजले resolver कुन पूल देख्छ भनी बताउँछ।

त्यसपछि मार्ग नै अवस्थित छ कि भनी पुष्टि गर्नुहोस्। Resolver को ठेगाना टनेलमा पठाउने मार्ग पूर्वशर्त हो, समाधान होइन; यदि प्याकेट कहिल्यै पुगेन भने स्रोत नीतिको कुनै विचार हुँदैन। क्लाइन्टमा ip route get 10.40.0.53 प्रयोग गरी जाँच्नुहोस्।

सबै कुरा अनुवाद गर्नुको सट्टा एउटा होस्ट मार्ग थप्नुहोस्

Pritunl को निजी DNS मार्गदर्शनले साँघुरो उपाय वर्णन गर्छ: resolver ठेगानाका लागि NAT सक्षम /32 मार्ग, त्यो ठेगाना क्लाइन्टको DNS सर्भरका रूपमा छानेर। मार्गले DNS ट्राफिकका लागि मात्र resolver ले देख्ने स्रोत बदल्छ। अनुप्रयोग ट्राफिकले तपाईंले त्यसका लागि छान्नुभएको स्रोत-संरक्षण डिजाइन कायम राख्छ।

अवस्थित मार्गहरू ओभरल्यापका लागि समीक्षा गरेपछि सर्भरको समर्थित मार्ग मालिकमार्फत यसलाई कन्फिगर गर्नुहोस्। माथिको उदाहरणमा गन्तव्य NAT सक्षम 10.40.0.53/32 हो, र क्लाइन्ट पूल 10.90.0.0/24 रहन्छ। एउटा सेवा ठीक गर्न सम्पूर्ण निजी दायरा अनुवाद नगर्नुहोस्, किनकि क्लाइन्टको वास्तविक ठेगानामा निर्भर हरेक तल्लो नीतिले त्यसको सट्टा गेटवे देख्न थाल्नेछ। परीक्षण खोजीका क्रममा resolver को क्वेरी लग हेरेर यसले वास्तवमै कुन ठेगाना पाउँछ पुष्टि गर्नुहोस्। होस्ट मार्ग मात्रले अनुवाद वा अनुमतिको बारेमा केही प्रमाणित गर्दैन।

Resolver ले अझै पनि अनुवादित स्रोतलाई UDP र TCP मा अनुमति दिनुपर्छ, र यसका जवाफहरू फर्किन सक्नुपर्छ। स्रोत बदल्दा हराएको जोन वा रेकर्ड बन्न सक्दैन।

क्वेरी सर्भरले पठाउँछ कि क्लाइन्टले भन्ने निर्णय गर्नुहोस्

Pritunl ले VPN Client DNS Mapping सँग जोडिएको DNS-प्रोक्सी व्यवस्था पनि अभिलेख गर्छ, जहाँ सर्भरले क्लाइन्टका लागि माथिल्लो क्वेरी फर्वार्ड गर्छ। त्यो मोडेलमा माथिल्लो स्रोत सर्भरकै नेटवर्क सन्दर्भको हो, र क्लाइन्ट-पक्षको अपवाद गलत उपाय हो।

केही थप्नुअघि कुन मोडेल सक्रिय छ पहिचान गर्नुहोस्। तीन ओभरल्यापिङ मर्मत, एउटा प्रोक्सी, क्लाइन्टमा resolver प्रतिस्थापन र म्यानुअल NAT स्क्रिप्टले सामान्यतया कसैले स्थापित गरेन भन्ने बुझाउँछ: क्वेरी कुन घटकले पठाउनुपर्छ। bootstrap पनि जाँच्नुहोस्: टनेल अस्तित्वमा आउनुअघि एन्डपोइन्ट खोज्ने एकमात्र तरिका निजी मात्र resolver हुन सक्दैन, र स्थायी resolver परिवर्तन जडानभन्दा लामो बाँच्नु हुँदैन।

सार्वजनिक वेब पृष्ठ होइन, निजी खोजी परीक्षण गर्नुहोस्

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

Resolver ठेगाना, /32 मार्ग र क्लाइन्ट DNS सेटिङ सँगै सर्भर नोटमा लेख्नुहोस्। त्यो कन्फिगरेसनको आधा मात्र पुनर्स्थापित गर्दा मूल असफलता दोहोरिन्छ।

अन्तमा, DNS सफल भएपछि टनेलले अझै अनुप्रयोगको गन्तव्यमा मार्ग दिन्छ भनी पुष्टि गर्नुहोस्। मार्ग, सेवा पहुँच र प्रमाणीकरण नाम समाधानबाट स्वतन्त्र रहन्छन्, र काम गर्ने खोजीले थ्रुपुटबारे केही भन्दैन। निजी पृष्ठ ढिलो भए पनि समाधान हुन्छ भने, resolver ले आफ्नो काम गर्यो र समस्या मार्गमा सर्यो।