ASA packet-tracer کے ساتھ VPN بہاؤ کو کیسے ماڈل کریں

ASA پر packet-tracer ایک تنگ سوال کا جواب دیتا ہے: کیا یہ پیکٹ، یہاں اس tuple کے ساتھ داخل ہوتے ہوئے، اجازت پائے گا اور کہاں جائے گا۔ یہ جواب نہیں دیتا کہ دور کا سرا کچھ وصول کرتا ہے یا نہیں۔ عام غلطی یہ ہے کہ بیرونی IKE tuple دیا جائے جبکہ جس چیز کی جانچ کرنی ہے وہ سرنگ کے اندر چلنے والی ایپلیکیشن ہے۔ پہلے tuple درست کریں، مراحل پڑھیں، اور پھر ہر اس چیز کے لیے حقیقی ثبوت حاصل کریں جو سمیولیٹر نہیں دیکھ سکتا۔

نیچے دیا گیا سفر یہ فرض کرتا ہے کہ ACL، NAT قاعدہ اور tunnel-group سیاق آپ کے سامنے ہیں۔ ان کے بغیر آؤٹ پٹ ایسی پالیسی بیان کرتا ہے جسے آپ جانچ نہیں سکتے۔

مرحلہ 1: اندرونی بہاؤ سادہ الفاظ میں لکھیں

کچھ بھی ٹائپ کرنے سے پہلے ایپلیکیشن بیان کریں۔ اندرونی میزبان جو دور کے گیٹ وے کے پیچھے سرور کے لیے SSH کھولتا ہے، وہ مخصوص ماخذ پورٹ کے ساتھ ایک اندرونی TCP بہاؤ ہے۔ ACL اور VPN فلٹر اسی بہاؤ کا جائزہ لیتے ہیں، اس لیے آپ بھی وہی ٹائپ کرتے ہیں۔

اسے ایک جملے کے طور پر لکھیں، پھر فیلڈ بہ فیلڈ ترجمہ کریں:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

مرحلہ 2: اندراج اور سمت منتخب کریں

اندراج وہ انٹرفیس ہے جس پر پیکٹ آتا ہے، نہ کہ وہ جس سے وہ جاتا ہے۔ شروع کرنے والے LAN میزبان کے لیے یہ inside انٹرفیس ہے۔ اسی سیشن کے واپسی پیکٹ کے لیے یہ outside انٹرفیس ہے، اور tuple الٹ جاتا ہے۔ منزل کو ماخذ کے طور پر لکھنا قابل اعتماد مگر غیر متعلق ALLOW حاصل کرنے کا دوسرا عام طریقہ ہے۔

پورٹس کی بھی سمت ہوتی ہے۔ شروع کی گئی درخواست میں سروس پورٹ منزل کے فیلڈ میں ہوتا ہے، اور کلائنٹ کا عارضی پورٹ ماخذ کے فیلڈ میں ہوتا ہے۔ TCP منزل 500 والا ماڈل 500 پر سننے والی TCP ایپلیکیشن بیان کرتا ہے؛ کمانڈ میں عدد دکھنے سے یہ IKE ٹیسٹ نہیں بنتا۔

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

آؤٹ پٹ میں ہر مرحلہ مالک والا فیصلہ ہے: راستہ تلاش، ACL، NAT، پھر VPN یا سرنگ کا انتخاب۔ انہیں چھاپی ترتیب میں پڑھیں اور پہلے ایسے مرحلے پر رکیں جو ڈیزائن سے مطابقت نہ رکھتا ہو۔

NAT لوگوں کو پھنسا دیتا ہے۔ اگر ترجمہ شدہ ماخذ اس crypto ACL سے باہر ہو جو سرنگ کے لیے ٹریفک منتخب کرتا ہے، تو بہاؤ کی اجازت مل سکتی ہے اور وہ کبھی encapsulated نہیں ہوگا۔ ٹریس ترجمہ شدہ پتہ چھاپتا ہے، اس لیے اس کا موازنہ اصل پتے کے بجائے سرنگ کی دلچسپ ٹریفک سے کریں۔

مرحلہ 4: آپ نے کون سے بائی پاس منتخب کیے، جانچیں

detailed شکل وہ اختیارات لیتی ہے جو جانچیں چھوڑ دیتے ہیں، اور Cisco bypass-checks اختیار کی دستاویز کرتا ہے جو ACL، VPN فلٹر، uRPF اور IPsec جعل سازی کی جانچوں کا احاطہ کرتا ہے۔ انہیں چھوڑ کر حاصل کردہ ALLOW کہتا ہے کہ راستہ اور NAT کام کریں گے، یہ نہیں کہ پالیسی حقیقی پیکٹ قبول کرے گی۔ نتائج کے ساتھ اختیارات درج کریں۔

اگر آپ کو پالیسی کا جواب درکار ہے تو بائی پاس کے بغیر چلائیں۔ اگر آپ روٹنگ کا سوال الگ کر رہے ہیں تو ان کے ساتھ چلائیں اور نتیجے کو روٹنگ جواب کا نام دیں۔

مرحلہ 5: حقیقی تبادلے سے خلا بند کریں

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

کچھ trace اور replay اختیارات پیکٹ بھیجتے ہیں یا حالت محفوظ رکھتے ہیں۔ ہر قسم کو صرف پڑھنے کی تلاش سمجھنے کے بجائے اپنی ریلیز اور منظور شدہ تشخیصی طریقہ کار کے لیے دستاویزی رویے کی پیروی کریں۔

ٹریس اب بھی آپ کو کیا نہیں بتا سکتا

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

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