Azure NVA معائنہ: جواب کسی دوسرے فائروال سے کیوں گزرتا ہے

برانچ سے Azure تک بہاؤ دونوں سمتوں میں درست طور پر روٹ ہو سکتا ہے اور پھر بھی ناکام ہو سکتا ہے، کیونکہ دونوں سمتیں مختلف آلات سے گزرتی ہیں۔ درخواست VPN کے ذریعے برانچ چھوڑتی ہے، NVA A پر اترتی ہے اور ورک لوڈ تک پہنچتی ہے۔ جواب ورک لوڈ چھوڑتا ہے، NVA B کی طرف اشارہ کرنے والے راستے سے ملتا ہے اور وہیں مر جاتا ہے۔ اس تصویر کا ہر راستہ درست ہے، اور TCP نشست پھر بھی ٹوٹی ہوئی ہے۔

Request: branch -> VPN gateway -> NVA A -> workload
Reply:   workload -> NVA B -> VPN gateway -> branch

یہی خلا یہاں پورا موضوع ہے: روٹنگ کنورجنسی اور نشست کی حالت کی ملکیت مختلف مسائل ہیں جو خاکے میں ایک جیسے دکھتے ہیں۔

Route Server حقیقت میں کیا پروگرام کرتا ہے

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

اس لیے راستہ سیکھنا رسائی کو ثابت کرتا ہے۔ یہ اس بارے میں کچھ ثابت نہیں کرتا کہ دوسرے سرے کے آلے نے یہ بہاؤ پہلے دیکھا ہے یا نہیں۔

ڈیزائن کرنے سے پہلے دونوں سمتیں پڑھیں

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

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

حالت کہاں رہتی ہے

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

اسی لیے دو صحت مند NVA معائنے کے لیے صحت کی جانچ نہیں ہیں۔ صحت رسائی کے بارے میں ہے؛ معائنہ اس بارے میں ہے کہ کون سی مثال نشست رکھتی ہے۔

معاون HA ماڈل اور ہر ایک کیا وعدہ کرتا ہے

Microsoft's guidance on Virtual WAN روٹنگ ارادہ کے بارے میں Microsoft کی رہنمائی دوہرے کردار کی کنیکٹیویٹی اور فائروال NVA کے لیے محدود رویے کی وضاحت کرتی ہے، جہاں براہ راست روٹنگ ہب کے معمول کے ہم آہنگ نفاذ کو نظرانداز کر سکتی ہے۔ ان نوٹس کو اپنے منتخب کردہ ٹوپولوجی پر پابندیوں کے طور پر پڑھیں، فعال-فعال ڈیزائن پر پابندی کے طور پر نہیں۔ وینڈر کی وہ جوڑی جو حالت ہم آہنگ کرتی ہے، یا فی بہاؤ اسٹیئر کرتی ہے، معاونت حاصل کر سکتی ہے۔ برابر لاگت والی وہ جوڑی جو دونوں میں سے کچھ نہیں کرتی، معاونت حاصل نہیں کرتی۔

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

اس پر بھروسہ کرنے سے پہلے کیا جانچیں

Test with inspection enabled and ورک لوڈ کی رسائی پالیسی اپنی جگہ پر رکھ کر جانچیں، کیونکہ دونوں میں سے کوئی بھی عدم توازن چھپا سکتا ہے۔ دونوں سمتوں میں نیا مجاز بہاؤ بھیجیں اور تصدیق کریں کہ اسی آلے نے دونوں نصف دیکھے۔ پھر مسلسل ٹریفک چلائیں اور منظور شدہ فیل اوور شروع کریں، یہ دیکھتے ہوئے کہ قائم شدہ نشستیں بچتی ہیں یا دوبارہ جڑتی ہیں۔

ہر بہاؤ کو اس آلے سے منسلک کریں جس نے اسے سنبھالا۔ ایک NVA پر پیکٹ کیپچر تقریباً کچھ نہیں بتاتا اگر جواب کبھی وہاں واپس نہ آیا۔

آخر میں، منصوبہ تین الگ لائنوں کے طور پر لکھیں: راستوں کی ملکیت، ٹریفک اسٹیئرنگ اور نشست کی حالت کی ملکیت۔ پہلے دو حل ہونے اور تیسرے کو فرض کر لینے پر ڈیزائن ٹوٹتے ہیں۔