مشترکہ Transit Gateway: AWS RAM میں راستوں کی ملکیت کس کی ہے
RAM شیئرنگ دوسرے اکاؤنٹ کو VPC منسلک کرنے دیتی ہے، لیکن روٹ ٹیبلز، ایسوسی ایشنز اور پروپیگیشنز گیٹ وے کے مالک کے پاس ہی رہتی ہیں۔ یہی حد ہے۔
Transit Gateway کو Resource Access Manager کے ساتھ شیئر کرنا ایک مخصوص کام کرتا ہے: یہ دوسرے اکاؤنٹ کو ایسے وسیلے کے خلاف متعین منسلکہ API سیٹ کال کرنے دیتا ہے جس کا وہ مالک نہیں۔ یہ گیٹ وے، اس کی روٹ ٹیبلز یا ٹریفک کیسے آگے بھیجا جائے گا یہ طے کرنے کا حق منتقل نہیں کرتا۔ لوگ اُلٹا فرض کرتے ہیں کیونکہ منسلکہ وصول کنندہ کے کنسول میں ظاہر ہوتا ہے اور فوراً کام کرتا ہے، جو ملکیت جیسا لگتا ہے۔ اس کے نیچے کا طریقہ کار مشترکہ وسیلے پر اجازت دینا ہے، اور ہر چائلڈ آبجیکٹ مالک کے اکاؤنٹ کی حد کے اندر ہی رہتا ہے۔ یہی تقسیم مشترکہ ٹرانزٹ کے گرد زیادہ تر رسائی-رد ٹکٹس کی وضاحت کرتی ہے۔
شیئرنگ درحقیقت کیا سونپتی ہے
وسیلہ شیئرنگ ایک وسیلہ، ایک پرنسپل اور ایک منظم اجازت کا نام دیتی ہے۔ اجازت اُن کارروائیوں کی فہرست دیتی ہے جو وہ پرنسپل کر سکتا ہے، اور Transit Gateway کے لیے وہ فہرست مشترکہ وسیلے پر منسلکہ کارروائیوں کا احاطہ کرتی ہے۔
فہرست سے باہر کوئی بھی چیز کنسول میں نہیں بلکہ API پر ناکام ہوتی ہے، اسی لیے سکرپٹ پہلی بار چلنے پر خرابی اکثر ظاہر ہوتی ہے۔
روٹ ٹیبلز، ایسوسی ایشنز اور پروپیگیشنز مالک کے پاس ہی رہتی ہیں
آگے بھیجنے کا تعین تین چائلڈ آبجیکٹ کرتے ہیں: منسلکہ کس روٹ ٹیبل سے منسلک ہے، یہ کن ٹیبلز میں پھیلتا ہے، اور اُن ٹیبلز میں کون سی راستے ہیں۔ AWS کی شیئرنگ دستاویزات کہتی ہیں کہ وصول کنندہ شیئرنگ کے ذریعے ٹرانزٹ گیٹ وے کی روٹ ٹیبلز یا اُن کی ایسوسی ایشنز اور پروپیگیشنز نہ بنا سکتا ہے، نہ بدل سکتا ہے، نہ حذف کر سکتا ہے۔ وہ کالز مالک اکاؤنٹ کی ہیں۔ جس وصول کنندہ کو نئی ایسوسی ایشن درکار ہو وہ انتظامی تبدیلی مانگ رہا ہے، اُس اجازت کا استعمال نہیں کر رہا جسے فعال کرنا بھول گیا۔
نیچے دیا گیا جدول وہی تقسیم ہے جو میں ڈیزائن دستاویزات میں رکھتا ہوں، کیونکہ یہ عملے کی تبدیلیوں میں بھی قائم رہتا ہے۔
| Role | What it controls |
|---|---|
| Transit Gateway owner | The gateway, its route tables, associations and propagations; the Site-to-Site VPN attachment is created here. |
| VPC owner using the share | Its own attachment, subnet route tables and security policy for the workloads. |
| Shared-subnet participant | Workload traffic only, following routes the VPC owner already set. |
درمیانی سطر غور سے پڑھیں: VPC کا مالک اپنے سب نیٹ کے راستوں کو کنٹرول کرتا ہے، گیٹ وے کا مالک مرکزی آگے بھیجنے کا فیصلہ کنٹرول کرتا ہے، اور کام کرنے والے راستے کو دونوں درکار ہیں۔ کوئی بھی ایک اکاؤنٹ اسے تنہا مکمل نہیں کر سکتا۔
ایک راستہ، دو اکاؤنٹس
اسپوک VPC سے آن-پریمائسز پریفکس تک پیکٹ کا پیچھا کریں۔ اسپوک سب نیٹ روٹ ٹیبل کو وہ پریفکس ٹرانزٹ گیٹ وے منسلکہ کو بھیجنا چاہیے، جسے VPC کا مالک بدل سکتا ہے۔ پھر گیٹ وے کے پاس منسلکہ کی متعلقہ ٹیبل میں VPN منسلکہ کی طرف اشارہ کرنے والا راستہ ہونا چاہیے، جسے صرف مالک ہی بدل سکتا ہے۔ واپسی ٹریفک کو دونوں کا آئینہ درکار ہے۔ کوئی بھی پہلو چھوڑا تو آپ کو نیم نصب راستہ ملتا ہے جو فائر وال مسئلے جیسا لگتا ہے۔
دونوں تبدیلیاں دو ذمہ داروں کے ساتھ ایک ٹکٹ میں لکھیں، ورنہ وہ مختلف ہفتوں میں مکمل ہوں گی۔
جب مقام اہم ہو تو Availability Zone ID استعمال کریں
زون کے نام اکاؤنٹ کے مقامی عرفی نام ہیں۔ ایک اکاؤنٹ میں us-east-1a کا دوسرے اکاؤنٹ کے us-east-1a جیسا ہی طبعی زون ہونا یقینی نہیں۔ جب ڈیزائن کو ایک ہی زون میں منسلکہ اور ورک لوڈ درکار ہو، تو AZ ID کا موازنہ کریں اور درج کریں۔
ناموں کا موازنہ ایسا نقشہ دیتا ہے جو درست لگتا ہے اور ایسا تاخیری پروفائل جو درست نہیں۔ نقشہ ابھی بن رہا ہو تبھی جانچیں، کسی کے فرق ناپنے کے بعد نہیں۔
شیئرنگ منسوخ کرنا ڈیٹا راستہ نہیں کاٹتا
شیئرنگ ہٹانا واپسی جیسا لگتا ہے، اور یہ فوری ٹریفک بندی نہیں۔ AWS دستاویز کرتا ہے کہ گیٹ وے شیئرنگ سے باہر ہونے پر منسلکہ فعال رہتا ہے۔ وسیلے کا انتظام کرنے کی اجازت غائب ہو جاتی ہے، جبکہ پہلے سے موجود منسلکہ تب تک آگے بھیجتا رہتا ہے جب تک کوئی اسے حذف یا غیر فعال نہ کرے۔ منسوخی کا دو مرحلوں میں منصوبہ بنائیں: شیئرنگ ہٹائیں، پھر منسلکہ، اور دوسرا مالک کرے گا۔
اگر شیئرنگ ہی آپ کا واحد کنٹرول ہے، تو آپ کے پاس کوئی کنٹرول نہیں۔
شیئرنگ ریکارڈ اور روٹنگ ریکارڈ اکٹھے رکھیں
دو فن پارے دو مختلف سوالوں کے جواب دیتے ہیں۔ شیئرنگ ریکارڈ بتاتا ہے کہ کون وسیلے کے ساتھ کام کر سکتا ہے۔ روٹ ٹیبلز بتاتی ہیں کہ کون سے نیٹ ورک واقعی بات کر سکتے ہیں۔ اُنہیں ایک ہی مالک فہرست کے ساتھ اکٹھا محفوظ کریں، ورنہ اگلا واقعہ کسی ایسے شخص سے شروع ہوگا جو ایسی اجازت ثابت کر رہا ہو جو کبھی مسئلہ نہ تھی۔
پھر ہر سمت میں ایک بہاؤ اور ایک ایسا پریفکس آزمائیں جو ناقابل رسائی رہنا چاہیے۔