VGW کے BGP اعلانات اور VPC کا روٹ ٹیبل: کیا کیا بدلتا ہے

VPC سب نیٹ کے روٹ ٹیبل میں غائب پریفکس اور گاہک کے راؤٹر پر غائب پریفکس دو مختلف خرابیاں ہیں، اور ان میں سے صرف ایک AWS روٹ ٹیبلوں کے اندر ٹھیک ہوتی ہے۔ ورچوئل پرائیویٹ گیٹ وے اپنے VPC سے منسلک CIDR بلاک اعلان کرتا ہے؛ سب نیٹ کا روٹ ٹیبل طے کرتا ہے کہ کوئی ورک لوڈ اپنا جواب کہاں بھیجتا ہے۔ دوسرے کو پہلے کو بدلنے کا طریقہ سمجھنا اس تشخیص میں سب سے عام غلط موڑ ہے۔ نیچے دیے گئے معائنے ترتیب سے چلائیں اور دونوں سمتوں کو الگ رکھیں۔

کوئی بھی ٹیبل پڑھنے سے پہلے منسلکے کا نام متعین کریں

سائٹ سے سائٹ VPN یا تو ورچوئل پرائیویٹ گیٹ وے پر ختم ہوتا ہے یا ٹرانزٹ گیٹ وے پر، اور وسائل کی IDs طے کرتی ہیں کہ کون سا روٹنگ ماڈل لاگو ہوتا ہے۔ پہلے انہیں پڑھیں: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'۔ جواب آپ کو بتاتا ہے کہ آگے معائنہ کرنے والا ٹیبل VPC کا روٹ ٹیبل ہے یا ٹرانزٹ گیٹ وے کا روٹ ٹیبل۔

اگر VPN ٹرانزٹ گیٹ وے سے منسلک ہے تو VPC کے روٹ ٹیبل کو کنٹرول پلیٹ فارم سمجھنا بند کریں۔ وہاں VPC کا ٹیبل گیٹ وے کے منسلکے کی طرف اشارہ کرتا ہے، اور ایسوسی ایشن و پھیلاؤ ٹرانزٹ گیٹ وے کے روٹ ٹیبل میں ہوتے ہیں۔ دونوں نقطہ ہائے نظر ملانے سے غلط شے کے بارے میں پراعتماد نتائج نکلتے ہیں۔

AWS سے دفتر کی سمت ایک اعلان ہے

VGW منسلکے کے لیے، گیٹ وے اپنے VPC سے منسلک CIDR بلاک BGP کے ذریعے گاہک کے گیٹ وے کو اعلان کرتا ہے۔ الگ سب نیٹ روٹ شامل کرنا، یا روٹ کو کسی پیئر شدہ VPC یا آلے کی طرف موڑنا، کوئی دوسرا منسلک CIDR شامل نہیں کرتا اور اس اعلان میں ظاہر نہیں ہوتا۔ اگر دفتر میں پریفکس غائب ہو تو کسی بھی روٹ ٹیبل میں ترمیم سے پہلے موصول شدہ روٹوں کی فہرست کا VPC ایسوسی ایشنوں سے موازنہ کریں۔

سادہ اصول کے استثنات ہیں، اس لیے اسے اس کے دائرے میں رکھیں۔ VPN CloudHub کا انتظام گاہک گیٹ ویز کے درمیان سائٹ پریفکس دوبارہ اعلان کر سکتا ہے، اور ٹرانزٹ گیٹ وے اپنے پھیلاؤ کے اصولوں کی پیروی کرتا ہے۔ یہ دعویٰ کہ VGW صرف اپنے VPC کا اعلان کرتا ہے ایک مفید ڈیفالٹ ہے، کوئی ایسا قانون نہیں جو آپ کو ملنے والی ہر ٹوپولوجی کو محیط ہو۔

دفتر سے AWS کی سمت پھیلاؤ اور انتخاب ہے

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

قیاس کرنے کے بجائے اصل پڑھیں: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'۔ EnableVgwRoutePropagation اصل والا اندراج BGP سے آیا؛ CreateRoute اصل والا اندراج کسی انسان نے ٹائپ کیا اور جب تک کوئی اسے حذف نہ کرے جیتتا رہے گا۔

دونوں سمتوں کو الگ رکھنے والی رن بک

کچھ بھی بدلنے سے پہلے AWS کی طرف چار حقائق لکھیں: منسلکے کی قسم، VPC کے منسلک CIDR، زیر بحث پریفکس کے لیے سب نیٹ روٹ کی اصل، اور ٹنل اور BGP کی حالت۔ وہی describe کال ہر ٹنل کے لیے قبول شدہ روٹوں کی گنتی کے ساتھ VgwTelemetry واپس کرتا ہے، جو بتاتا ہے کہ AWS نے کوئی روٹ قبول کیے یا نہیں۔ پھر اس کا موازنہ گاہک کے آلے نے واقعی جو نصب کیا اس سے کریں۔ BGP میں موجود مگر فارورڈنگ ٹیبل میں غائب پریفکس مقامی درآمد یا بہترین راستے کا مسئلہ ہے، AWS روٹ ٹیبل کا مسئلہ نہیں۔

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

وہاں رہتے ہوئے کیا نہ بدلیں

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

ڈیٹا راستہ ان سب سے الگ ہے۔ سکیورٹی گروپس سٹیٹ فل ہوتے ہیں، نیٹ ورک ACL نہیں، اور کوئی ہوسٹ فائر وال یا غیر متناسب واپسی راستہ اس ٹریفک کو گرا سکتا ہے جسے روٹنگ نے درست طور پر پہنچایا تھا۔ اعلان شدہ مجموعہ بھی اپنے اندر کی ہر سروس کو اجازت نہیں دیتا، اس لیے رسائی کو پالیسی کی سرحد پر محدود کریں، اس پر انحصار کرنے کے بجائے کہ کوئی پتہ اتفاقاً BGP اعلان میں نظر آتا ہے یا نہیں۔

ہر روٹ ٹیبل استفسار سے پہلے اور بعد کی حالت تبدیلی کے ریکارڈ میں محفوظ کریں۔ اگر تبدیلی معاملات بگاڑ دے تو پچھلے روٹ بحال کریں اور اسی استفسار سے تصدیق کریں، کیونکہ جس واپسی کی آپ تصدیق نہیں کر سکتے وہ صرف ایک اندازہ ہے۔