dnsmasq मा तपाईंको VPN डोमेन जोन ट्रान्सफर होइन

तपाईं क्लाइन्टको dnsmasq कन्फिगरेसनमा कर्पोरेट जोन खोज्नुहुन्छ, भेट्नुहुन्न, र VPN ले आफ्नो डोमेन पुश गरेन भन्ने निष्कर्षमा पुग्नुहुन्छ। पुश गरिएको कुरा राउटिङ सङ्केत हो, जोन होइन। क्लाइन्टले डोमेन र त्यसको लागि जवाफ दिनुपर्ने resolver रेकर्ड गर्छ, र व्यवस्थापित ब्याकएन्डले त्यसलाई सशर्त फर्वार्डिङमा बदल्छ। गलत ठाउँमा हेर्दा आत्मविश्वासी र पूर्ण रूपमा गलत निदान निस्कन्छ।

क्लाइन्टले स्वीकार गरेको कुरा गेटवेले प्रस्ताव गरेको कुरा होइन

गेटवेले resolver, डोमेन र त्यो resolver सम्म पुग्न आवश्यक मार्ग प्रस्ताव गर्न सक्छ, र क्लाइन्टले तीनै वा कुनै पनि स्वीकार गर्न सक्छ। आयातित प्रोफाइल, सहायक स्क्रिप्ट वा पुश गरिएका विकल्पहरूलाई बेवास्ता गर्ने नीतिले स्वीकृत सेट खाली छोड्न सक्छ जबकि सर्भर पक्ष सही देखिन्छ। सर्भरको कन्फिगरेसनको सट्टा क्लाइन्टको रेकर्ड गरिएको अवस्थाबाट सुरु गर्नुहोस्, किनकि resolver ले वास्तवमा त्यही अवस्था पाउँछ। यदि स्वीकृत डोमेन छैन भने अरू केही महत्त्वपूर्ण हुनेछैन। कुनै पनि क्यास जाँच्नुअघि जडानको DNS गुणहरू जाँच्नुहोस्।

त्यो भिन्नताले कहिल्यै नआएको डोमेनका अधिकांश रिपोर्टहरू व्याख्या गर्छ। त्यो प्रस्ताव गरियो, र लागू गरिएन।

डोमेन प्रविष्टिका दुई प्रकार

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

निजी नामस्थानका लागि सामान्यतया केवल-मार्ग रूप नै चाहिन्छ। यसले कर्पोरेट सफिक्सलाई कर्पोरेट resolver तिर राख्छ र बाँकी सबैलाई एक्लै छोड्छ।

resolv.conf मा localhost कुनै बग होइन

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

त्यो प्रविष्टिलाई सार्वजनिक resolver ले प्रतिस्थापन गर्नु क्लासिक गलत सुधार हो। यसले सार्वजनिक नाम समाधान पुनर्स्थापित गर्छ र त्यही सम्पादनमा सशर्त नीति त्याग्छ।

ब्याकएन्डहरू नमिसाउनुहोस्

व्यवस्थापित dnsmasq इन्स्टेन्स र सिस्टम resolver फरक कन्फिगरेसन र फरक स्थिति दृश्यहरू भएका फरक प्रोग्रामहरू हुन्। एउटाको लागि स्थिति आदेशले अर्कोबारे केही उपयोगी बताउँदैन।

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

नामस्थान परीक्षण गर्नुहोस्, उत्तर मात्र होइन

अनुप्रयोगको सामान्य मार्गबाट एउटा अनुमत निजी नाम र एउटा सार्वजनिक नियन्त्रण नाम सोध्नुहोस्। कर्पोरेट सर्भरमा सिधा क्वेरीले रेकर्ड अवस्थित छ भनी प्रमाणित गर्छ; क्लाइन्टले त्यो सर्भर छान्यो भनी प्रमाणित गर्दैन। दोस्रो क्वेरी नै नीति परीक्षण गर्ने क्वेरी हो।

त्यसपछि पुनः जडान र विच्छेदनपछि दोहोर्याउनुहोस्। एसोसिएसनले जडानको जीवनचक्र पछ्याउनुपर्छ, र निजी नामहरूले सुरुङ नभएपछि समाधान हुन छोड्नुपर्छ, त्यसै सफिक्सका लागि जवाफ दिने सार्वजनिक resolver मा फर्कनुको सट्टा। यदि तिनीहरू फर्के भने तपाईंले चुहावट भेट्नुभयो, जो बिग्रिएको खोजभन्दा फरक दोष हो। कुन ब्याकएन्ड चल्यो, कुन डोमेन लागू भए र प्रत्येक क्वेरीले के फर्कायो लेख्नुहोस्।