AWS Client VPN DNS: subnet नाही, VPC resolver वापरा

endpoint 10.0.8.0/24 मध्ये आहे, म्हणून resolver 10.0.8.2 असावा. हा सर्वाधिक ऐकलेला युक्तिवाद आहे आणि तो दोन वेळा चुकीचा आहे. Route 53 Resolver प्राथमिक VPC IPv4 श्रेणी अधिक दोनवर उत्तर देतो, जो 10.0.0.0/16 च्या VPC साठी 10.0.0.2 आहे, endpoint कोणतेही subnet वापरो. दुसरी चूक अधिक शांत आहे: endpoint मध्ये योग्य पत्ता ठेवणे म्हणजे client ची ऑपरेटिंग सिस्टम कधीही त्याला काही विचारेल असे नाही. दोन्ही चुका एकच लक्षण देतात: नाव निराकरण काही client वर चालते आणि इतरांवर अयशस्वी होते.

समजूत subnet संबंधापासून सुरू होते

संबंध म्हणजे client जोडण्यांसाठी elastic network interfaces कुठे राहतात हे, कोणता resolver पत्ता अस्तित्वात आहे हे नाही. endpoint चे subnet clientांना VPC मध्ये पत्ता देतात, आणि त्यांपैकी प्रत्येकाचा स्वतःचा resolver नसतो.

ह्या दोन कल्पना वेगळ्या केल्या की गणित रहस्यमय राहत नाही आणि समस्या निवारण client कडे जाते, जिथे यातील बहुतेक प्रकरणे खरोखर संपतात.

प्राथमिक VPC श्रेणीतून पत्ता मोजा

VPC चा प्राथमिक IPv4 CIDR घ्या आणि network पत्त्यात दोन मिळवा. 10.0.0.0/16 10.0.0.2 देतो, 172.31.0.0/16 172.31.0.2 देतो, आणि दुय्यम श्रेणी असलेला VPC resolver प्राथमिकेवर ठेवतो. त्या VPC मधील 10.0.8.0/24 subnet त्याला हलवत नाही. endpoint ला हात लावण्यापूर्वी पत्ता VPC ID च्या शेजारी लिहा, कारण ही संख्या VPC ची गुणधर्म आहे, जोडणीची नाही.

VPC link-local पत्ता 169.254.169.253 वरही उत्तर देतो. हा पत्ता VPC मधून पोहोचण्यायोग्य आहे, पण बोगद्याच्या दुसऱ्या टोकावरील लॅपटॉपसाठी हे सर्वसाधारण मार्गस्थ गंतव्य नाही.

म्हणून दोन वैध resolver पत्ते आहेत, आणि त्यांपैकी कोणतेही subnet अधिक दोन नाही.

endpoint सेटिंग काय करते आणि काय नाही

Client VPN endpoint मध्ये DNS सर्व्हर फील्ड आहेत, आणि जिथे कन्सोल VPC resolver पर्याय देते तिथे तीच कल्पना भरते. ते सेट केल्याने जोडणी स्थापन होताना सेवा clientांना काय देते ते बदलते. व्यवस्थापित नसलेला OpenVPN client त्या मूल्याशी काय करतो ते बदलत नाही, कारण client ला ते ऑपरेटिंग सिस्टमवर लागू करावे लागते. «माझ्या Mac वर चालते पण Linux बॉक्सवर नाही» हे याच अंतरातून येते.

Linux मध्ये resolver एकत्रीकरण कनेक्शन मॅनेजरकडे आहे, वापरकर्त्याकडे नाही. /etc/resolv.conf हाताने संपादित केल्याने पत्ता एका सत्रासाठी चालतो हे सिद्ध होते आणि नंतर पुन्हा जोडल्यावर नाहीसा होतो — म्हणूनच अनेक दुरुस्त केलेली प्रकरणे दुसऱ्या सकाळी परत येतात.

जोडल्यानंतर client वर सक्रिय resolver तपासा, endpoint चे कॉन्फिगरेशन पान नाही.

split tunneling योग्य resolver हरवू शकते

split tunneling मध्ये बोगद्यात ढकललेले मार्गच वापरले जातात. resolver पत्ता कोणत्याही मार्गाने झाकलेला नसल्यास, क्वेरी स्थानिक इंटरफेसने बाहेर जाते आणि तुमचा घरचा राउटर उत्तर देतो. endpoint मधील पत्ता अजूनही बरोबर आहे आणि शोध अजूनही अयशस्वी होतो. resolver साठी मार्ग जोडा, नंतर पुन्हा चाचणी करा.

एकमेकांवर आच्छादणाऱ्या स्थानिक श्रेणी तोच निकाल अधिक त्रासदायक पद्धतीने देतात: क्वेरीला उत्तर मिळते, फक्त चुकीच्या सर्व्हरकडून.

Amazon DNS पत्त्यासाठी security groups उघडू नका

शोध कालबाह्य झाल्यावर सहज प्रवृत्ती resolver पत्त्यावर UDP 53 परवानगी देणारा नियम जोडण्याची असते. security groups आणि नेटवर्क ACL Amazon DNS रहदारी स्वतःच्या DNS इंस्टन्सकडील रहदारीसारखी गाळत नाहीत असे AWS नोंदवते. ते नियम उघडल्याने VPC resolver साठी काहीही बदलत नाही आणि सीमा विनाकारण रुंदावते. तुम्ही स्वतः चालवता तो resolver वेगळे प्रकरण आहे आणि त्याला खरोखर स्वतःचे नियम हवेत.

तुमच्या रचनेत दोन्ही असल्यास, कोणताही नियम संपादित करण्यापूर्वी client प्रत्यक्षात कडेकडे आहे ते तपासा.

मार्ग पडताळा, नंतर दुसरे काही मोजा

सार्वजनिक नाव सोडवा, VPC शी संबंधित खाजगी होस्टेड झोनमध्ये नोंदणीकृत खाजगी नाव सोडवा, आणि दोन्हींमध्ये client चा सक्रिय resolver वाचा. हा क्रम «resolver पत्ता चुकीचा» हे «झोन जोडलेला नाही» आणि «client ने सेटिंग दुर्लक्षित केली» यापासून वेगळे करतो. प्रत्येकाचा वेगळा उपाय आहे, आणि कोणतेही throughput समस्या नाही.

यशस्वी शोध सतत हस्तांतरण गतीबद्दल काहीही सांगत नाही, म्हणून अहवाल देताना या दोन गोष्टी वेगळ्या ठेवा.