AWS Client VPN DNS: सबनेट नहीं, VPC रिज़ॉल्वर का उपयोग करें

endpoint 10.0.8.0/24 में है, इसलिए रिज़ॉल्वर 10.0.8.2 होना चाहिए। यही तर्क मैं सबसे ज़्यादा सुनता हूँ, और यह दो बार गलत है। Route 53 Resolver प्राथमिक VPC IPv4 रेंज प्लस दो पर उत्तर देता है, जो 10.0.0.0/16 के VPC के लिए 10.0.0.2 है, चाहे endpoint कोई भी सबनेट इस्तेमाल करे। दूसरी गलती ज़्यादा ख़ामोश है: endpoint में सही पता डालने का मतलब यह नहीं कि क्लाइंट का ऑपरेटिंग सिस्टम उससे कभी कुछ पूछे। दोनों गलतियाँ एक ही लक्षण देती हैं: नाम रिज़ॉल्यूशन कुछ क्लाइंट पर काम करता है और दूसरों पर विफल होता है।

मिथक सबनेट एसोसिएशन से शुरू होता है

एसोसिएशन इस बात से है कि क्लाइंट कनेक्शन के लिए इलास्टिक नेटवर्क इंटरफ़ेस कहाँ रहते हैं, इससे नहीं कि कौन-सा रिज़ॉल्वर पता मौजूद है। endpoint के सबनेट क्लाइंट को VPC के अंदर पता देते हैं, और उनमें से हर एक अपना रिज़ॉल्वर नहीं रखता।

जैसे ही आप इन दो विचारों को अलग करते हैं, गणित रहस्यमय रहना बंद कर देता है और समस्या-निवारण क्लाइंट की ओर चला जाता है, जहाँ वास्तव में इनमें से अधिकतर मामले ख़त्म होते हैं।

प्राथमिक VPC रेंज से पता निकालें

VPC का प्राथमिक IPv4 CIDR लें और नेटवर्क पते में दो जोड़ें। 10.0.0.0/16 10.0.0.2 देता है, 172.31.0.0/16 172.31.0.2 देता है, और द्वितीयक रेंज वाला VPC रिज़ॉल्वर को प्राथमिक पर ही रखता है। उस VPC के अंदर 10.0.8.0/24 का सबनेट उसे हिलाता नहीं। endpoint को छूने से पहले पता VPC ID के बगल में लिखें, क्योंकि यह संख्या VPC की विशेषता है, कनेक्शन की नहीं।

VPC link-local पते 169.254.169.253 पर भी उत्तर देता है। यह पता VPC के अंदर से पहुँचने योग्य है, लेकिन सुरंग के दूसरे छोर पर रखे लैपटॉप के लिए यह सामान्य रूप से रूट होने वाला गंतव्य नहीं है।

इसलिए दो वैध रिज़ॉल्वर पते हैं, और उनमें से कोई भी सबनेट प्लस दो नहीं है।

endpoint सेटिंग क्या करती है और क्या नहीं

Client VPN endpoint में DNS सर्वर फ़ील्ड होते हैं, और जहाँ कंसोल VPC रिज़ॉल्वर विकल्प देता है वहाँ वही विचार भर देता है। इन्हें सेट करने से बदलता है कि कनेक्शन स्थापित होते समय सेवा क्लाइंट को क्या सौंपती है। इससे यह नहीं बदलता कि अनमैनेज्ड OpenVPN क्लाइंट उस मान के साथ क्या करता है, क्योंकि क्लाइंट को उसे ऑपरेटिंग सिस्टम पर लागू करना ही होता है। इसी खाई से «मेरे Mac पर काम करता है पर Linux बॉक्स पर नहीं» आता है।

Linux में रिज़ॉल्वर एकीकरण कनेक्शन मैनेजर का है, उपयोगकर्ता का नहीं। /etc/resolv.conf को हाथ से संपादित करना साबित करता है कि पता एक सत्र के लिए काम करता है और फिर पुनः कनेक्ट पर गायब हो जाता है — इसीलिए इतने सारे ठीक किए गए मामले अगली सुबह लौट आते हैं।

कनेक्ट करने के बाद क्लाइंट पर सक्रिय रिज़ॉल्वर जाँचें, endpoint का कॉन्फ़िगरेशन पेज नहीं।

split tunneling सही रिज़ॉल्वर को हरा सकता है

split tunneling में केवल वे रूट इस्तेमाल होते हैं जो सुरंग में भेजे जाते हैं। अगर रिज़ॉल्वर पता किसी रूट से ढका नहीं है, तो क्वेरी स्थानीय इंटरफ़ेस से बाहर जाती है और आपका होम राउटर उत्तर देता है। endpoint का पता अब भी सही है और लुकअप अब भी विफल है। रिज़ॉल्वर के लिए रूट जोड़ें, फिर दोबारा परीक्षण करें।

अतिव्यापी स्थानीय रेंज वही परिणाम और भी बुरे तरीके से देती हैं: क्वेरी का उत्तर मिलता है, बस गलत सर्वर से।

Amazon DNS पते के लिए security groups न खोलें

लुकअप के समय-समाप्त होने पर सहज प्रवृत्ति यह होती है कि रिज़ॉल्वर पते के लिए UDP 53 की अनुमति देने वाला नियम जोड़ दिया जाए। AWS दस्तावेज़ करता है कि security groups और नेटवर्क ACL Amazon DNS ट्रैफ़िक को उस तरह नहीं छानते जैसे वे कस्टम DNS इंस्टेंस तक के ट्रैफ़िक को छानते हैं। इन नियमों को खोलने से VPC रिज़ॉल्वर के लिए कुछ नहीं बदलता और सीमा बेवजह बढ़ती है। जो रिज़ॉल्वर आप स्वयं चलाते हैं वह अलग मामला है और उसे सचमुच अपने नियम चाहिए।

अगर आपके डिज़ाइन में दोनों हैं, तो कोई भी नियम संपादित करने से पहले देखें कि क्लाइंट वास्तव में किसकी ओर इशारा कर रहा है।

रास्ता सत्यापित करें, फिर कुछ और मापें

एक सार्वजनिक नाम हल करें, VPC से जुड़े निजी होस्टेड ज़ोन में पंजीकृत निजी नाम हल करें, और दोनों के बीच क्लाइंट का सक्रिय रिज़ॉल्वर पढ़ें। यह क्रम «रिज़ॉल्वर पता गलत है» को «ज़ोन जुड़ा नहीं है» और «क्लाइंट ने सेटिंग अनदेखी की» से अलग करता है। हर एक का अलग समाधान है, और कोई भी थ्रूपुट समस्या नहीं है।

सफल लुकअप स्थायी स्थानांतरण गति के बारे में कुछ नहीं कहता, इसलिए रिपोर्ट करते समय इन दोनों बातचीत को अलग रखें।