AWS Transit Gateway پر متعدد VPC کے لیے ایک سائٹ سے سائٹ VPN

اس سہ ماہی میں دو VPC کو دفتر کے نیٹ ورک کی ضرورت ہے، اور تخمینہ دوسری سرنگ پر ہی ٹوٹتا ہے۔ AWS Transit Gateway مشترکہ روٹنگ مرکز کا کردار ادا کر سکتا ہے: VPN ایک بار منسلک ہوتا ہے، اور ہر VPC اسی مرکز سے منسلک ہوتا ہے۔ پھر مقامی نیٹ ورک ایک ہی کنکشن سے ہر منسلک VPC تک پہنچتا ہے۔ یہ بدلتا ہے کہ روٹنگ کا فیصلہ کس کے پاس ہے، اور زیادہ تر ڈیزائن اسی حصے میں غلطی کرتے ہیں۔

VPN اٹیچمنٹ اور VPC اٹیچمنٹس ایک ہی گیٹ وے پر الگ اشیاء ہیں، اسی لیے روٹنگ تعلقات بعد میں بنانے پڑتے ہیں۔

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

پیئرنگ وہ مختصر راستہ کیوں نہیں جس کی لوگ امید کرتے ہیں

پرکشش متبادل یہ ہے کہ VPN کو VPC A پر ختم کریں اور VPC B کو اس کے ساتھ پیئر کریں۔ عام VPC پیئرنگ A کے VPN کنکشن کے ذریعے کنارے سے کنارے تک ترسیل فراہم نہیں کرتی۔ پیئر صرف ان پتوں تک پہنچتا ہے جو پیئرنگ خود فراہم کرتی ہے، اور VPN کنارہ ان میں سے ایک نہیں۔ ترسیل مرکز دیتا ہے؛ پیئرنگ آپ کو ایک جوڑا دیتی ہے۔

یہ پابندی پیئرنگ کی خصوصیت ہے، ایسا کوٹہ نہیں جسے بڑھایا جا سکے۔

وابستگی اور پھیلاؤ مختلف کام کرتے ہیں

ٹرانزٹ گیٹ وے کے اندر وابستگی وہ روٹ ٹیبل منتخب کرتی ہے جس سے اٹیچمنٹ سے آنے والی ٹریفک تلاش کی جاتی ہے۔ پھیلاؤ طے کرتا ہے کہ کون سے ٹیبل اٹیچمنٹ کے سیکھے یا منسلک پری فکس وصول کریں گے۔ ایک اٹیچمنٹ ایک ٹیبل سے وابستہ ہو کر بیک وقت کئی میں پھیل سکتا ہے۔ دونوں کو خلط ملط کرنا ہی وہ طریقہ ہے جس سے ڈیزائن ایسی رسائی پر پہنچتا ہے جس کا کسی نے منصوبہ نہیں بنایا۔

مکمل منسلک چھوٹا مرکز آسان صورت ہے۔

ہر اٹیچمنٹ کو ایک ٹیبل میں رکھیں تو VPN سمیت دونوں VPC پری فکس صاف حل ہو جاتے ہیں۔ یہ VPC کے درمیان رسائی کی بھی اجازت دیتا ہے جس کا ادارے نے شاید کبھی ارادہ نہ کیا ہو، کیونکہ مشترکہ ٹیبل شاخ کا تصور نہیں جانتی۔

ورک لوڈ کے راستے کہیں اور رہتے ہیں

ہر ورک لوڈ سب نیٹ کو مطلوبہ مقامی پری فکس کے لیے ٹرانزٹ گیٹ وے کی طرف اپنا راستہ اب بھی درکار ہے۔ وہ VPC روٹ ٹیبلز گیٹ وے کی اپنی ٹیبلز سے الگ اشیاء ہیں۔ ضروری پری فکس شامل کریں اور ہر منزل کو نئے ڈیفالٹ سے بدلنے کے بجائے موجودہ راستے محفوظ رکھیں۔ سب نیٹ راستہ بھی گاہک کے آلے کو کچھ نہیں بتاتا۔

ڈائنامک یا اسٹیٹک روٹنگ سوچ سمجھ کر منتخب کریں؛ پیئرنگ دونوں میں سے کچھ نہیں دیتی۔

مقامی رسائی کھوئے بغیر شاخیں الگ رکھیں

جب A اور B دونوں دفتر تک پہنچ سکتے ہیں مگر ایک دوسرے کی طرف روٹ نہیں کر سکتے، تو ٹیبل تقسیم کریں۔ VPN اٹیچمنٹ کی وابستہ ٹیبل VPC پری فکس رکھتی ہے۔ VPC اٹیچمنٹس کی وابستہ ٹیبل مقامی پری فکس رکھتی ہے، بغیر کسی ایسے راستے کے جو A کو B سے جوڑے۔ پھیلاؤ ہی وہ تعلق پیدا کرتا ہے، اس لیے آپ کو کبھی ہر ڈیفالٹ وابستگی قبول نہیں کرنی پڑتی۔

یہ روٹنگ کی تنہائی ہے، اور یہ ایپلیکیشن کی اجازت نہیں۔

سیکیورٹی گروپس، نیٹ ورک ACL، ہوسٹ فائر وال اور ہر سروس کی اپنی اجازتیں اب بھی طے کرتی ہیں کہ کون سی ٹریفک قبول ہوگی۔ اگر معائنہ درکار ہو تو مرکز یہ کرے گا ماننے کے بجائے اس کا معاون راستہ واضح طور پر ڈیزائن کریں۔

وہ کیا ہے جو مرکز ٹھیک نہیں کرتا

پتوں کے منصوبے اب بھی بغیر اوورلیپ کے رہنے چاہئیں، کیونکہ مرکز ایک پری فکس کو دو ورک لوڈ کی شناخت کی اجازت نہیں دیتا۔ ہر VPC اٹیچمنٹ کو وہ Availability Zone کوریج درکار ہے جس کی اس کے ورک لوڈ توقع کرتے ہیں۔ BGP کے ساتھ، گاہک کے آلے کے راستے ہر ضروری پری فکس کی طرف واپس ڈیزائن اور اس کی درآمد پالیسی سے مطابقت رکھنے چاہئیں۔ گمشدہ اعلان بالکل ٹوٹی سرنگ جیسا دکھتا ہے۔

VPN کنکشن اور ٹرانزٹ گیٹ وے اب مشترکہ بنیادی ڈھانچہ ہیں۔

سرنگوں کی فالتو پن، آلات کی صلاحیت، نگرانی اور دیکھ بھال کا منصوبہ تمام منحصر VPC کے گرد بنائیں، ہر ایک کو خودمختار طور پر منسلک سمجھنے کے بجائے۔

موجودہ virtual private gateway ترتیب سے منتقلی بھی وہی واضح منصوبہ مانگتی ہے۔ اٹیچمنٹس اور پالیسیاں بنائیں، ایک کنٹرول شدہ ورک لوڈ راستہ منتقل کریں، اور پرانے راستے کو ریٹائر کرنے سے پہلے اجازت یافتہ اور مسترد تعلقات کی تصدیق کریں۔ مرکزیت تب مدد کرتی ہے جب نیٹ ورک ٹیم کو مشترکہ کنیکٹیویٹی سنبھالنے کے لیے ایک جگہ دے، اور نقصان پہنچاتی ہے جب ایک بڑی ٹیبل کے پیچھے چھپا دے کہ کون کس تک پہنچ سکتا ہے۔