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

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

काहीही बदलण्यापूर्वी अयशस्वीतेचा आकार वाचा

तीन निष्कर्ष तीन वेगळ्या गोष्टी दर्शवतात, आणि एक क्वेरी त्यांना वेगळी करते: क्लायंट प्रत्यक्षात वापरत असलेल्या resolver विरुद्ध नावासाठी 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 चा प्लस-दोन पत्ता दूरस्थ resolver का नाही

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 पत्ता सादर करतो, आणि फक्त हाच फरक क्वेरी टाकून देण्यासाठी पुरतो। दोन्ही यशस्वी झाले पण एप्लिकेशन तरीही अयशस्वी होत असेल, तर कदाचित एप्लिकेशन तुम्ही तपासलेल्यापेक्षा वेगळा resolver वापरत असेल।

सार्वजनिक आणि खासगी नामविश्व जाणीवपूर्वक वेगळे ठेवा। Split DNS हे तुम्ही कॉन्फिगर करता ते धोरण आहे, एका शोधाच्या योगायोगाने डेटा परत करण्याचा दुष्परिणाम नाही।

जे मी करणार नाही

एका शोधाला चालवणारा NAT नियम जोडून त्याला रचना म्हणणार नाही।

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

संबंधित लेख