अन-प्रिमाइसेस क्लाइन्टका लागि 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 पट्टिको पहुँच मात्र चाहिने धेरै कम-मात्रा वर्कलोडका लागि प्रश्न निर्धारण गर्छ।