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 सर्भर फिल्डहरू छन्, र जहाँ console ले 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 र network ACL ले Amazon DNS ट्राफिकलाई आफ्नै DNS इन्स्ट्यान्सतर्फको ट्राफिकजस्तै फिल्टर गर्दैनन् भनी AWS अभिलेख गर्छ। ती नियम खोल्दा VPC resolver का लागि केही बदलिँदैन र सीमा बिनाकारण फराकिलो हुन्छ। आफै चलाएको resolver फरक अवस्था हो र त्यसलाई साँच्चै आफ्नै नियम चाहिन्छ।

तपाईंको डिजाइनमा दुवै छन् भने, कुनै पनि नियम सम्पादन गर्नु अघि client वास्तवमा कुनतिर संकेत गरिरहेको छ जाँच्नुहोस्।

मार्ग प्रमाणित गर्नुहोस्, त्यसपछि अरू केही नाप्नुहोस्

सार्वजनिक नाम समाधान गर्नुहोस्, VPC सँग सम्बन्धित निजी होस्टेड जोनमा दर्ता भएको निजी नाम समाधान गर्नुहोस्, र दुईबीच client को सक्रिय resolver पढ्नुहोस्। यो क्रमले «resolver ठेगाना गलत छ» लाई «जोन सम्बन्धित छैन» र «client ले सेटिङ बेवास्ता गर्यो» बाट छुट्याउँछ। हरेकको फरक उपाय छ, र कुनै पनि throughput समस्या होइन।

सफल खोजले निरन्तर स्थानान्तरण गतिको बारेमा केही भन्दैन, त्यसैले रिपोर्ट गर्दा यी दुई कुरा अलग राख्नुहोस्।