AWS Client VPN स्प्लिट टनल: कौन-से रूट प्रकाशित करने चाहिए

कंसोल स्प्लिट टनल के लिए एक टॉगल देता है, इसलिए निर्णय चेकबॉक्स जैसा लगता है। ऐसा नहीं है। क्लाइंट तक वास्तव में एंडपॉइंट का प्रकाशित रूट सेट पहुँचता है, और वही सूची तय करती है कि कौन-से निजी प्रीफ़िक्स टनल का उपयोग करें, सामान्य इंटरनेट ट्रैफ़िक स्थानीय रहे या AWS से बाहर जाए, और क्लाइंट किस रिज़ॉल्वर से अब भी बात कर सकता है। तीन प्रश्न डिज़ाइन तय करते हैं, और हर एक का उत्तर बुरी तरह दिया जा सकता है जबकि कनेक्शन फिर भी सफल रहता है।

स्प्लिट टनल फ़्लैग गंतव्यों की सूची नहीं है

AWS स्प्लिट टनल को कनेक्शन स्थापित होने पर क्लाइंट की रूट तालिका में एंडपॉइंट रूट जोड़ने के रूप में वर्णित करता है। निजी VPC के लिए रूट टनल को उसी गंतव्य तक सीमित करता है; बाकी सब क्लाइंट के सामान्य मार्ग से चलता है। डिफ़ॉल्ट रूट अलग प्रभाव वाला अलग निर्देश है, इसीलिए स्प्लिट टनल दस्तावेज़ इस मोड के लिए कॉन्फ़िगर किए गए एंडपॉइंट पर 0.0.0.0/0 प्रकाशित करने के विरुद्ध चेतावनी देता है: यह कनेक्टिविटी बढ़ाने के बजाय प्रायः तोड़ देता है। एंडपॉइंट रूट तालिका नीति है, और क्लाइंट रूट तालिका वह परिणाम है जिसे आप जाँच सकते हैं।

एंडपॉइंट रूट तालिका और क्लाइंट के इंस्टॉल किए गए रूट एक साथ पढ़ें। लेबल मंशा बताता है; रूट बताते हैं कि क्या होता है।

पहला निर्णय: क्या सामान्य इंटरनेट ट्रैफ़िक स्थानीय रहना चाहिए?

अगर ब्राउज़िंग को उपयोगकर्ता के अपने कनेक्शन का उपयोग करना है, तो केवल वे निजी गंतव्य प्रकाशित करें जिनकी काम को आवश्यकता है और वहीं रुकें। इंटरनेट रूट न जोड़ें क्योंकि किसी फ़ुल-टनल ट्यूटोरियल में एक था, और यह न मानें कि अतिरिक्त रूट सुरक्षा सुधारता है। यह मार्ग बदलता है, नीति नहीं जोड़ता, और आम तौर पर वह विलंब लेता है जिसका आपने बजट नहीं बनाया था।

अगर इंटरनेट ट्रैफ़िक को AWS से बाहर जाना है, तो दस्तावेज़ीकृत इंटरनेट-प्रवेश आर्किटेक्चर बनाएँ: एंडपॉइंट रूट, प्राधिकरण नियम, संबद्ध सबनेट का मार्ग, सुरक्षा नीति और एक कार्यशील अपस्ट्रीम एग्रेस। केवल डिफ़ॉल्ट रूट इनमें से कुछ भी नहीं देता।

दूसरा निर्णय: कौन-से निजी प्रीफ़िक्स, और किसके प्राधिकरण से?

वास्तविक कार्यभार की सेवा करने वाला सबसे छोटा गंतव्य सेट प्रकाशित करें, और जाँचें कि प्रत्येक संबद्ध सबनेट उन तक रूट कर सकता है। एंडपॉइंट का रूट लक्ष्य और सबनेट का VPC रूटिंग अलग परतें हैं, और एक में मौजूद रूट दूसरे के बारे में प्रमाण नहीं है। प्राधिकरण फिर अलग है: कोई गंतव्य पहुँच योग्य हो सकता है और फिर भी अस्वीकार हो सकता है क्योंकि क्लाइंट के समूह के पास ऐसा कोई नियम नहीं है जो उसे अनुमति दे।

एक सफल सत्र का परीक्षण एक मार्ग सिद्ध करता है। प्रत्येक संबद्ध सबनेट जाँचें, क्योंकि बाद में जोड़ा गया सबनेट संबंध ठीक वही जगह है जहाँ गुम रूट आम तौर पर रहता है।

जब किसी गंतव्य तक नाम से पहुँचना आवश्यक हो, तो ध्यान दें कि अगला प्रश्न नाम विश्लेषण का है, रूट का नहीं।

तीसरा निर्णय: कौन-सा रिज़ॉल्वर टनल का अनुसरण करता है?

क्लाइंट को ऐसा DNS सर्वर मिल सकता है जो केवल VPN से पहुँच योग्य हो, और वह रिज़ॉल्वर तभी काम करता है जब उसका पता स्वयं किसी प्राधिकृत रूट के भीतर हो। दोनों आधे जाँचें: रिज़ॉल्वर का पता प्रकाशित रूट का अनुसरण करता है, और सर्वर उन नामों का उत्तर देता है जो एप्लिकेशन माँगता है। पते से सफल होने वाला परंतु होस्टनाम से विफल होने वाला अनुरोध नामकरण की ओर संकेत करता है, रूटिंग की ओर नहीं, और उस स्थिति में टनल को डीबग करना दोपहर बर्बाद करता है।

सार्वजनिक नाम कनेक्शन से पहले की तरह ही हल होने चाहिए, जो इस बारे में सटीक होने का एक और कारण है कि आप क्या प्रकाशित करते हैं।

रूट सेट बदलें, फिर दोनों दुनियाएँ जाँचें

AWS दस्तावेज़ करता है कि स्प्लिट-टनल एंडपॉइंट पर रूट बदलने से क्लाइंट कनेक्शन रीसेट होते हैं। इस बात को ध्यान में रखकर परिवर्तन की योजना बनाएँ: उसे लागू करें, समर्थित क्लाइंट से फिर जुड़ें, और संपादन से पहले लागू स्थिति पर भरोसा करने के बजाय इंस्टॉल किए गए रूट फिर से पढ़ें। पुरानी लागू स्थिति ही सबसे आम कारण है कि सही परिवर्तन टूटा हुआ दिखता है।

डिज़ाइन तभी स्वीकार करें जब एक निजी संसाधन और एक सार्वजनिक गंतव्य दोनों इच्छित रूप से व्यवहार करें, नाम से और पते से, उन पता परिवारों में जिन्हें आप वास्तव में समर्थन देते हैं। प्रमाणीकरण करने वाला टनल सही ढंग से विभाजन करने वाले टनल के समान नहीं है।

रूट सूची को तर्क के साथ रनबुक में लिखें, ताकि अगला व्यक्ति जानबूझकर किए गए बहिष्करण और भूल गए बहिष्करण में अंतर कर सके।