ऑन-प्रिमाइसेस क्लायंटसाठी S3 गेटवे की इंटरफेस एंडपॉइंट?

साइट VPN मार्फत कार्यालय नेटवर्कवरून S3 पर्यंत पोहोचणे ही अशी राउटिंग समस्या नाही जी स्थिर रूट एकट्याने सोडवू शकेल। गेटवे एंडपॉइंट रूट टेबलशी जोडलेला असतो आणि VPC च्या आत निर्माण होणाऱ्या विनंत्या सर्व्ह करतो। इंटरफेस एंडपॉइंट तुमच्या सबनेटमध्ये खाजगी पत्त्यांसह लवचिक नेटवर्क इंटरफेस ठेवतो, आणि या पत्त्यांपर्यंत VPN किंवा Direct Connect मार्फत ऑन-प्रिमाइसेसवरून पोहोचता येते। विनंती कुठून सुरू होते हे ठरवते की तुम्हाला प्रत्यक्षात दोन्हींपैकी काय हवे आहे, आणि DNS, सुरक्षा गट व धोरणाचे काम त्या उत्तरातून येते।

विनंती कुठून सुरू होते यावरून एंडपॉइंटचे प्रकार वेगळे करा

गेटवे एंडपॉइंट व्यवस्थापित प्रीफिक्स सूचीकडे निर्देश करणारी रूट-टेबल नोंद म्हणून दिसतो। त्याला नेटवर्क इंटरफेस, सुरक्षा गट किंवा स्वतःचा खाजगी पत्ता नसतो, आणि त्यामुळेच ऑन-प्रिमाइसेस होस्ट त्याकडे राउट करू शकत नाही: पलीकडे राउट करण्यासारखे काहीच नाही। VPC च्या आतून येणारा ट्राफिक S3 पर्यंत पोहोचतो कारण सबनेटचे रूट टेबल तो प्रीफिक्स एंडपॉइंटकडे पाठवते। इतर कुठूनही येणाऱ्या ट्राफिककडे अनुसरण करण्यासाठी अशी नोंद नाही।

इंटरफेस एंडपॉइंट म्हणजे तुम्ही निवडलेल्या सबनेटमधील नेटवर्क इंटरफेसचा संच, प्रत्येकाकडे त्या सबनेटमधील खाजगी पत्ता आणि जोडलेला सुरक्षा गट असतो। हिब्रिड क्लायंट वापरू शकणारा हाच आकार आहे, कारण तुमचा टनेल पॅकेट नेऊ शकेल असे हे सामान्य गंतव्य आहे। याचा अर्थ असाही की एंडपॉइंट सबनेटमधील पत्ते वापरतो आणि ते संपू शकतात।

aws ec2 describe-vpc-endpoints --query "VpcEndpoints[].{Id:VpcEndpointId,Type:VpcEndpointType,Service:ServiceName,State:State}" --output table

नावाऐवजी Type स्तंभ वाचा। एकच VPC सामान्यतः एकाच सेवेसाठी दोन्ही प्रकार ठेवते, आणि तुमच्या ऑन-प्रिमाइसेस अनुप्रयोगाला हवी असलेली नोंद इंटरफेसची नोंद आहे।

S3 तपासण्यापूर्वी इंटरफेस पत्त्यापर्यंतचा मार्ग तयार करा

तीन गोष्टी एकाच वेळी खऱ्या असल्या पाहिजेत: ऑन-प्रिमाइसेस राउटरकडे एंडपॉइंट सबनेटपर्यंत रूट आहे, त्या सबनेटमधून परतीचा मार्ग क्लायंट नेटवर्कपर्यंत पोहोचतो, आणि एंडपॉइंटचा सुरक्षा गट क्लायंटची स्रोत श्रेणी स्वीकारतो। तीनही पूर्ण झाल्यावरही सबनेटचे नेटवर्क ACL पॅकेट टाकून देऊ शकते, म्हणून ते नंतरची विचारसरणी न म्हणता चौथा मुद्दा म्हणून तपासा।

VPC मधील कोणत्यातरी EC2 इन्स्टन्सपर्यंत चालणारा रूट यापैकी काहीही सिद्ध करत नाही। तो फक्त टनेल सुरू आहे हे दाखवतो, जो तुम्हाला आधीच माहीत असलेल्या मार्गाचा एकच भाग आहे। एंडपॉइंटचा पत्ता वेगळा सिद्ध करा, नंतर नाव त्या पत्त्यावर सोडवले जाते हे सिद्ध करा।

ip route get 10.60.4.37
nc -vz 10.60.4.37 443
openssl s_client -connect 10.60.4.37:443 -servername bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com </dev/null

पहिला आदेश क्लायंट कोणता इंटरफेस वापरेल हे दाखवतो। दुसरा TCP हातमिळवणी सिद्ध करतो। तिसरा एंडपॉइंट नावासाठी वैध प्रमाणपत्रासह TLS पूर्ण होते हे सिद्ध करतो, आणि परवानग्यांना दोष देण्यापूर्वी चुकीचा पत्ता पकडणारी तपासणी हीच आहे।

अनुप्रयोगाला कोणते DNS उत्तर मिळते ते ठरवा

VPC मध्ये इंटरफेस एंडपॉइंट असणे स्वतःच ऑन-प्रिमाइसेस SDK पुनर्निर्देशित करत नाही। क्लायंट एकतर AWS त्या एंडपॉइंटसाठी प्रकाशित करत असलेले एंडपॉइंट-विशिष्ट नाव वापरतो, किंवा कार्यालयातून सोडवता येईल असे तुम्ही जाणूनबुजून केलेले खाजगी होस्टेड झोन वापरतो।

हिब्रिड रिझोल्यूशनसाठी ऑन-प्रिमाइसेस रिझॉल्व्हरला VPC च्या DNS दृश्यात समर्थित मार्ग हवा, सामान्यतः Resolver इनबाउंड एंडपॉइंटमार्फत। कोणत्या क्वेरी स्रोतांवर परिणाम होतो हे न समजता खाजगी DNS सुरू करणे म्हणजे शोध कार्यालयाला पोहोचू न शकणारा पत्ता परत देऊ लागण्याचा मार्ग। हे सेटिंग VPC रिझॉल्व्हरमधून येणाऱ्या क्वेरींची उत्तरे बदलते, सर्वत्रच्या प्रत्येक क्लायंटची नाही।

dig +short bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com
aws s3api head-bucket --bucket example-artifacts --endpoint-url https://bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com

दोन्ही अनुप्रयोगाच्या होस्टवर चालवा, VPC मधील जंप बॉक्सवर नाही। तिथे उत्तर देणारा रिझॉल्व्हर तुमचा वर्कलोड वापरतो तोच आहे, आणि वेगळ्या होस्टवरून वेगळे उत्तर मिळणे हे या रचनेतील सर्वात सामान्य गोंधळाचे कारण आहे।

पोहोचणे म्हणजे अधिकृतता नाही

एंडपॉइंटवर पोहोचणाऱ्या विनंतीला अजूनही अधिकृत प्रिन्सिपल आणि लागू बकेट परवानगी हवी। एंडपॉइंट धोरण एंडपॉइंट काय अनुमती देतो ते संकुचित करू शकते, आणि बकेट धोरण ते पुन्हा संकुचित करू शकते। इंटरफेसपर्यंत पोहोचणे कॉलर कोणत्या वस्तू वाचू शकतो याबद्दल काहीही सांगत नाही।

दोन्ही दिशा तपासा: इच्छित बकेटविरुद्ध एक निरुपद्रवी अधिकृत कॉल, आणि धोरणाबाहेरील ओळख किंवा संसाधनासाठी नाकारला जाणे अपेक्षित असलेला एक कॉल। निकालासोबत एंडपॉइंटचे नाव, सोडवलेला पत्ता आणि धोरणाचा संदर्भ ठेवा जेणेकरून पुढील व्यक्ती ते पुन्हा तयार करू शकेल। धोरणाचा प्रकार सांगणारा नकार एक तासाचा अंदाज वाचवतो।

शेवटी, तरतूद करण्यापूर्वी दोन्ही पर्यायांचा खर्च पाहा। इंटरफेस एंडपॉइंट इंटरफेस-तास आणि गीगाबाइटनुसार बिल करतो, गेटवे एंडपॉइंट करत नाही, आणि हाच फरक केवळ VPC बाजूचा प्रवेश हवा असलेल्या अनेक कमी-प्रमाण वर्कलोडसाठी प्रश्न ठरवतो।