آپ کا BGP سیشن VPC کی راؤٹ ٹیبل میں کیوں نظر نہیں آتا

جو کہانی بار بار دہرائی جاتی ہے وہ یہ ہے کہ EC2 VPN آلات پر موجود راؤٹنگ ڈیمن BGP کے اوپر آنے پر VPC کو اس کے دور دراز پری فکس سکھا دے گا۔ اس کا آدھا سچ ہے۔ سیشن اوپر آتا ہے، اور اس کی وجہ سے VPC کی راؤٹ ٹیبل میں کچھ نہیں بدلتا، اسی لیے پہلی علامت عام طور پر ایک سب نیٹ ہوتی ہے جو ٹریفک کو خاموشی سے کالے سوراخ میں پھینک دیتا ہے۔

یہاں دو مختلف چیزیں ملائی جا رہی ہیں: راؤٹ سرور کے ساتھ پیئرنگ، اور ٹیبل میں راؤٹ انسٹال کرنا۔

افسانہ: BGP چلائیں اور VPC پری فکس سیکھ لے گا

BGP دو بولنے والوں کے درمیان گفتگو ہے، اور اس ڈیزائن میں بولنے والے آپ کے آلے پر موجود راؤٹنگ ڈیمن اور VPC Route Server کا ایک اینڈ پوائنٹ ہیں جسے AWS آپ کی ملکیت والے سب نیٹ میں رکھتا ہے۔ وہ گفتگو پری فکس لے کر چلتی ہے۔ یہ آپ کے ورک لوڈ سب نیٹس کی راؤٹ ٹیبل کو نہیں چھوتی، کیونکہ وہ ٹیبلز صرف پھیلاؤ کے ذریعے سیکھتی ہیں جسے ہر ایک پر فعال کرنا پڑتا ہے۔ جب تک ایسا نہ ہو، VPC کا تانا بانا آلے کے علم کے بارے میں کچھ نہیں جانتا۔

سیٹ اپ کے مراحل ایک وجہ سے الگ ہیں: منسلک کریں، اینڈ پوائنٹ بنائیں، پیئر کریں، پھر پھیلاؤ فعال کریں۔

Route Server ایک کنٹرول پلین ہے، سرنگ نہیں

Route Server ایک بھی پیکٹ کو انکرپٹ، فارورڈ یا معائنہ نہیں کرتا۔ یہ آلے کے ساتھ BGP کا تبادلہ کرنے اور نتیجے میں آنے والے پری فکس ان راؤٹ ٹیبلز کو دینے کے لیے موجود ہے جو انہیں وصول کرنے کے لیے ترتیب دی گئی ہیں۔ ڈیٹا پلین نہیں بدلا: پیکٹ اب بھی آلے کے نیٹ ورک انٹرفیس سے نکلتے ہیں، اس کے VPN سے گزرتے ہیں اور اسی راستے واپس آتے ہیں۔

اس کا مطلب ہے کہ فارورڈنگ انسٹینس پر ماخذ اور منزل کی جانچ اب بھی اہم ہے، کیونکہ انسٹینس اب کسی اور کو مخاطب کی گئی ٹریفک فارورڈ کر رہا ہے۔

سیکیورٹی گروپس اور سب نیٹ کنٹرولز فارورڈ شدہ بہاؤ پر بھی لاگو ہوتے ہیں۔ Route Server ٹریفک پھینکنے والے آلے کو اسے فارورڈ کرنے پر مجبور نہیں کرے گا، اور دور دراز طرف گم شدہ واپسی راؤٹ کی مرمت نہیں کرے گا۔

پھیلاؤ ہر راؤٹ ٹیبل کے لیے ہے، پورے VPC کے لیے نہیں

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

آلے کے اعلان کردہ پری فکس کی فہرست کے بجائے مخصوص سب نیٹ کی مؤثر ٹیبل دیکھیں۔ API اس سوال کا سیدھا جواب دیتا ہے: aws ec2 associate-route-server اور aws ec2 enable-route-server-propagation --route-table-id <id> وہ دو مراحل ہیں جو لوگ بھول جاتے ہیں، اور aws ec2 describe-route-tables --route-table-ids <id> دکھاتا ہے کہ پری فکس route server اندراج کے طور پر آیا بھی یا نہیں۔

آلہ اب بھی ہر پیکٹ ڈھوتا ہے

رسائی کا اعلان کرنا اسے رکھنے کے برابر نہیں. BGP سیشن قائم رہ سکتا ہے جبکہ آلے کا VPN بند ہو، اور کبھی نہ بدلنے والا اسٹیٹک اعلان ٹریفک کو مردہ راستے کی طرف کھینچتا رہتا ہے۔ Route Server BFD جیسی ناکامی کی نشاندہی کی حمایت کرتا ہے، لیکن وہ ساتھی کی زندگی جانچتا ہے، اس کے پیچھے ہر چیز کی صحت نہیں۔

اعلان کو حقیقی دور دراز راؤٹ سے باندھیں: جب سرنگ اور دور دراز نیٹ ورک چل رہے ہوں تو پری فکس کا اعلان کریں، اور نہ ہوں تو اسے واپس لیں۔

ایک پری فکس واپس لیں اور دیکھیں کیا ہوتا ہے

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

راؤٹ کو دوسرے آلے پر منتقل کرنے سے وہ سیشن منتقل نہیں ہوتے جو یہ ڈھو رہا تھا، کیونکہ NAT اور فائر وال کی حالت پہلے آلے پر ہی رہتی ہے۔

درجن بھر پری فکس کے مقررہ مجموعے کے لیے، VPC کی ٹیبلز میں اسٹیٹک راؤٹ ہی سستا جواب رہتے ہیں۔ Route Server اپنی جگہ تب کماتا ہے جب پری فکس کی فہرست واقعی بدلتی ہے اور واپس لینے کی پالیسی ایسی چیز ہو جو آپ آن کال شخص کو سمجھا سکیں۔