متعدد NIC والی GCP VM: جوابات غلط انٹرفیس سے کیوں نکلتے ہیں

Compute Engine VM میں دوسرا انٹرفیس شامل کرنے سے اسے ایک اور نیٹ ورک کنکشن ملتا ہے، ہم آہنگ واپسی راستہ نہیں۔ مہمان اب بھی اپنے ہی روٹس اور قواعد سے انٹرفیس اور ماخذ پتہ منتخب کرتا ہے۔ پھر Google Cloud پیکٹ جس انٹرفیس سے نکلا اس کے گرد VPC روٹنگ اور فائر وال پالیسی لاگو کرتا ہے۔ جب یہ دونوں فیصلے میل نہیں کھاتے، درخواستیں ایک NIC پر آتی ہیں اور جوابات دوسرے سے نکلتے ہیں، اور برانچ آدھی کھلی گفتگو دیکھتی ہے۔

راستہ پانچ مراحل میں طے کریں اور پالیسی قاعدہ لکھنے سے پہلے ہی عدم مطابقت سامنے آ جائے گی۔

مرحلہ 1: کلاؤڈ NICs کو مہمان آلات سے منسلک کریں

کلاؤڈ انٹرفیسز کو nic0، nic1 وغیرہ کا نام دیتا ہے، اور مہمان ایسے آلات کے نام دیکھتا ہے جن کا میل کھانا ضروری نہیں۔ کچھ اور کرنے سے پہلے انسٹنس میٹا ڈیٹا یا انٹرفیس کے اپنے پتے سے نقشہ حل کریں۔ DHCP کا فراہم کردہ عام ڈیفالٹ راستہ nic0 سے منسلک ہے، اسی لیے انٹرنیٹ کی طرف راستہ اکثر حادثاتی طور پر جیت جاتا ہے۔ اندازہ لگائے گئے آلے کے نام پر پالیسی لکھنا ہی وہ طریقہ ہے جس سے درست قاعدہ غلط انٹرفیس پر پڑتا ہے۔

پتے، آلات کے نام اور ہر ایک کا VPC لکھیں۔ وہ تین کالم والا نقشہ ہر اگلے مرحلے کا ان پٹ ہے۔

مرحلہ 2: دو روٹنگ فیصلوں کے نام رکھیں

پہلا فیصلہ مہمان کا ہے: اس پیکٹ کے لیے کون سا انٹرفیس اور کون سا ماخذ پتہ۔ دوسرا کلاؤڈ کا ہے: VPC کے روٹس اور فائر وال پالیسی اس انٹرفیس کے گرد کیا اجازت دیتے ہیں۔

VPN کی طرف والے VPC میں نظر آنے والا راستہ اس NIC کو چننے والا مہمان راستہ نہیں بنتا۔ کلاؤڈ راستہ بتاتا ہے کہ نیٹ ورک کیا پہنچا سکتا ہے، جبکہ مہمان راستہ طے کرتا ہے کہ پیکٹ کیا کرتا ہے۔

مرحلہ 3: واپسی راستے کی پالیسی منتخب کریں

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

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

مرحلہ 4: مہمان کے اپنے فلٹرز چیک کریں

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

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

مرحلہ 5: ہر راستے کے لیے ایک بہاؤ آزمائیں

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

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

دوسرا NIC آپ کو کیا نہیں دیتا

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

اگر VM کو دوسری مشینوں کا ٹریفک آگے بھیجنا ہے، تو اس روٹر کردار کی واضح منصوبہ بندی کریں، جس میں فارورڈنگ کی اجازت دینے والی کلاؤڈ سیٹنگ اور اس کے ساتھ جانے والے مہمان فلٹرز شامل ہوں۔