dnsmasq मधील तुमचे VPN डोमेन झोन ट्रान्सफर नाही

तुम्ही क्लायंटच्या dnsmasq कॉन्फिगरेशनमध्ये कॉर्पोरेट झोन शोधता, तो सापडत नाही, आणि VPN ने आपला डोमेन पुश केला नाही असा निष्कर्ष काढता। जे पुश झाले ते राउटिंग इशारा आहे, झोन नाही। क्लायंट डोमेन आणि त्याला उत्तर देणारा resolver नोंदवतो, आणि व्यवस्थापित बॅकएंड त्याचे सशर्त फॉरवर्डिंगमध्ये रूपांतर करतो। चुकीच्या ठिकाणी पाहिल्याने आत्मविश्वासू आणि पूर्णपणे चुकीचे निदान मिळते।

क्लायंटने जे स्वीकारले ते गेटवेने जे सादर केले ते नाही

गेटवे resolver, डोमेन आणि त्या resolverपर्यंत पोहोचण्यासाठी आवश्यक मार्ग सादर करू शकतो, आणि क्लायंट तिन्ही किंवा एकही स्वीकारू शकतो। आयात केलेली प्रोफाइल, सहाय्यक स्क्रिप्ट किंवा पुश केलेल्या पर्यायांकडे दुर्लक्ष करणारे धोरण स्वीकारलेला संच रिकामा ठेवू शकते तर सर्व्हर बाजू बरोबर दिसते। सर्व्हरच्या कॉन्फिगरेशनऐवजी क्लायंटच्या नोंदवलेल्या स्थितीपासून सुरुवात करा, कारण resolver ला प्रत्यक्षात तीच स्थिती मिळते। स्वीकारलेला डोमेन नसल्यास पुढे काहीही महत्त्वाचे राहणार नाही। कोणताही कॅशे तपासण्यापूर्वी कनेक्शनचे DNS गुणधर्म तपासा।

हा फरक कधीही न पोहोचलेल्या डोमेनबद्दलच्या बहुतेक अहवालांचे स्पष्टीकरण देतो। तो सादर केला गेला, आणि तो लागू केला गेला नाही।

डोमेन नोंदीचे दोन प्रकार

कनेक्शन सामान्य शोध डोमेन आणि केवळ-मार्ग डोमेन वाहू शकते, आणि दुसरा प्रकार टिल्डने सुरू होतो। शोध डोमेन क्वेरी मार्गस्थ करतो आणि लहान नावांचा विस्तार होऊ देतो, जे वर्कस्टेशनवर सोयीचे आणि सर्व्हरवर आश्चर्यकारक आहे। केवळ-मार्ग डोमेन सांगतो की त्या सफिक्सच्या क्वेरी लहान नावे कशी सोडवली जातात हे न बदलता विशिष्ट सर्व्हरकडे जाव्यात। एकच डोमेन दोन्ही प्रकारे लिहिणे अनावश्यक नाही, कारण दोन्ही नोंदी वेगवेगळे काम करतात।

खाजगी नामस्थानासाठी सहसा केवळ-मार्ग स्वरूप हवे असते। ते कॉर्पोरेट सफिक्स कॉर्पोरेट resolverकडे ठेवते आणि बाकी सर्वांना एकटे सोडते।

resolv.conf मधील localhost हा बग नाही

स्थानिक कॅशिंग resolver वापरात असताना, सिस्टम फाइल लूपबॅक पत्ता आणि दुसरे काहीही दर्शवत नाही। ती नोंद स्थानिक श्रोत्याची ओळख करते, व्यवस्थापकाने दिलेल्या अपस्ट्रीम सर्व्हरची नाही। कॉर्पोरेट पत्ता फाइलमध्ये वैधपणे अनुपस्थित राहील।

ती नोंद सार्वजनिक resolver ने बदलणे ही क्लासिक चुकीची दुरुस्ती आहे। ते सार्वजनिक नाव सोडवणे पुनर्संचयित करते आणि त्याच संपादनात सशर्त धोरण टाकून देते।

बॅकएंड एकत्र करू नका

व्यवस्थापित dnsmasq इन्स्टन्स आणि सिस्टम resolver वेगवेगळ्या कॉन्फिगरेशन आणि वेगवेगळ्या स्थिती दृश्यांसह वेगवेगळे प्रोग्राम आहेत। एकासाठी स्थिती आदेश दुसऱ्याबद्दल काहीही उपयुक्त सांगत नाही।

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

नामस्थानाची चाचणी करा, केवळ उत्तराची नाही

अनुप्रयोगाच्या नेहमीच्या मार्गाने एक परवानगी असलेले खाजगी नाव आणि एक सार्वजनिक नियंत्रण नाव विचारा। कॉर्पोरेट सर्व्हरवर थेट क्वेरी रेकॉर्ड अस्तित्वात असल्याचे सिद्ध करते; ती क्लायंटने तो सर्व्हर निवडल्याचे सिद्ध करत नाही। दुसरी क्वेरी धोरणाची चाचणी करणारी आहे।

नंतर पुन्हा कनेक्ट झाल्यावर आणि डिस्कनेक्ट झाल्यावर पुन्हा करा। असोसिएशनने कनेक्शनच्या जीवनचक्राचे अनुसरण केले पाहिजे, आणि खाजगी नावांनी बोगदा नसताना सोडवणे थांबवले पाहिजे, त्याऐवजी त्याच सफिक्ससाठी उत्तर देणाऱ्या सार्वजनिक resolverवर पडू नये। जर ते पडले, तर तुम्हाला गळती सापडली आहे, जी तुटलेल्या शोधापेक्षा वेगळी दोष आहे। कोणता बॅकएंड चालला, कोणते डोमेन लागू झाले आणि प्रत्येक क्वेरीने काय परत केले ते लिहा।