آن-پریمائسز کلائنٹ کے لیے 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 کی طرف سے رسائی درکار ہوتی ہے۔