AWS Client VPN इन्डपोइन्ट DNS: समाधान गरिएको IP पिन गर्दा किन असफल हुन्छ
AWS Client VPN इन्डपोइन्टको नाम तपाईंले समाधान गरेको ठेगानाले बदल्नुहोस्, पछि टनेल काम गर्न छाड्छ। निर्यात गरिएको नाम र त्यसको अनियमित प्रिफिक्स राख्नुहोस्।
गत हप्ता dig +short ले तपाईंको AWS Client VPN प्रोफाइलको इन्डपोइन्ट नामका लागि एउटा ठेगाना दियो, र टनेल जोडियो। यो हप्ता त्यही प्रोफाइल तपाईंको ल्यापटपमा 'Connecting' मा अडिएको छ, जबकि सहकर्मीको नछोएको प्रतिलिपि अझै काम गर्छ। केही पनि अवरुद्ध भएन र प्रमाणपत्र समाप्त भएन। कसैले इन्डपोइन्ट होस्टनाम त्यही समाधान गरिएको ठेगानाले बदल्यो, र सेवाले अब त्यहाँ जवाफ दिँदैन। निर्यात गरिएको नाम त्यो परिवर्तन सहन बनाइएको भाग हो।
तपाईंको प्रोफाइलको नाम सोधिने नाम नहुन सक्छ
Client VPN बाट निर्यात गरिएका प्रोफाइलमा सामान्यतया remote-random-hostname हुन्छ। त्यो विकल्प सक्रिय हुँदा क्लाइन्टले एउटा एकपटकको लेबल बनाउँछ, बिन्दुले इन्डपोइन्ट नामसँग जोड्छ, र संयुक्त नाम समाधान गर्छ। इन्डपोइन्टको जोनमा रहेको वाइल्डकार्ड रेकर्डले कुनै पनि लेबललाई जवाफ दिन्छ, त्यसैले बनावटी प्रिफिक्स पनि समाधान हुन्छ र त्यसैले क्वेरी हातले दोहोर्याउन खोज्दा यो चाल अदृश्य रहन्छ।
त्यसैले जब तपाईं इन्डपोइन्ट नाम टर्मिनलमा टाँस्नुहुन्छ र जवाफ पाउनुहुन्छ, तपाईंले क्लाइन्ट जडानको समयमा प्रयोग गर्ने नामभन्दा फरक नाम समाधान गर्नुभएको छ। त्यो भिन्नता प्रोफाइलमा सुधार्नुपर्ने खोट होइन। लेबल जानाजान पुनः बनाइन्छ: विकल्पले क्यासलाई पुरानो जवाफ राख्न दिँदैन, र यसले कहिल्यै तपाईंको मेसिन वा सत्र पहिचान गर्दैन।
मैले क्लाइन्टले विकल्प पूर्ण रूपमा बेवास्ता गर्ने अनुकूलता अवस्था भोगेको छु। AWS समाधानको दस्तावेज गर्छ: वास्तविक इन्डपोइन्ट नाम राख्नुहोस् र अगाडि एउटा अनियमित स्ट्रिङ र बिन्दु थप्नुहोस्, यसलाई टाँस्ने मान होइन नामकरण ढाँचा मान्नुहोस्। यो पुरानो क्लाइन्टमा लागू गर्नु उचित छ; प्रिफिक्स भएको स्ट्रिङलाई इन्डपोइन्टका रूपमा हार्डकोड गर्नु होइन।
सुरक्षित जवाफ किन सही रहन सक्दैन
Client VPN इन्डपोइन्ट ठेगानाहरू AWS ले व्यवस्थापन गर्छ र समयसँगै परिवर्तन हुन्छन्, जुन उत्तम अभ्यासको दस्तावेजले स्पष्ट भन्छ। कैद गरिएको जवाफ एउटा समाधानको स्न्यापसट मात्र हो। यसलाई हार्डकोड गर्ने प्रोफाइल सेवा सर्नेबित्तिकै अवकाशप्राप्त होस्टतर्फ लक्षित प्रोफाइल बन्छ, र असफलता विरलै DNS जस्तो देखिन्छ: तपाईंले जडान टाइमआउट वा अडिएको ह्यान्डशेक पाउनुहुन्छ, त्यसैले मानिसहरू राउटिङ र प्रमाणपत्रको पछि दौडन्छन्।
/etc/hosts मा त्यही जवाफले त्यही म्याद थप समस्यासहित पाउँछ। hosts प्रविष्टि रिबुट, पुनः निर्यात र 'क्लाइन्ट पुनः स्थापना गर्नुहोस्' सुधारबाट बाँच्छ, त्यसैले ठेगाना सर्दा हरेक पटक असफलता फर्किन्छ। मैले एउटा हप्तौंसम्म हानिरहित बसेको र त्यसपछि त्यो बोक्ने हरेक मेसिन बन्द गरेको देखेको छु, जबकि नयाँ स्थापनाहरू सामान्य रूपमा जोडिएका थिए। एउटै खातामा एउटा समूह असफल र अर्को ठीक हुने यो विभाजन नै तपाईंले पाउने सबैभन्दा सस्तो सङ्केत हो।
अनियमितताको दायरा ठीकसँग तोक्नुहोस्। यो प्रत्येक जडान प्रयासमा हुन्छ। स्थापित टनेलले आफ्नो इन्डपोइन्ट पुनः समाधान गर्दैन, सत्रको बीचमा सर्भर बदल्दैन, र व्यक्तिगत अनुप्रयोग अनुरोधहरूले प्रत्येकले नयाँ VPN होस्ट छान्दैनन्। अर्को प्रयासले मात्र पुनः समाधान गर्छ, त्यसैले दिउँसोभर चल्ने सत्रले भोलिको बिहानबारे केही भन्दैन।
टनेल उठ्दा सेवाले के जाँच्छ
Client VPN ले तपाईं जोडिएको ठेगाना इन्डपोइन्टको DNS नामका लागि समाधान गरिएको ठेगानासँग मिल्नुपर्ने माग गर्छ। त्यो एउटै सर्तले असम्बन्धित देखिने धेरै असफलता व्याख्या गर्छ: अन्यत्र देखाउने अनुकूलित DNS रेकर्ड, वास्तविक इन्डपोइन्ट ठेगानामा अग्रसर गर्ने अनुकूलित फ्रन्टएन्ड, र कच्चा ठेगानामा पुनः लेखिएको प्रोफाइल। AWS ले अनुकूलित रेकर्ड र अग्रसरणको संयोजनलाई नयाँ AWS क्लाइन्टसँग असफलता भनेर दस्तावेज गर्छ। जाँच साँघुरो छ; यो हरेक उपनाम निषेधित छ भन्ने फैसला होइन।
यो VPN प्रोटोकलबारे सामान्य नियम पनि होइन। सङ्ख्यात्मक remote सामान्य OpenVPN परिनियोजनमा पूर्ण रूपमा मान्य छ, र धेरै त्यसै गरी चल्छन्। प्रतिबन्ध व्यवस्थित संरचनाबाट आउँछ, त्यसको तलको प्रोटोकलबाट होइन।
जसले प्रमाणपत्र प्रमाणीकरण खुकुलो बनाउनु गलत प्रतिक्रिया बनाउँछ। ठेगाना फेरिएपछि प्रोफाइल असफल भए सर्भर प्रमाणीकरण बन्द गर्नुले समाधान वा ठेगाना मिल्ने सर्त सुधार्नुको सट्टा त्रुटि सार्छ, र जे पनि विश्वास गर्ने क्लाइन्ट छोड्छ। निर्यात गरिएको CA, सर्भर प्रमाणीकरण र पारस्परिक प्रमाणीकरणका सेटिङ जस्तै आएका थिए त्यस्तै राख्नुहोस्।
अनुमति सूची, इग्रेस र निजी DNS तीन फरक समस्या हुन्
ल्यापटप जोडिनुअघि गन्तव्यलाई अनुमति दिनुपर्ने फायरवाल नियम बाहिरी श्रोतासँग सम्बन्धित छ। नेटवर्क मालिकलाई इन्डपोइन्ट नाम, ट्रान्सपोर्ट र कन्फिगर गरिएको पोर्ट दिनुहोस्, त्यसपछि उनीहरूको नियन्त्रणले सेवाको DNS व्यवहार पछ्याउन सक्छ कि भनेर सोध्नुहोस्। एउटा कैद गरिएको ठेगाना राख्ने नियम नलेखिएको म्याद भएको स्न्यापसट हो। यदि नियन्त्रणले अपरिवर्तनीय गन्तव्य मात्र स्वीकार्छ भने, चुपचाप जवाफ हार्डकोड गर्नुको सट्टा रोलआउटअघि त्यो अन्तर टाल्नुहोस्।
टनेल उठेपछिका अनुरोधका लागि स्थिर स्रोत ठेगाना चाहिने साझेदारको फरक आवश्यकता हुन्छ: इग्रेस। वेबसाइटले के देख्छ भन्ने अनुप्रयोग मार्ग र स्प्लिट-टनेल नीतिमा निर्भर हुन्छ, क्लाइन्ट जोडिएको ठेगानामा होइन। स्प्लिट-टनेल ट्राफिकले AWS लाई छुँदै नछुन सक्छ।
टनेलभित्रको निजी DNS तेस्रो तह हो। क्लाइन्टलाई दिइने रिजोल्भरले जडानपछि आन्तरिक नामको जवाफ दिन्छ; टनेल नबनेसम्म यसले सार्वजनिक इन्डपोइन्ट समाधान गर्न सक्दैन। इन्डपोइन्ट समाधान असफलता र आन्तरिक अनुप्रयोग समाधान असफलता फरक चरणमा हुन्छन्, र तिनलाई मिसाउँदा तपाईं गलत लगमा पुग्नुहुन्छ।
ठेगाना परिवार पनि त्यही सूचीमा पर्छ। IPv4 जवाफले IPv6 वा दोहोरो स्ट्याक इन्डपोइन्टको अनुमत मार्गबारे केही भन्दैन, त्यसैले एउटा परिवारमा लिइएको स्न्यापसट अर्कोका लागि प्रमाण होइन।
केही पनि पिन नगरी जडान जाँच्नुहोस्
निर्यात भएकै प्रोफाइलबाट सुरु गर्नुहोस् र यसले वास्तवमा के माग्छ पढ्नुहोस्:
grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'त्यसपछि तीन कुरा तुलना गर्नुहोस्: प्रोफाइलमा भएको इन्डपोइन्ट नाम, नयाँ प्रयासका लागि क्लाइन्टले रिपोर्ट गर्ने ठेगाना, र नाम अहिले केमा समाधान हुन्छ। समाधान हुने नामले रेकर्डले जवाफ दिन्छ भन्ने मात्र प्रमाणित गर्छ; ट्रान्सपोर्ट र प्रमाणीकरण अलग छन्, र इन्डपोइन्टले ping को जवाफ दिनु पर्दैन। बीचको विषयका लागि क्लाइन्टको आफ्नै लग मात्र स्रोत हो, त्यसैले प्रयासको क्रममा कैद गर्नुहोस्, पछि होइन।
| What you see | Usual cause | Next check |
|---|---|---|
| One machine fails, others connect | Pinned address or stale hosts entry on that machine | Diff its profile and hosts file against a working copy |
| Everyone fails at once, no config change | The endpoint address rotated | Confirm the current endpoint configuration with the account owner |
| Tunnel up, internal names fail | Client DNS policy, not endpoint resolution | Inspect the resolver pushed after connection |
आज जवाफ दिने ठेगाना आजबारे प्रमाण हो; नाम नै सेवाले मान्य राख्ने कुरा हो। अवलोकन नोट गर्नुहोस्, इन्डपोइन्टको मालिकलाई पठाउनुहोस्, र प्रोफाइललाई नामतर्फ देखाउँदै राख्नुहोस्।
छोड्नुपर्ने दुई बानी: अडिएको ह्यान्डशेक पार गर्न प्रमाणपत्र जाँच बन्द गर्नु, र एउटा टाँसिन्छ कि भनेर इन्डपोइन्ट नामअगाडि लेबल थुपार्नु। लेबल वाइल्डकार्ड रेकर्डमार्फत समाधान हुन्छ वा समस्या अन्यत्र छ। राम्ररी कन्फिगर गरिएको प्रोफाइल तैपनि असफल भए लामो होस्टनाम होइन, सटीक क्वेरी र जडान घटना पठाउनुहोस्।
बन्द गर्नुअघि: प्रोफाइलमा अझै निर्यात गरिएको इन्डपोइन्ट नाम छ, कुनै hosts फाइलले ठेगाना पिन गर्दैन, क्लाइन्ट लगको remote हालको समाधानसँग मिल्छ, र फायरवाल नियमले ठेगानाको सट्टा इन्डपोइन्टको नाम भन्छ। अर्को व्यक्तिलाई सुम्पने अवस्था पनि यही हो।