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

मैं यह साबित करके शुरू करता हूँ कि रिकॉर्ड मौजूद है, फिर बाकी समय क्वेरी पथ पर लगाता हूँ। ये अलग प्रणालियाँ हैं और अलग तरह से विफल होती हैं।

कुछ भी बदलने से पहले विफलता का आकार पढ़ें

तीन परिणाम तीन अलग बातें मानते हैं, और एक क्वेरी उन्हें अलग करती है: उस रिज़ॉल्वर के विरुद्ध नाम के लिए dig चलाएँ जो क्लाइंट वास्तव में उपयोग कर रहा है।

What you seeWhat it usually meansFirst thing to check
SERVFAIL, or a timeout after several secondsNo path to the resolver, or the resolver cannot reach AWSRoute to the endpoint and the security policy on port 53
NXDOMAIN from a resolver that did answerThe resolver replied, but the zone is not in its viewZone association or the forwarding rule for that namespace
A public address for an internal nameSplit DNS is not in effect for this clientWhich resolver the client is configured to use

समय-समाप्ति नेटवर्क के बारे में एक कथन है। NXDOMAIN DNS दृश्य के बारे में एक कथन है। सार्वजनिक उत्तर नीति के बारे में एक कथन है। समय-समाप्ति के दौरान ज़ोन रिकॉर्ड संपादित करना मामले का एकमात्र उपयोगी साक्ष्य फेंक देता है।

VPC का प्लस-दो पता दूरस्थ रिज़ॉल्वर क्यों नहीं है

CIDR प्लस-दो पता VPC के भीतर संसाधनों के लिए स्थानीय सेवा है। AWS दस्तावेज़ित करता है कि स्थानीय नेटवर्क से, या किसी दूसरे VPC के DNS सर्वर से, क्वेरी सीधे उस पते पर अग्रेषित करना समर्थित नहीं है और अस्थिर परिणाम दे सकता है।

इसका मतलब यह नहीं कि कोई प्रयोग कभी काम करता नहीं दिखता। इसका मतलब है कि व्यवहार ऐसा अनुबंध नहीं है जिसे हेल्पडेस्क स्क्रिप्ट में रखा जा सके। समर्थित दिशा एक इनबाउंड Resolver एंडपॉइंट है: आपके VPC के भीतर पतों की एक जोड़ी, जो आपके नियंत्रित नेटवर्क से पहुँच योग्य हो और AWS के बाहर से आने वाली क्वेरी स्वीकार करे।

पथ उस क्रम में बनाएँ जिसमें वह साफ़ तौर पर विफल होता है

तीन हॉप मौजूद होने चाहिए, और हर एक की विफलता का अपना तरीका है।

VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addresses

फ़ॉरवर्डर को VPN के ज़रिये एंडपॉइंट पतों तक मार्ग चाहिए, और वापसी पथ भी काम करना चाहिए। पोर्ट 53 पर पारंपरिक DNS के लिए एंडपॉइंट UDP और TCP पर उत्तर देता है, इसलिए दोनों प्रोटोकॉल की अनुमति होनी चाहिए और दोनों को बीच में किसी भी स्टेटफुल जाँच से बचना होगा।

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

आउटबाउंड एंडपॉइंट विपरीत दिशा की सेवा करता है और आपके लैपटॉप से आने वाली क्वेरी का उत्तर नहीं देगा।

दोनों सिरों से सत्यापित करें

क्लाइंट से फ़ॉरवर्डर के विरुद्ध क्वेरी करें, फिर फ़ॉरवर्डर से एंडपॉइंट के विरुद्ध। अगर क्लाइंट विफल हो और फ़ॉरवर्डर सफल हो, तो अंतर उन दोनों के बीच है।

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

सार्वजनिक और निजी नामस्थानों को जानबूझकर अलग रखें। Split DNS एक नीति है जिसे आप कॉन्फ़िगर करते हैं, यह किसी एक लुकअप के संयोग से डेटा लौटाने का दुष्प्रभाव नहीं है।

जो मैं नहीं करूँगा

मैं ऐसा NAT नियम नहीं जोड़ूँगा जिसने एक लुकअप चलाया और उसे डिज़ाइन कहूँ।

मैं हर दूरस्थ क्लाइंट को प्लस-दो पते पर नहीं भेजूँगा क्योंकि एक परीक्षण ने एक बार रिकॉर्ड लौटाया। और मैं एंडपॉइंट की सुरक्षा नीति को पूरे VPN पूल तक नहीं बढ़ाऊँगा जब एक ही फ़ॉरवर्डर को पहुँच चाहिए। अगर संगठन पहले से VPC के भीतर मंज़ूर फ़ॉरवर्डर चला रहा है, तो पहले वह डिज़ाइन पढ़ें, क्योंकि आपका जोड़ा गया दूसरा एंडपॉइंट वही है जिसे कोई दस्तावेज़ित नहीं करता।

संबंधित लेख