dnsmasq में आपका VPN डोमेन ज़ोन ट्रांसफ़र नहीं है

आप क्लाइंट के dnsmasq कॉन्फ़िगरेशन में कॉर्पोरेट ज़ोन खोजते हैं, नहीं मिलता, और निष्कर्ष निकालते हैं कि VPN ने अपना डोमेन पुश नहीं किया। जो पुश हुआ वह रूटिंग संकेत है, ज़ोन नहीं। क्लाइंट डोमेन और उस resolver को दर्ज करता है जिसे उसके लिए जवाब देना चाहिए, और प्रबंधित बैकएंड उसे सशर्त फ़ॉरवर्डिंग में बदल देता है। ग़लत जगह देखने से आत्मविश्वासी और पूरी तरह ग़लत निदान मिलता है।

क्लाइंट ने जो स्वीकार किया वह वह नहीं है जो गेटवे ने पेश किया

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

यही अंतर कभी न पहुँचने वाले डोमेन की अधिकांश रिपोर्टों की व्याख्या करता है। उसे पेश किया गया, और उसे लागू नहीं किया गया।

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

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

निजी नामस्थान के लिए आम तौर पर केवल-रूट रूप ही चाहिए। यह कॉर्पोरेट सफ़िक्स को कॉर्पोरेट resolver की ओर रखता है और बाकी सबको अकेला छोड़ देता है।

resolv.conf में localhost कोई बग नहीं है

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

उस प्रविष्टि को सार्वजनिक resolver से बदलना क्लासिक ग़लत सुधार है। यह सार्वजनिक नाम हल करना बहाल करता है और उसी संपादन में सशर्त नीति को त्याग देता है।

बैकएंडों को न मिलाएँ

प्रबंधित dnsmasq इंस्टेंस और सिस्टम resolver अलग कॉन्फ़िगरेशन और अलग स्थिति दृश्यों वाले अलग प्रोग्राम हैं। एक के लिए स्थिति कमांड दूसरे के बारे में कुछ उपयोगी नहीं बताता।

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

नामस्थान का परीक्षण करें, केवल उत्तर का नहीं

एप्लिकेशन के सामान्य पथ से एक अनुमत निजी नाम और एक सार्वजनिक नियंत्रण नाम पूछें। कॉर्पोरेट सर्वर पर सीधी क्वेरी साबित करती है कि रिकॉर्ड मौजूद है; यह साबित नहीं करती कि क्लाइंट ने वह सर्वर चुना। दूसरी क्वेरी ही नीति का परीक्षण करती है।

फिर पुनः कनेक्ट और डिस्कनेक्ट के बाद दोहराएँ। एसोसिएशन को कनेक्शन के जीवनचक्र का पालन करना चाहिए, और निजी नामों को सुरंग न होने पर हल होना बंद कर देना चाहिए, न कि उसी सफ़िक्स के लिए जवाब देने वाले सार्वजनिक resolver पर वापस गिरना चाहिए। अगर वे वापस गिरते हैं, तो आपने लीक पाया है, जो टूटी लुकअप से अलग दोष है। लिखें कि कौन-सा बैकएंड चला, कौन-से डोमेन लागू हुए, और प्रत्येक क्वेरी ने क्या लौटाया।