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 मौजूदा हल से मेल खाता है, और फ़ायरवॉल नियम पते के बजाय एंडपॉइंट का नाम बताता है। यही अगले व्यक्ति को सौंपने वाली स्थिति है।