EC2 उपलब्धता क्षेत्रांमध्ये: VPN आधी राउटिंग तपासा
एकाच VPC मध्ये दोन EC2 इन्स्टन्स आधीपासूनच क्षेत्रांदरम्यान खाजगी राउटिंग सामायिक करतात. दुसरा बोगदा जोडण्यापूर्वी सबनेट तक्ते आणि प्रवेश नियम तपासा.
दोन EC2 इन्स्टन्समध्ये VPN सॉफ्टवेअर स्थापित करण्यापूर्वी एका प्रश्नाचे उत्तर द्या: ते एकाच VPC मध्ये आहेत का? असल्यास, खाजगी मार्ग आधीपासूनच अस्तित्वात आहे आणि क्षेत्रांदरम्यानची नेमणूक तो बदलत नाही. या परिस्थितीत बहुतेक काम म्हणजे प्रत्येक सबनेट प्रत्यक्षात कोणता राउट तक्ता वापरतो हे पुष्टी करणे आणि नंतर बिघाड हा राउटिंगचा प्रश्न होता का हे शोधणे. या विशिष्ट प्रश्नाचे बोगदा हे सहसा चुकीचे उत्तर असते.
तपासणी 1: एकच VPC की वेगवेगळे VPC
VPC प्रादेशिक आहे आणि उपलब्धता क्षेत्रांमध्ये पसरतो, तर प्रत्येक सबनेट नेमका एका क्षेत्राचा असतो. एकाच VPC च्या वेगवेगळ्या क्षेत्रांतील दोन इन्स्टन्स अजूनही त्याच खाजगी राउटिंग डोमेनमध्ये आहेत.
वेगवेगळे VPC कधीही केवळ प्रदेश किंवा क्षेत्र लेबल सामायिक केल्यामुळे खाजगी मार्ग मिळवत नाहीत. त्या प्रकरणास समर्थित कनेक्शन आणि स्वतःचे मार्ग व परवानगीचे काम आवश्यक आहे, जो वेगळा निर्णय आहे.
तपासणी 2: सबनेट राउट तक्ते काय सांगतात
वास्तविक मूल्यांसह मांडणी लिहा. VPC 10.60.0.0/16 वर, सबनेट 10.60.1.0/24 आणि 10.60.2.0/24 असल्यास, इन्स्टन्सना 10.60.1.10 आणि 10.60.2.20 VPC च्या स्थानिक मार्गाने मार्ग देतो.
नंतर प्रथम सापडलेला तक्ता नव्हे, तर दोन्ही सबनेटशी संबंधित तक्ते तपासा. अधिक विशिष्ट तपासणी किंवा उपकरण मार्ग मूलभूत मार्गाला मागे टाकू शकतो आणि स्थानिक मार्गाचे लक्ष्यही नवीन संरचनांमध्ये बदलले जाऊ शकते. कन्सोलमध्ये कुठेतरी दिसणारा स्थानिक मार्ग दोन्ही वर्कलोड तो वापरतात हे सिद्ध करत नाही.
VPC प्रत्यक्षात देत असलेले खाजगी पत्ते आणि नावे वापरा. खाजगी पत्ता 10 ने सुरू होणे आवश्यक नाही आणि स्मरणातून एक तयार करणे हाच कार्यरत वातावरणाचे चुकीचे निदान करण्याचा मार्ग आहे.
तपासणी 3: राउटिंग की अधिकृतता
राउटिंग पॅकेटला फक्त लक्ष्याच्या नेटवर्क इंटरफेसपर्यंत पोहोचवते. लक्ष्याचा सुरक्षा गट अजूनही स्रोत आणि सेवा स्वीकारला पाहिजे, स्रोताचे बाहेर जाणारे नियम विनंतीला परवानगी दिली पाहिजेत आणि कोणत्याही नेटवर्क ACL ने दोन्ही दिशा अनुमत केल्या पाहिजेत कारण ACL स्थिती ठेवत नाहीत.
त्यापुढे पाहुण्याचा फायरवॉल, श्रोत्याचे बंधन आणि अनुप्रयोगाची स्वतःची ओळख आहे. यापैकी कोणीही राउटिंगने निर्दोष पोहोचवलेली विनंती नाकारू शकते.
स्वीकृती ही अनुप्रयोगाची खरी क्रिया असली पाहिजे. यशस्वी ping अनुप्रयोगात प्रवेश देत नाही आणि TLS नाव व क्रेडेन्शियल्स बरोबर आहेत हे सिद्ध करत नाही, आणि अवरोधित ping सर्व खाजगी सेवा बंद आहेत हे स्थापित करत नाही.
तपासणी 4: वेगळे कनेक्शन खरोखर आवश्यक आहे का
VPN अजूनही रचनेत असू शकतो, परंतु सांगितलेल्या कारणासाठी: हा VPC कार्यालयाशी जोडणे, लॅपटॉपना प्रवेश देणे किंवा ओव्हरले आवश्यकता पूर्ण करणे. ते कारण एकाच VPC मधील सामान्य संवादापेक्षा वेगळे आहे.
VPC काय नाही हेही लक्षात ठेवा. हा घरगुती इथरनेट विभागाचा विस्तार नाही. ब्रॉडकास्ट शोधण्यावर अवलंबून असलेल्या अनुप्रयोगासाठी मूल्यांकनाची स्वतंत्र आवश्यकता आहे. ती राउटिंग बग नसून रचनेतील त्रुटी आहे.
तपासणी 5: एन्क्रिप्शनचा प्रश्न
खाजगी पत्ता आणि परवानगी नियम अनुप्रयोग स्तरावरील क्रिप्टोग्राफिक संरक्षणाबद्दल काहीही सांगत नाहीत. जर डेटाला टोकापासून टोकापर्यंत संरक्षण हवे असेल, तर ते सेवा प्रत्यक्षात समर्थन देते त्या प्रोटोकॉल आणि ओळख मॉडेलमधून येते.
रचना टिपणीत नेटवर्क-स्तर आणि अनुप्रयोग-स्तराचे दावे वेगळे ठेवा, कारण ते एकत्र करणे हाच कोणीही अंमलात आणले नाही अशा संरक्षणाचा दावा पुनरावलोकन अखेरीस करण्याचा मार्ग आहे.
काय नोंद करावे
दोन्ही सबनेट आयडी, प्रत्येकाशी संबंधित राउट तक्ता, सुरक्षा गटाचे संदर्भ आणि तुम्ही चाचणी केलेली अनुप्रयोग क्रिया नोंदवा. ही चार तथ्ये आहेत आणि ती या मार्गाविषयीचे बहुतेक भविष्यातील वाद मिटवतात.
केवळ क्षेत्रात नेमणूक कधीही VPN जोडा असे सांगत नाही आणि खाजगी विनंती का अयशस्वी झाली हे कधीही स्पष्ट करत नाही.