سائٹ سے سائٹ VPN پر ASA DHCP ریلے: مرحلہ وار رہنما

ریلے تین مراحل میں کام کرتا ہے اور VPN صرف درمیانی مرحلہ عبور کرتا ہے۔ کلائنٹ برانچ سیگمنٹ پر براڈکاسٹ کرتا ہے، ASA اُس براڈکاسٹ کو DHCP سرور کی طرف یونیکاسٹ درخواست میں بدل دیتا ہے، اور سرور کلائنٹ کی بجائے ریلے پتے کو جواب دیتا ہے۔ اسی ترتیب سے مراحل طے کریں، اور «ریلے خراب ہے» کے بیشتر واقعات کسی غائب پالیسی یا غلط پڑھی گئی setroute لائن پر آ کر ختم ہوتے ہیں۔

پہلا مرحلہ: کلائنٹ کی طرف والے انٹرفیس پر ریلے فعال کریں

برانچ کے ASA پر ریلے اُس انٹرفیس کی خصوصیت ہے جو کلائنٹس کی طرف دیکھتا ہے۔ سرور کو اس کے قابلِرسائی انٹرفیس کے ساتھ عالمی طور پر قرار دیا جا سکتا ہے، یا اسی کلائنٹ کی طرف والے انٹرفیس کے تحت، تاکہ روٹنگ ٹیبل اخراج کا راستہ چنے۔ یہ دونوں شکلیں ایک دوسرے کے بدلے استعمال نہیں ہو سکتیں، اور غلط شکل کا نقل اتارنا پہلا مقام ہے جہاں رہنما راستہ بھٹکتا ہے۔

کچھ بھی بدلنے سے پہلے چلتی ترتیب دیکھیں: کس انٹرفیس پر ریلے فعال ہے، سرور کی کون سی شکل موجود ہے، اور کیا setroute کلائنٹ انٹرفیس سے منسلک ہے۔ اگر ASA کسی دوسرے سیگمنٹ کے لیے بھی DHCP سرور چلاتا ہے تو رکیں اور پابندیوں کی فہرست پڑھیں؛ ایک ہی ڈیوائس پر سرور اور ریلے ایک ساتھ فعال نہیں کیے جا سکتے۔

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

دوسرا مرحلہ: ASA کا پیدا کردہ ٹریفک ٹنل سے گزار یں

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

یقینی بنائیں کہ دلچسپی کا ٹریفک ASA کے ریلے ماخذ اور سرور کے پتے کو ڈھانپتا ہے، اور واپسی کی سمت بھی اجازت یافتہ ہے۔ VTI پر مبنی ڈیزائن میں روٹنگ کا فیصلہ آسان ہے، تاہم VTI پر ریلے کی معاونت ایک مخصوص ریلیز میں آئی؛ ASA کا DHCP رہنما 9.14(1) کا ذکر کرتا ہے، اس لیے پرانے آلات پر VTI کی مثال نقل کرنے سے پہلے امیج دیکھیں۔

ASA سے سرور تک ping بذاتِ خود زیادہ کچھ ثابت نہیں کرتا۔ یہ کسی دوسرے راستے، دوسرے ماخذ پتے کے ساتھ، یا ایسی پالیسی کے تحت کامیاب ہو سکتا ہے جس سے ریلے کے پیکٹ مطابقت نہیں رکھتے۔

تیسرا مرحلہ: جواب اور setroute اختیار پڑھیں

RFC 2131 کہتا ہے کہ جب وہ خانہ صفر نہ ہو تو سرور اپنا جواب giaddr میں دیے گئے پتے پر بھیجتا ہے۔ لہٰذا واپسی راستہ ریلے پتے کی طرف روٹ ہونا چاہیے، اور ٹنل پالیسی کو سرور سے ریلے کی سمت کی اجازت دینی چاہیے۔ اگر درخواست گزر گئی مگر پیشکش کبھی نہ آئی تو دیکھنے کی جگہ یہی ہے۔

پھر ایک جیسی سنائی دینے والی دو چیزیں الگ کریں۔ setroute کی ورڈ وہ ڈیفالٹ روٹر اختیار بدلتا یا بڑھاتا ہے جو ASA کلائنٹ کو دیتا ہے۔ یہ ASA پر کوئی روٹ نصب نہیں کرتا اور VPN پالیسی نہیں بناتا۔ پتہ ملنے کے باوجود کہیں نہ پہنچنے والے کلائنٹ میں اکثر ٹنل نہیں بلکہ setroute یا اسکوپ کا مسئلہ ہوتا ہے۔ اسے بغیر جامد گیٹ وے والے کلائنٹ سے جانچیں اور دیکھیں کہ پیشکش میں کون سا ڈیفالٹ روٹر نمودار ہوتا ہے۔

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

«ٹھیک ہو گیا» کہنے سے پہلے میں کیا دیکھتا ہوں

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

اگر کوئی مرحلہ خاموش ہو تو مزید ریلے بیان جوڑنے کے بجائے متعلقہ پالیسی یا روٹ دیکھیں۔ جب کوئی معاملہ اوپر اٹھاتا ہے تو ریلے کی ترتیب عام طور پر پہلے ہی درست ہوتی ہے؛ جو بدلا ہے وہ ٹنل پالیسی یا واپسی روٹ ہے۔

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